[PATCH] Fix compilation --with-debug-malloc && --with-error-checking=malloc; better dlmalloc overhead

[Nix]

On 29 Dec 2006, Stephen J. Turnbull spake thusly:

> Nix writes:
>
>  > As an additional wrinkle, the Doug Lea malloc() has always had an
>  > overhead of at least 4 bytes per allocated chunk (8 bytes per chunk for
>  > machines with 8-bit pointers, more if this is a large request satisfied
>  > via mmap() rather than via arena allocation). For now, 4 bytes is more
>  > accurate than the previous figure of, um, 0. (What malloc() has no bytes
>  > of overhead?! How on earth would it track blocks?)
>
> ISTR comments indicating that malloc overhead was handled in some sly
> way.  Am I misremembering?

There *is* code in alloc.c:malloced_storage_size() for SYSTEM_MALLOC
which does... interesting things to claimed_size(), but that's not quite
the same.

This is all tangled up with multiple-mallocs stuff anyway and thus is a
nest of (torpid) snakes...

> I've always thought it absurd that you can't ask the system for
> information about a block if you hand it a pointer.

I concur, not least because free() *has* to track things like the size:
why can't it tell us what it is?


(btw, on a vaguely-related subject, the leak is suppressed: now I just
need to figure out why my crude suppression hack works and fix the thing
I've suppressed so it doesn't explode the arena. Memory usage still rises
but at ~10Mb/hr of heavy Gnus usage, which is much more acceptable given
that some of that could be accounted for by loading the odd elisp file
(maybe that happened and I didn't notice).

More definite info in a couple of hours unless something knocks me
offline: always possible when you're at the wrong end of a bad phone
line in the savage Yorkshire wilds...)