Mail Archives: djgpp-workers/2002/10/22/15:25:48
> Date: Mon, 21 Oct 2002 06:24:25 -0400
> From: CBFalconer <cbfalconer AT yahoo DOT com>
>
> > > The point to me is that
> > > any such interfaces are done through header files, and leave the
> > > malloc code itself free to do what it needs.
> >
> > I'm not sure I understand. The debugging hooks are called by malloc at
> > strategic places, provided that they are non-NULL (each hook is a pointer
> > to a function, by default set to NULL). malloc is free to do what it
> > needs, but it must call the hooks while it's doing that.
>
> Why do it within malloc? Isn't it easier to define say
>
> void * xmalloc(size_t sz)
> {
> void *p;
>
> xmentryhook(sz);
> p = malloc(sz);
> xmexithook(p);
> return p;
> }
>
> in the users space.
Because the hooks don't just tell you when malloc is called. They
tell you something about the inner workings of malloc, so a program
which hooked into malloc can gather information about memory
allocation.
For example, __malloc_get_freelist returns the free list of memory
blocks, an otherwise internal structure. An application can then
examine the free list for whatever it needs, like count the size of
the free memory pool.
Another example is __libc_malloc_fail_hook, which, if points to
something non-NULL, is called by malloc when it is about to fail the
call. An application that sets up such a hook can later print how
many allocations failed. __libc_malloc_hook is called whenever a
block is returned to an application, and the info about that block is
passed as arguments to the hook; this can be used to gather statistics
about memory allocations. Etc., etc.
malldbg.c uses these hooks to implement a simple malloc debugging
and memory reporting package.
> Incorporating such pointers in the module will mean they
> have to be NULL initialized and tested
True. I don't think a test against NULL is a significant overhead in
normal usage.
> and non-standard routines will have to be present to set and reset
> them.
Well, messing with internals of a library implementation is inherently
non-standard. Those hooks are meant to be used by memory allocation
debuggers and various malloc extensions, so standardization of the
internal names is not the issue. For example, malldbg.c implements
several fairly-standard functions using these facilities.
> It also means that
> such routines as "free(NULL)" cannot simply do an early return,
> but must use the single return point.
I don't see why. `free' simply does this:
if (ptr == 0)
{
if (__libc_free_hook)
__libc_free_hook();
return;
}
So you again pay the price of a single comparison.
> Or is name changing the operational problem?
It's mainly a back compatibility problem.
> At any rate, if you can ease my getting the descriptions of the
> interfaces, I can think about things much better, rather than
> making wild guesses.
I'll happily help you understand teh current implementation. Just
ask questions here if the docs is not enough.
> Just looking at the names above realloc_fail_hook seems to be
> missing.
realloc fails if malloc fails, and the latter has a fail hook.
But I don't have anything against adding a reall-c-specific fail
hook, if that's what people want.
> And what about calls that
> are rejected because the memory has been corrupted or free/realloc
> is passed an invalid pointer (some of which I detect and do a
> signal).
If these are detected, we probably want additional hooks for these
specific failures.
- Raw text -