Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: fsck seg fault failure on vmware -i386?

In article 
 <> wrote:
>> What would be useful would be to find out (if it is possible, I hestiated
>> to ask earlier, as I suspect this will not be easy) would be to find out
>> just what the value of the time_t is that was handed to ctime() and ended
>> up with a core dump.    That, and the (much easier to discover) what
>> timezone
>> would normally be in use (ie: what is /etc/localtime) ?
>> If the core dump from fsck can be obtained, the way to discover the time
>> value most easily (I think) would be to do a stack trace, look at the call
>> of ctime(), see its (one) parameter, and look at what that points to -
>> that's
>> the time_t value of interest.
>> Apart form that, it would require finding the inode in question, and
>> dumping its contents, which is probably not-trivial.
>> Of course, an alternative way to see if this is what the problem is would
>> be
>> to fix asctime_r() (simply make it return NULL if its timeptr arg is
>> NULL),
>> and fix fsck_ffs (if ctime() returns NULL, don't attempt to dereference
>> it).
>> Then see if that version of fsck_ffs still dumps core, if it does, then we
>> haven't yet found the real problem.  If those changes fix it, then you
>> have
>> the guts of a PR to submit to get a big fixed...
>OK, have core and gdb - you already saw the backtrace ouput...
>Is this what you are looking for?:
>(gdb) down
>Bottom (innermost) frame selected; you cannot go down.
>(gdb) up
>#1  0xbbb3c6b3 in asctime () from /lib/
>(gdb) up
>#2  0xbbb39284 in __ctime50 () from /lib/
>(gdb) up
>#3  0x0804d5e6 in pinode (ino=224938) at /usr/src/sbin/fsck_ffs/inode.c:659
>659             p = ctime(&t);
>(gdb) print t
>$1 = 1264115119
>(gdb) print &t
>$2 = (time_t *) 0xbfbfdaa8
>(gdb) quit

Oh, it is dying inside asctime! Can you build a debugging libc, (MKDEBUG=yes)
and then link fsck with -lc_g?


Home | Main Index | Thread Index | Old Index