xfs
[Top] [All Lists]

Re: xfs_repair crashing (versions 3.1.4 and 3.1.5)

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: xfs_repair crashing (versions 3.1.4 and 3.1.5)
From: Anisse Astier <anisse@xxxxxxxxx>
Date: Tue, 19 Apr 2011 13:07:37 +0200
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20110419082705.GI23985@dastard>
References: <BANLkTikh1i3aYgXNZut+AGT-1kz=aqv-Eg@xxxxxxxxxxxxxx> <20110419082705.GI23985@dastard>
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.


Regards,

Anisse

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