Re: fsck seg fault failure on vmware -i386?

[Robert Elz <kre%munnari.OZ.AU@localhost>]

  | 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>
    Message-ID:  <20100207093424.GA23095%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.

kre