[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: fsck seg fault failure on vmware -i386?
>> 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
>> 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 -
>> 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
>> to fix asctime_r() (simply make it return NULL if its timeptr arg is
>> and fix fsck_ffs (if ctime() returns NULL, don't attempt to dereference
>> 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
>> 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?:
>Bottom (innermost) frame selected; you cannot go down.
>#1 0xbbb3c6b3 in asctime () from /lib/libc.so.12
>#2 0xbbb39284 in __ctime50 () from /lib/libc.so.12
>#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
Oh, it is dying inside asctime! Can you build a debugging libc, (MKDEBUG=yes)
and then link fsck with -lc_g?
Main Index |
Thread Index |