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

[Lubos Lunak]

On čt 18. duben 2002 11:24, Lubos Lunak wrote:
> On čt 18. duben 2002 09:04, Falk Brettschneider wrote:
[snip]
>
>  I'll see if Doug Lea says anything on this.

 Hmm, that was fast:

----------  Forwarded Message  ----------

Subject: Re: Infinite loop in malloc
Date: Thu, 18 Apr 2002 07:17:48 -0400
From: Doug Lea <dl at cs.oswego.edu>
To: Lubos Lunak <l.lunak at sh.cvut.cz>
Cc: Doug Lea <dl at cs.oswego.edu>

>  The problem itself happens in malloc_consolidate(), when the do {} while(
> p=nextp ) != 0 ); loops forever, because for some reason nextp == p->fd

This definitely looks like an application bug where either there is a
duplicate free, or someone is writing over a freed chunk. It ought not
be too hard to track down. Most likely a duplicate free (these have
different symptoms depending on chunk sizes etc). If not, then the
kind of object is something that has a pointer as its first field, and
that pointer is set to itself after being freed.  You might be able to
find problem faster by compiling -DDEBUG -DDEFAULT_MXFAST=0.  This
will slow it down a lot but will probably quickly find problem.

(In general, you might advise everyone with apparent malloc problems
to first compile with debug etc before trying to "fix" malloc. It
would save eveyone a lot of time :-)

And about the claim in the posting...

> Second, an infinite loop in malloc is a bug IMO.

In which case, probably every malloc has a bug, since an arbitrarily
evil program can trash memory so badly that no malloc can cope.

-Doug

-------------------------------------------------------

-- 
 Lubos Lunak
 llunak at suse.cz ; l.lunak at kde.org
 http://dforce.sh.cvut.cz/~seli