Mail Archives: djgpp-workers/2003/03/17/10:41:48
Richard Dawe wrote:
> CBFalconer wrote:
> [snip]
> > Following this (at the end) is the header file for malldbg, which
> > is the module that will implement all of this. The set of hooks
> > are fundamentally flawed, and, while included, I also propose a
> > set that will avoid those flaws. For example, the existing
> > realloc hook has no way of telling what the result of realloc
> > was.
>
> FWIW they look like they've been defined to be similar to the interfaces
> provided by glibc. Was near-compatibility with the glibc interface one
> of the goals, when the interface was designed?
They have. I would not have designed them that way.
>
> As the libc docs say:
>
> "`__libc_realloc_hook'
> Called at entry to `realloc', before the actual reallocation.
> BLOCK is a pointer 4 bytes before the address passed to `free' by
> the application, i.e. it is a pointer to the beginning of the size
> information maintained before the user buffer. SIZE is the new
> size requested by the application. (This hook is called _in
> addition_ to the other hooks which will be called by `free' and
> `malloc' if and when `realloc' calls them.)"
>
> The __libc_malloc_fail_hook would be called, if the realloc call were actually
> failing. So you can find out whether realloc fails, but not in the realloc
> hook itself.
There is a big fallacy here - i.e. that malloc and free are
actually called. This is not so for nmalloc, although it does
call some of the same routines. realloc is designed to avoid
moving data whenever possible. Nothing in the standard requires
this either. The end effect is the same.
Also the "4 bytes" is not accurate, and makes an unwarrented
connection to the actual implementation. See the definition of
sysquery, which is returned dynamically, and thus can adapt to the
actual situation.
>
> [snip]
>
> You can get a recent snapshot of the malloc sources from djlsr204.zip
> downloaded from the page above or get one of MartinS's CVS snapshots. The
> sources are in src/libc/ansi/stdlib. Oh, and there's the include files
> (libc/malldbg.h? Or more?). So you don't need to create a new development
> environment, just to use the malloc from CVS. Just copy the files into some
> work area
No, I can't use the existing malloc. That is the whole reason for
this development in the first place. On principal, subsystems
should be developed in isolation, but checked in the overall
system.
>
> > Nobody has confirmed or denied that the html doc file I fed back earlier
> > really covers the subject.
>
> I confess I haven't looked at either MartinS's snapshot or the ZIP file you
> sent.
>
> > Maybe the following header will have better luck.
> [snip]
>
> Maybe you could provide a summary of the problems with the current hooks and
> how your interface is better? What I can see so far:
>
> Bad points:
>
> * The realloc hook won't tell you whether realloc has failed. (This may not be
> a problem, if you think the __libc_malloc_fail_hook is good enough.)
See above.
>
> Good points:
>
> * It has an extendable interface for setting the hooks.
>
> * The paradigm for setting the hooks is a bit nicer, because it returns the
> old hook value, instead of the user having to explicitly save it. Is there
> some problem I missed here? This just seems like a way of saving typing (=>
> slightly less error-prone).
No, it is a means of avoiding evil probing into system memory. It
is also easily extendible in future, without affecting existing
code. It has already implemented an extension in the
realloc_exit_HK.
Look at the description of malloc_debug, for example. It is full
of implementation details, and lacking in functional details. Are
the reports to stdout, stderr, or some logging file? I take the
last back - it does say stderr. nmalloc already largely verifies
consistency. I took out some further internal verification
because people were worried about the overall footprint before.
Adding that back would avoid ANY need for 400 kb auxiliary
storages and intrinsic limits.
Have you ever run the testing code in the nmalloc package, and
seen the displays of the free memory chains, etc.? This was
deliberately made external to the package as a demonstration of
probing the structure.
If not, try:
tnmalloc (alone, for some idea of the tests etc)
tnmalloc 4 20 | less (Output is excruciatingly detailed)
and notice the periodic dumps of the free memory chains. Note
that chain 0 is actually the last sbrk block being handled.
Those dumps were used in developing the package, and follow all
the actions around.
--
Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT worldnet DOT att DOT net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
- Raw text -