strange effect with --enable-fast-malloc=full

[Michael Matz]

Hi,

On Thu, 18 Apr 2002, Falk Brettschneider wrote:

> In case of a memory fault the application should always segfault.

This can't be ensured.  If memory is corrupted, you can't expect anything
from it anymore, not even that it reliably segfaults.

> user just wonders why there's 100% CPU load. In the last years I've
> never seen the original malloc() having such problems with buggy
> programs.

Which doesn't indicate anything.

> > This doesn't look like a real fix to me. What if
> >'if(next->fd->fd->fd==nextp)' will be needed some day too?
> >
> Indead this is unsolved. Is there a general rule that for instance the
> address of nextp has always to be bigger than the one of next? Maybe
> such a check is better. But I don't fully understand the malloc() code.
> The meaning of the variables isn't very well documented.

I anyway would be against such workarounds.  They try to implement a
certain behaviour in case memory was corrupted.  This is bound to fail
anyway, so slowing down the malloc just to handle a small subset of the
problem, is useless IMHO.  Fix the app instead.

> I'm sorry, I don't have time any more for this. That's why, now I don't
> use --enable-fast-malloc any more, other programmers should be warned to
> use it, too.

Well, programmers should be warned too about not deleting the same pointer
twice, or accessing memory not allocated.  But this OTOH is not a property
of the malloc, but of C++, so an extra warning seems inappropriate.  The
same way is the warning you wanted.  How should it be worded?  "Please be
aware, that if you rely on SEGV on memory corruption, don't use
fast-malloc"?  That's nonsense.

If you really want to debug your app by waiting for a SEGV, then develop
without fast-malloc (even then it's not exactly a sane mean for
debugging), and only release with it.


Ciao,
Michael.