Mail Archives: djgpp-workers/2003/03/19/13:22:31
Eli Zaretskii wrote:
>
> > Date: Tue, 18 Mar 2003 22:30:27 -0500
> > From: CBFalconer <cbfalconer AT yahoo DOT com>
> >
> > Fairly good news. mallinfo and mallocmap now work. malloc_verify
> > looks like it will be no problem. The malloc_debug interface can
> > also be easy, but I think its semantics need some clearing up.
>
> Good news indeed! Thanks for working on this.
>
> > I am very nervous about examining the environment, since
> > malloc/free/realloc seem to be called deep within the startup
> > code
>
> While it's true that malloc et al are called inside the startup code,
> the debugging features can be disabled at that stage, since none of
> that phase is of any interest to users, and malloc_debug could be
> called only from `main' (or from static constructors that run just
> before `main'). At that point, there should be no problem to look at
> the environ[] array, since it's already set up.
>
> In other words, you could allocate that array inside malloc_debug, in
> which case you can be sure it's safe to examine the environment.
No, unfortunately (or fortunately) it is too late by then. I have
to capture the base of the allocation chains, and that is formed
on the initial call to malloc anywhere, and on any sbrk call that
returns unexpected values. The runtime seems to malloc and free
objects before the application starts, so some application
allocated items are going to buried adjacent to system stuff.
Their actual allocation can take place long after any malloc_debug
calls are performed, and they would still be lost. There is
nothing consistent evident from the startup operation - things
seem to change with command line length, for example. My guess
would be something to do with forming argv[].
>
> > and the result can't be used to assign a static object anyhow.
>
> Sorry, I don't understand what problem you were thinking about here.
I can't declare a static array of pointers whose size is
determined at runtime. Nor do I want to get into any headaches
from malloc recursively calling malloc. There there be dragons.
>
> > The semantics of malloc_debug are going to need examination. All
> > the processes work from the get-go, so there is no need to enable
> > debugging to be able to examine things.
>
> Does that mean your code records the necessary information regardless?
> If so, isn't that an unnecessary overhead that could be omitted when
> debugging features are not required?
Yes it does. It is not unnecessary, it is the information that
was needed to make the free operation O(1). It is also used to
enhance the performance of realloc, which is also O(1).
>
> > I would like to see an additional field to the mapinfo record,
> > specifying the count of free blocks. Will this cause problems
> > elsewhere, or will reusing an existing field cause problems?
>
> We need to be compatible to the struct definition as it is now, since
> other Unix platforms use that. But I don't see any problem to use an
> unused member for what you need (there are a few that are unused in my
> implementation, IIRC).
Then please suggest which fields can be reused. Are the field
names sacred?
>
> > How to handle namespace pollution? All those names (mallocmap
> > etc.) are in the users space, and should not be taken from him
> > IMO.
>
> Right. Those functions are documented and exist on other platforms,
> so we should keep their names.
>
> > I would much rather see a set of names in implementation
> > space.
>
> What would be the purpose of this, other than allow the debug
> interface to be part of the standard malloc (see below)?
No funny surprises when joe luser prepares an application handling
his local shopping mall, creates a module named mallinfo, and
forgets to link it in. Or links it in and then expects to use the
allocation debug package.
>
> > If this is done the whole set of debuggery can always be
> > sitting there for use on demand, with no special linking etc.
> > requirements.
>
> There should be no special linking requirements. As soon as the
> application invokes one of the debug functions, the malloc-debug
> module will automatically be linked into the app.
>
> As for having it there by default, I'd rather not bloat every DJGPP
> program unless we really need that. We already have too many FAQs
> about the size of a hello world program.
It is NOT going to be bloat. The debuggery package is in the
order of 2k of object code. The nmalloc package itself is about
2.5k. The only special requirement I envision is a #include in
the application, which can probably be avoided if the user does
not specify ansi pedantic. But that complicates the conditionals
in stdlib.h.
>
> > I also suggest considering a means of setting a logging file for
> > the debug output.
>
> I don't mind, but that would be DJGPP-specific, as I think there's no
> equivalent functionality on other platforms that support malloc_debug.
> But if someone could find an equivalent functionality, I think we
> should design this to be API-compatible.
what about:
int malloc_debug(int level, FILE *f);
where f == NULL is the present call, and something else sets the
output file. Maybe we rename it _malloc_dbg and provide a macro:
#define malloc_debug(i) _malloc_dbg(i, NULL)
Please also see the sample output run I put up here a short time
ago.
--
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 -