> As a quick cheesy test, I wonder if we could confirm this, or at least
> learn something useful, by moving the problem around?

That might work, but I'm not that familar with the pool allocator in
NetBSD, so I can't say for certain.

> > The DEBUG_MEMGUARD option was quite useful in tracking this down - I
> > wonder if something similar might help narrow down what's happening in
> > your case?

> I presume this surrounds each allocation with extra padding filled
> with known content, and checks that the padding is undisturbed later?
> That more general solution sounds very useful too; I'm not sure if we
> have something like this, but we probably should.

It actually puts each allocation in its own page. When the allocation
is freed the vm system sets up the page to cause a fault if the
page is accessed. That way we can catch code that uses-after-free.
It's very wasteful of memory, but is only intended as a debugging
tool.

(At the moment you attach the option to a particular allocation type.)

	David.