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

[Roland McGrath]

> 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.

Sounds like clobberation to me.

> 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?

That's a reasonable thing to do.  As I said, reentrance is something to be
suspicious of.  So you could insert a simple check for that, i.e.:
        if (lmm_in_use) panic;
        lmm_in_use=1;
        ...
        lmm_in_use=0;

> 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.

There are other tricks you can use, like setting a breakpoint on a
rarely-used system call and then do something in your Hurd that invokes it.
I don't recall what I used to use for this.

I remember C-c not working very often, though it should.  The way it should
work is that the irq for the gdb serial port should be set up by
gdb_pc_com_init to run gdb_pc_com_intr.  There is a hack in int_init.c
in oskit-mach that tries to avoid interfering with this, but it is
hard-wired for irq 3 (the usual setting for the second serial port).