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

Bug #425723 reported by Mateusz
184
This bug affects 21 people
Affects Status Importance Assigned to Milestone
GLibC
Fix Released
Medium
KDevelop
Invalid
High
eglibc (Ubuntu)
High
Unassigned
Karmic
High
Unassigned
kdevelop (Ubuntu)
Low
Unassigned
Karmic
Undecided
Unassigned
qt4-x11 (Ubuntu)
Undecided
Unassigned
Karmic
Undecided
Unassigned

Bug Description

Binary package hint: kdevelop

I created new project: "qt4 cmake gui application" with subversion system. For subversion repository I entered "localhost" (probably wrong, I was just playing with it). After clicking Finish kdevelop hanged so I closed it (it closed instantly without hanging my destkop for a second). Apport showed up a minute after closing.

ProblemType: Crash
Architecture: i386
AssertionMessage: *** glibc detected *** kdevelop: free(): invalid pointer: 0xbfc22c44 ***
Date: Mon Sep 7 15:28:48 2009
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/bin/kdevelop
Package: kdevelop 4:3.9.95-0ubuntu2
ProcCmdline: /usr/bin/kdevelop
ProcEnviron:
 LANGUAGE=pl_PL:pl:en_GB:en
 LANG=pl_PL.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-9.29-generic
Signal: 6
SourcePackage: kdevelop
StacktraceTop:
 __kernel_vsyscall ()
 raise () from /lib/tls/i686/cmov/libc.so.6
 abort () from /lib/tls/i686/cmov/libc.so.6
 ?? () from /lib/tls/i686/cmov/libc.so.6
 ?? () from /lib/tls/i686/cmov/libc.so.6
Title: kdevelop assert failure: *** glibc detected *** kdevelop: free(): invalid pointer: 0xbfc22c44 ***
Uname: Linux 2.6.31-9-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

Revision history for this message
In , Petr Baudis (pasky) 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()?

Revision history for this message
In , Petr Baudis (pasky) wrote :

Created attachment 3996
proposed patch

Revision history for this message
In , Petr Baudis (pasky) 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.

Revision history for this message
In , Petr Baudis (pasky) 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;
}

Revision history for this message
Mateusz (mateuszzz88) wrote :
Revision history for this message
Apport retracing service (apport) wrote : Stacktrace.txt (retraced)

StacktraceTop:__kernel_vsyscall ()
*__GI_raise (sig=6)
*__GI_abort () at abort.c:92
__libc_message (do_abort=2,
malloc_printerr (action=<value optimized out>,

Revision history for this message
Apport retracing service (apport) wrote : ThreadStacktrace.txt (retraced)
Changed in kdevelop (Ubuntu):
importance: Undecided → Medium
tags: removed: need-i386-retrace
visibility: private → public
Revision history for this message
Jonathan Thomas (echidnaman) wrote :

Thank you for your bug report. This bug has been reported to the developers of the software. You can track it and make comments at: https://bugs.kde.org/show_bug.cgi?id=206665

Changed in kdevelop (Ubuntu):
importance: Medium → Low
status: New → Triaged
Revision history for this message
Jonathan Thomas (echidnaman) wrote :

...and of course Vang Kofoed is not the KDevelop upstream project... :/

Changed in vagnk:
importance: Unknown → Undecided
status: Unknown → New
status: New → Invalid
affects: vagnk → kdevelop4
Changed in kdevelop4:
importance: Undecided → Unknown
status: Invalid → Unknown
Revision history for this message
Jonathan Thomas (echidnaman) wrote :

From upstream:
"The problem is either in Qt or libc 2.10, not in kdevelop. The "workaround" is
already applied by KDE 4.3's startkde script, for usage in other DE's setting
MALLOC_CHECK=1 makes libc not abort the application. For more information see
http://www.gnu.org/s/libc/manual/html_node/Heap-Consistency-Checking.html"

Changed in kdevelop4:
status: Unknown → Invalid
Changed in kdevelop (Ubuntu):
status: Triaged → Invalid
Revision history for this message
In , Mpyne (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.

Revision history for this message
In , Petr Baudis (pasky) 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?

Revision history for this message
In , Mpyne (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).

Revision history for this message
In , Petr Baudis (pasky) 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.

Revision history for this message
Jonathan Thomas (echidnaman) wrote :
Changed in qt4-x11 (Ubuntu):
status: New → Invalid
Changed in eglibc (Ubuntu):
importance: Undecided → High
status: New → Triaged
Changed in glibc:
status: Unknown → Fix Released
Colin Watson (cjwatson)
Changed in kdevelop (Ubuntu Karmic):
status: New → Invalid
Changed in qt4-x11 (Ubuntu Karmic):
status: New → Invalid
Changed in eglibc (Ubuntu Karmic):
status: New → Triaged
importance: Undecided → High
Revision history for this message
Colin Watson (cjwatson) wrote :

The upstream change that fixed this bug is:

  http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=cc49a5a8837be1f9307b167d9bf4399798a847c9

Minus spurious whitespace changes, it's short. Attached.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package eglibc - 2.10.2-2ubuntu4

---------------
eglibc (2.10.2-2ubuntu4) lucid; urgency=low

  * Update to r9527 from the eglibc-2.10 branch.
    - LP: #425723.
  * Merge with Debian (r4032, trunk).
  * Rebuild to link with --hash-style=both on armel.
 -- Matthias Klose <email address hidden> Wed, 23 Dec 2009 21:40:58 +0100

Changed in eglibc (Ubuntu):
status: Triaged → Fix Released
Matthias Klose (doko)
Changed in eglibc (Ubuntu Karmic):
status: Triaged → In Progress
Revision history for this message
Sami Nieminen (sami-nieminen) wrote :

Is the fix for libc6-686 available for Karmic somewhere? I am experiencing the free() bug quite much with kde desktop and the kde developers told it is due to this glibc problem mentioned here.

Revision history for this message
Scott Kitterman (kitterman) wrote :

Using the dgetlp (from the ubuntu-dev-tools package, you can:

dgetlp http://launchpadlibrarian.net/37155676/eglibc_2.10.1-0ubuntu16.dsc

and get the source for the proposed fix for Karmic and build it yourself.

Revision history for this message
Martin Pitt (pitti) wrote : Please test proposed package

Accepted eglibc into karmic-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in eglibc (Ubuntu Karmic):
status: In Progress → Fix Committed
tags: added: verification-needed
Revision history for this message
Tomasz Czapiewski (xeros) wrote :

I've had this issue (crashes like this one) with digiKam (reported bug 497562) and amaroK with KDE 4.4 Beta 2 on Karmic and the upgrade of libc packages from 2.10.1-0ubuntu15 to 2.10.1-0ubuntu16 (from karmic-proposed repository) solved it. Thanks for Luka Renko for link to this bug report and for yours fix.

Revision history for this message
Sami Nieminen (sami-nieminen) wrote :

New eglibc solved my crashes as well. Thanks!

Martin Pitt (pitti)
tags: added: verification-done
removed: verification-needed
Revision history for this message
Alex Sidorenko (asid) wrote :

Fixed my crashes of digikam in KDE-4.4RC1 as well!

Cheers,
Alex

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package eglibc - 2.10.1-0ubuntu16

---------------
eglibc (2.10.1-0ubuntu16) karmic-proposed; urgency=low

  [ Martin Pitt ]
  * debian/patches/series: Apply any/local-ipv6-lookup.diff again to fix
    painfully long timeouts on DNS resolution, if routers do not send an
    answer to AAAA (IPv6) DNS queries. With this patch those DNS requests are
    not sent in the first place if there are no routable IPV6 interfaces.
    (LP: #417757) This reopens LP #239701, #374674, so a full solution would
    need to fix the patch properly.

  [ Matthias Klose ]
  * patches/any/cvs-malloc-check.diff: new patch from upstream to fix bugs
    with MALLOC_CHECK. Closes: #557158. LP: #425723.
 -- Matthias Klose <email address hidden> Thu, 24 Dec 2009 11:16:36 +0100

Changed in eglibc (Ubuntu Karmic):
status: Fix Committed → Fix Released
Changed in kdevelop4:
status: Invalid → Unknown
Changed in kdevelop4:
importance: Unknown → High
status: Unknown → Invalid
Changed in glibc:
importance: Unknown → Medium
Revision history for this message
In , Neleai (neleai) wrote :

*** Bug 770 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Jackie-rosen (jackie-rosen) wrote :

*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.