[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: fsck seg fault failure on vmware -i386?
Date: Tue, 2 Feb 2010 09:04:53 +0100
From: Rhialto <rhialto%falu.nl@localhost>
| I know that my idea about /etc/localtime was discounted, but you can try
| it fairly easy anyway: give it a go with /usr mounted, but with
| /etc/localtime pointing to some non-existent file.
It actually could be related, but not in the way that you probably think,
just having the file absent wouldn't cause a problem, but having it absent
would mean a different default timezone was in use, and (in a few very
unlikely cases) different timezones can mean different times are valid,
and others not (and end up generating NULL from localtime() which does seem
to be the only way asctime_r() could core dump).
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...
Main Index |
Thread Index |