[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: fsck seg fault failure on vmware -i386?
| On Sun, Feb 07, 2010 at 08:23:15AM +0000, David Laight wrote:
| > That data doesn't look very good to me at all.
| > (Under the assumption it is supposed to be a disk inode.)
Well, assuming that the difference in system versions from where
the binary & core were created, and mine where I ran gdb didn't totally
scramble things (I can't think of a good reason why just examining the
executable and core file should be a problem though - source file line
numbers won't match, and libc references are all wild, but dumping the
inode contents should all be based upon the symbol table in the binary).
Date: Sun, 7 Feb 2010 09:34:24 +0000
From: David Holland <dholland-current%NetBSD.org@localhost>
| Also, di_nlink of 19288 is implausible and di_mode is invalid.
Yes, we know this is a mess - the question we're trying to answer is just
why fsck_ffs dumps core on that inode (or thing that ought be an inode
but looks like noise). And even weirder, why it doesn't dump core if
/usr is mounted (which must relate to access to the timezone data files,
given that the core dump is from in asctime_r() - the immediate cause of
the core dump seems clear, the question is just what conspired to
lead to that happening (ie: localtime() almost certainly returned NULL,
but why ???)
Before wasting more time on my gdb dump though we need someone with a
consistent system environment to confirm that what my gdb printed is
really what is there.
Main Index |
Thread Index |