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

[Lubos Lunak]

On út 16. duben 2002 21:21, Falk Brettschneider wrote:
> Hi Lubos
>
[snip]
> >>
> >>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.

 Maybe you could just add debug output to malloc() and free(), printing the 
addresses (and if this would be too much output, adding a global flag and 
enabling it only shortly before it crashes). This way you could check the 
double deleting. And you could try to make a small testcase out of your 
application.

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

 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.

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