> Sorry to follow up to my own post, but .. 
> 
> >	Data modified on freelist: word 3 of object 0xf87b2ec0
> >		size 56 previous type VM mapent (0xdead9eef != 0xdeadbeef)
> 
> 	Sorry I didn't catch this one. I know now that the value 0xdeadbeef
> is oft-used as empty markers in data structures.
> 
> 	Since this appears to have dropped a bit, does that imply bad
> memory? Its the exact same bit every time .. (b -> 9)

My guess is that it's not your RAM.

[ the following may be completely useless. 8-]

I'd say that there's some piece of buggy code out there (heh) which
is performing one of the following sets of actions:

	(1) freeing some memory, and
	(2) clearing bit 13 of the fourth word (word #s printed start
	    at 0) of the memory block.

or:

	(1) freeing some memory, and 
	(1) decrementing a count in the fourth word of the memory
	    block by 8k.

Either seems reasonable, but given the nature of your crash i'd guess
the latter.  (i'd say that'd be especially likely if you have all
8k-block-size file systems, and/or were beating on one when the
machine crashed.)


I looked for the obvious culprits for a flag-clearing: aha driver,
buffer struct, various vm structures (esp. vm_map_entry_t, the type
that the malloc code claims the memory block was last used as), tty
struct (paranoid distrust of the tty code is good for you, and it has
lots of flags 8-), and various MI SCSI structs, and didn't notice any
that have a flags field in the right place.

I looked in a few places for a count in that position which could have
been modified (buffer and related structs, aha stuff, MI SCSI
scsi_sfer, etc.), but didn't see anything there either...



chris