Mail Archives: djgpp-workers/2003/04/21/12:05:59
Charles Sandmann wrote:
>
> > You mean you are ready to incorporate it? This was intended to
> > allow others to thrash it, and expose any crawling creatures with
> > more than four legs or less than one.
>
> Martin Stromberg ran it as his default malloc in his CVS tree
> for quite some time.
>
> The only way to get a more extensive test is to put it in an
> alpha test of the entire build suite. So in a word, yes - if
> we could get the issues resolved I'd want to incorporate it
> (which is why I'm so bitchy about the compatibilty/docs).
>
> I'd still like to make sure all the tests added since V2.03
> (for things like fluffy 2GB+ mallocs) are fixed.
Ok, this is a new objective, AFAIAmC. What is fluffy 2GB+
malloc? If sbrk performs, I expect nmalloc will, but IHBWB.
What about my new method of installing hooks? I would dearly love
to discard the old, which isn't publicized in 2.03, and so
shouldn't harm much. The debug_level could also do with a change
- I would prefer to see individual features enabled by individual
bits, so the user can pick and choose:
Bit
0: Nothing. Even installing hooks is prevented
1: External hook installation allowed.
2: Malloc_verify enabled, messages only if anomalies
4: Automatic verify on all malloc/realloc calls, message only
8: Verify does immediate abort.
16: Reports free(NULL)
out of which we can build several published constants as arguments
for malloc_debug. Something like:
tyoedef enum (DBG_OFF = 0, DBG_HOOKS = 1, DBG_VERIFY = 2,
DBG_AUTOVERIFY = 6, DBG_CATCH = 14,
DBG_FREENULL = 16) DBGKIND;
and free the code from dependance on arbitrary magic numbers. Now
if that bit assignment isn't viable it can easily be changed.
DBGKIND malloc_debug(DBGKIND level);
possible user level code:
if (!(newlevel = malloc_debug(DBG_CATCH, NULL)) {
fprintf(stderr,
"Must first reset to DBG_OFF or remove existing hooks");
}
else current_lvl = new_lvl;
or
current_lvl = malloc_debug(DBG_AUTOVERIFY, logfile);
/* code under suspicion for fouling its nest */
current_lvl = malloc_debug(current_lvl, logfile);
to isolate the slowdowns to the area under suspicion. I don't
know of any system that provides such convenient features.
(taking pity on the future maintainer). The earlier such changes
are made the easier it all becomes.
--
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 -