[Bug 425723] Re: kdevelop assert failure: *** glibc detected *** kdevelop: free(): invalid pointer: 0xbfc22c44 ***

Bug Watch Updater 425723 at bugs.launchpad.net
Thu May 26 02:53:43 UTC 2011


Launchpad has imported 8 comments from the remote bug at
http://sourceware.org/bugzilla/show_bug.cgi?id=10282.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2009-06-14T23:04:15+00:00 Petr Baudis wrote:

In multi-threaded programs, we are seeing a lot of free() aborts with
MALLOC_CHECK_ turned on (our default settings) with glibc-2.10 on
openSUSE:Factory. A simple testcase is not easy to make, but I suppose
brute-forcing parallel free()s agressively enough would make it show up.

I think this locking change is the cause. In realloc_check(), the mutex is
explicitly taken when calling mem2chunk_check(), and mem2chunk_check appears to
be accessing other parts of the arena which I guess is unsafe without the mutex.

Shouldn't the mutex be held during mem2chunk_check()?

Reply at: https://bugs.launchpad.net/glibc/+bug/425723/comments/0

------------------------------------------------------------------------
On 2009-06-14T23:04:50+00:00 Petr Baudis wrote:

Created attachment 3996
proposed patch

Reply at: https://bugs.launchpad.net/glibc/+bug/425723/comments/1

------------------------------------------------------------------------
On 2009-06-15T15:42:58+00:00 Petr Baudis wrote:

It turns out that this introduces on the other hand a deadlock if
MALLOC_CHECK_=3, since malloc_printerr() tries to re-acquire the lock; the same
deadlock exists in top_check() currently, BTW.

I will attach a new patch as soon as I test it.

Reply at: https://bugs.launchpad.net/glibc/+bug/425723/comments/2

------------------------------------------------------------------------
On 2009-06-15T22:37:44+00:00 Petr Baudis wrote:

Created attachment 4001
deadlock-free proposed patch

Revised patch; unfortunately, the ATOMIC_FASTBINS stuff makes the code fairly
ugly now... getting rid of the #if 0 bit might help a little.

Without this patch, this crashes in few tens of seconds on my four-core when
run with MALLOC_CHECK_=3:

/* compile with -fopenmp */
#include <stdlib.h>
#include <unistd.h>

int main(void)
{
#pragma omp parallel num_threads(256)
  while (1) {
    void *ptr = malloc(rand() % 65536);
    usleep((rand() % 100) * 100);
    free(ptr);
    usleep((rand() % 100) * 100);
  }
  return 0;
}

Reply at: https://bugs.launchpad.net/glibc/+bug/425723/comments/3

------------------------------------------------------------------------
On 2009-11-16T23:15:02+00:00 Mpyne wrote:

I just wanted to point out that the bug is still present in glibc 2.11. The
second proposed patch works for me in both the testcase and (so far) in my KDE
workspace with MALLOC_CHECK_ enabled.

This bug is a concern for KDE developers because development versions of KDE
automatically set MALLOC_CHECK_ for glibc systems to attempt maximize early
error detection.  It's hard when merely enabling mcheck causes crashes of its
own though. Something in the combination of Qt4+glib and a couple of other KDE
programs (like Okular, KTorrent, and KNotify) trips across this race quite
frequently.

Since there appears to be a fix I'll go ahead and inform the KDE development
community so we can push for the fix to be implemented in distribution packages
while it's debated for glibc.

Reply at: https://bugs.launchpad.net/glibc/+bug/425723/comments/11

------------------------------------------------------------------------
On 2009-11-16T23:25:43+00:00 Petr Baudis wrote:

That is quite strange, this appeared to me to have been fixed right before 2.11
release. And I cannot reproduce this bug anymore with 2.11 final. Are you sure
you are seeing the bug with that glibc version? Is that vanilla or in some
distribution? Does my testcase still trigger the bug for you?

Reply at: https://bugs.launchpad.net/glibc/+bug/425723/comments/12

------------------------------------------------------------------------
On 2009-11-17T00:25:36+00:00 Mpyne wrote:

(In reply to comment #5)
> That is quite strange, this appeared to me to have been fixed right before
2.11
> release. And I cannot reproduce this bug anymore with 2.11 final. Are you
sure
> you are seeing the bug with that glibc version? Is that vanilla or in some
> distribution? Does my testcase still trigger the bug for you?

This is in glibc 2.11 as distributed by Gentoo that I see it. The vanilla USE
flag is disabled so they apply whatever Gentoo magic it is that makes things
happen. However the mcheck fix patch applied cleanly and I can't believe Gentoo
would create a patch to revert that fix.

According to gitweb the affected file (malloc/hooks.c) was last updated
2009-04-17 in the glibc 2.11 tag
(http://sourceware.org/git/?p=glibc.git;a=history;f=malloc/hooks.c;h=622a815f32

Your testcase still triggered the bug (and quite expeditiously too).

Reply at: https://bugs.launchpad.net/glibc/+bug/425723/comments/13

------------------------------------------------------------------------
On 2009-11-17T00:49:39+00:00 Petr Baudis wrote:

Aha, you are right, I'm sorry; a fix was committed right after 2.11 was tagged,
and in SUSE I took a later commit for our 2.11 build.

Anyway, I have already cherry-picked the fix for the 2.11 stable branch and this
will be included in 2.11.1, to be released before the end of November.

Reply at: https://bugs.launchpad.net/glibc/+bug/425723/comments/14


** Changed in: glibc
   Importance: Unknown => Medium

-- 
You received this bug notification because you are a member of Kubuntu
Bugs, which is subscribed to qt4-x11 in Ubuntu.
https://bugs.launchpad.net/bugs/425723

Title:
  kdevelop assert failure: *** glibc detected *** kdevelop: free():
  invalid pointer: 0xbfc22c44 ***



More information about the kubuntu-bugs mailing list