Re: oskit-mach bug, panic in consider_lmm_collect()

[Igor Khavkine]

On Mon, Jul 23, 2001 at 09:30:08PM -0400, Roland McGrath wrote:
> You should set a breakpoint (or insert a panic call) in the lmm code so you
> catch it as soon as it fails and wants to return 0.  The lmm datastructures
> must be messed up somehow.  One possibility is some
> locking/interrupt-blocking sort of bug wherein lmm gets reentered.

It seems that in one of the `regions' of `malloc_lmm', the sum of
all `size' fields of all nodes on the list does not add up to
`free' as marked in the region structure.

I think I can reproduce this bug when I try to uncompress a big source
package (like glibc). However it seems to me that the `malloc_lmm'
data structure would be accessed quite regularly, making it difficult
to pinpoint the instance when the data is corrupted. I was thinking
of adding sanity checks through out [gnumach]/oskit/osenv_mem.c to
try to pinpoint when the data is corrupted. Is there a better solution?

Also it seems impossible to interrupt a running kernel using C-c from
gdb over a serial line. Is this feature not implemented in oskit-mach's
gdb stubs? This makes it very difficult to set breakpoints since I have
to set all of them before the kernel starts running.

Igor