xfs
[Top] [All Lists]

Re: xfs_repair crashing (versions 3.1.4 and 3.1.5)

To: Anisse Astier <anisse@xxxxxxxxx>
Subject: Re: xfs_repair crashing (versions 3.1.4 and 3.1.5)
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Thu, 21 Apr 2011 14:26:06 -0500
Cc: Dave Chinner <david@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20110419130737.45beb611@xxxxxxxxxxxxxxxxx>
References: <BANLkTikh1i3aYgXNZut+AGT-1kz=aqv-Eg@xxxxxxxxxxxxxx> <20110419082705.GI23985@dastard> <20110419130737.45beb611@xxxxxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
On 4/19/11 6:07 AM, Anisse Astier wrote:
> On Tue, 19 Apr 2011 18:27:05 +1000, Dave Chinner <david@xxxxxxxxxxxxx> wrote :
> 
>> On Mon, Apr 18, 2011 at 09:24:22PM +0200, Anisse Astier wrote:
>>> directory flags set on non-directory inode 2283178100, would fix bad flags.
>>> bad key in bmbt root (is 73434, would reset to 74194) in inode
>>> 2283178100 data fork
>>> bad fwd (right) sibling pointer (saw 145202888 should be NULLDFSBNO)
>>> Segmentation fault
>>
>> Hmmm. The very next line doesn't appear before the segfault, making
>> me think that it's the printf that is causing it to crash.
>>
>>         if (check_dups == 0 &&
>>                 cursor.level[0].right_fsbno != NULLDFSBNO)  {
>>                 do_warn(
>>         _("bad fwd (right) sibling pointer (saw %llu should be 
>> NULLDFSBNO)\n"),
>>                         cursor.level[0].right_fsbno);
>>
>> We get this line of output.
>>
>>                 do_warn(
>>         _("\tin inode %u (%s fork) bmap btree block %llu\n"),
>>                         XFS_AGINO_TO_INO(mp, agno, ino), forkname,
>>                         cursor.level[0].fsbno);
>>
>> But not this one. I wonder if passing a 64bit number to a %u format
>> string (shoul dbe %llu) causes problems on ARM? All the variables
>> are valid as they are printed or accessed elsewhere in the function,
>> so that's the only thing I can think of without a stack trace to
>> tell me otherwise....
> 
> I have no idea. I did not succeed in getting a stacktrace. CPU is an
> ARM9, and I used Debian armel squeeze & wheezy  xfsprogs binaries.

Perhaps you could try removing or fixing the printf Dave suspects, rebuild 
repair, and run it again?

-Eric

<Prev in Thread] Current Thread [Next in Thread>