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

[Falk Brettschneider]

Hi Lubos

Lubos Lunak wrote:

>On út 16. duben 2002 15:28, Falk Brettschneider wrote:
>
>>Hi!
>>
>>Lubos Lunak wrote:
>>
>>>On út 16. duben 2002 14:07, Falk Brettschneider wrote:
>>>
>>>>Hi!
>>>>
>>>>I tried to compile KDE_3_0_BRANCH with using the
>>>>--enable-fast-malloc=full flag in configure, first for kdecore only,
>>>>second for the whole kdesupport, kdelibs, kdebase.
>>>>But now always I got a strange effect when closing my KDE application.
>>>>Somehow it hangs forever in an infinite loop somewhere in malloc.
>>>>Whenever I interrupt it in gdb, it shows the same callstack:
>>>> http://www.geocities.com/gigafalk/strange.jpg
>>>>
>>>Hmm. The backtrace is completely useless - the only 3 things I can see is
>>>that 1) the backtrace ends in malloc(), 2) you don't have libkdecore with
>>>debug info
>>>
>>sorry, now I recompiled kdecore with debug info and I saw it loops back
>>in line 2963 of malloc.c because there's always a p != 0.
>>
>>>even though you have it in libqt and 3) you use Keramik. Could you
>>>give me a testcase,
>>>
>>it only happens in a closed-source KDE app of the company I work for
>>here, I can't give you the code or the binary and plugins.
>>
>>>or find out where exactly in the malloc it loops?
>>>
>>I saw in the debugger that nextp is equal to p->fd and p doesn't get a
>>new pointer within the code block of the while statement. That's why it
>>loops infinitely. I don't understand what that all means though... Do
>>you have an idea?
>>
>
> Not really, but I think p->fd is a pointer to the next free block (so 
>nextp==p->fd should never happen). I think it's either deleting a block twice 
>or a write out of bounds. Valgrind will tell for sure.
>
I tried valgrind but it's in a very early stage. I gave up after every 
trial ended up with "not implemented yet in valgrind". For instance my 
app is multi-threaded, valgrind can't handle pthread. So I didn't get at 
the point where the error occurs.

>
>
>>>And first of all, could you run the application in valgrind? This malloc
>>>implementation seems to be more vulnerable to heap corruption, so it may
>>>be you have a bug somewhere and malloc in glibc gets over it somehow.
>>>Your second mail just confirms my suspicion. Most probably you're trying
>>>to delete something twice.
>>>
>>I should install valgrind...
>>
>
> 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. :-)


Cheers,
F at lk



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