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

[Lubos Lunak]

On út 16. duben 2002 22:43, Falk Brettschneider wrote:
> Hi!
>
> Lubos Lunak wrote:
> >>>Yes, you should. Unless you can prove the bug is not in the application,
> >>>I'm considering this malloc() implementation to be Bug Free(tm).
> >>
> >>Hmm...being in the infinite loop is worse than a good old-fashioned
> >>crash. Can we please insert an escape condition { ... if (p->fd==nextp
> >>&& prev_inuse(p)) { break; }... } while (....) ? Then I at least get a
> >>good crash. :-)
> >
> > Hmm. I'll think about this after we find out where the problem is. If
> > it's the app's fault, I don't think it should check for every runaway
> > pointer. And if it's this malloc's fault ... well, it's a malloc
> > implementation developed for several years and probably widely used,
> > which I more or less just tweaked a bit and copy&pasted spinlocks from
> > glibc to it.
>
> Well, Lubos, there must be a difference between your implementation and
> the classic malloc. As I wrote before it doesn't infinitely loop, if I
> don't switch --enable-fast-malloc=full on.

 Yes, and the difference is the internal data. With one implementation, if you 
delete twice or write out of the allocated data, you damage the internal 
data, with other implementation, you may be writting to an unused part of 
memory. Just the fact that it crashes with one malloc implementation but 
doesn't with another doesn't necessarily mean that the first one is broken.

>
> Second, an infinite loop in malloc is a bug IMO. It should never happen
> there. If I get a crash in my application, that's the common signal for
> me to fix a memory problem in my app.

 I don't see how much different is a malloc that crashes and heap corruption 
from one that endlessly loops on heap corruption. Assuming neither of them is 
buggy, which we still don't know yet.

>
> But I don't just grumble, I have a patch for you that fixes the problem
> here. All other KDE apps seem to work on normally. The patch is not only
> the (p->fd==nextp) condition but also the (nextp->fd->fd==nextp)
> condition that also happened here and leads to the same infinite loop.
>
> P.S.: I can commit if you want to

 This doesn't look like a real fix to me. What if 
'if(next->fd->fd->fd==nextp)' will be needed some day too? Does this patch 
make your application work? Given that you actually can test it, as when your 
application is already closing down, there're not many chances to crash on 
corrupted heap. If you add one loop at the end of main(), allocating a lot of 
blocks of different sizes and another one releasing them, will it still work? 
Regardless of where the problem is, the patch looks like curing only the 
symptoms you have.


 Put '#define DEBUG' at the beginning of malloc.c and recompile it, it will 
add some checks and will hopefully crash somewhere near the real problem. And 
if you could put the debug outputs there printing the block addresses, that 
would probably help too (I still think it's a double deleting of something, 
not that rare when application is closing down). And I'll probably mail Doug 
Lea, just in case the bug is really in the malloc.

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