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

[Falk Brettschneider]

Hi!

Lubos Lunak wrote:

>On út 16. duben 2002 22:43, Falk Brettschneider wrote:
>
>>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.
>
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.


>
>
>>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.

>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.
>

Thanks anyway,
Cheers
F at lk



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com