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

[Falk Brettschneider]

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.

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.

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.

Hope that helps,
Cheers,
F at lk

P.S.: I can commit if you want to

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: malloc.c.diff
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20020416/d730f540/attachment.ksh>