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

[Lubos Lunak]

On čt 18. duben 2002 09:04, Falk Brettschneider wrote:
> Hi!
[snip]
> >>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.
>
> In case of a memory fault the application should always segfault.
> Imagine you start the app from K->RunCommand. You don't have a prompt
> that shows the app has finished. If it stays in the loop at the end of
> the program, it will look like the app doesn't have a problem but the
> 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.

 As soon as you corrupt your memory or do other bad things, the code is free 
to do anything, including throwing your computer out of the window. The 
trick, of course, it not to release such buggy programs.
 To avoid this bad situation, I'm going to --enable-fast-malloc enable by 
default on Linux and FreeBSD in HEAD. I've already had one case where 
everybody was running KDE happily, only for me it was crashing, the reason 
was of course this malloc and a duplicated delete somewhere in kdelibs. By 
enabling this (apparently more vulnerable) malloc by default, such problems 
will be spotted in time instead of making trouble to users (e.g. SuSE 
packages have this malloc enabled in 3.0.0 - and I haven't had a single 
complain from Adrian).

>
> >>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?
>
> 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.
>
> >Does this patch
> >make your application work?
>
> Yes. It works well with my patch. Now I get just a segfault in
> qt_cleanup() at XCloseDisplay(). I'm hunting the leaks now.

 'Works well'?

>
> >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).
>
> 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.
>
> >And I'll probably mail Doug
> >Lea, just in case the bug is really in the malloc.

 As I said, I don't have a single reason to believe the problem is in malloc. 
In case somebody else will have problems with it too, and will be able to at 
least somewhat proof the problem is not in the application, I'll reconsider.

 I'll see if Doug Lea says anything on this.

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