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
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
