Bug 506854 - Crashes in memory handling
Crashes in memory handling
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Andreas Schwab
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-06-18 18:19 EDT by Clemens Eisserer
Modified: 2009-08-25 21:46 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-24 12:34:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
dragon player received SIGABRT in free (10.05 KB, application/octet-stream)
2009-06-18 20:21 EDT, Clemens Eisserer
no flags Details

  None (edit)
Description Clemens Eisserer 2009-06-18 18:19:23 EDT
Description of problem:

For some time now I see a lot of crashes for both KDE and Java programs.

The JVM's I tested were OpenJDK as well as Sun's JRE, both often don't survive a night running Azureus. When they die they receive SIGABRT and most of the time don't create a hs_err file (only 2 times out of ~30 crashes).

Also KDE programs often seem to fail in glibc's free memory management function.

I attached a few stack-traces of different programs where it happend.
It happend way more often, but I have't always been successful getting stack-traces.

Version-Release number of selected component (if applicable):
Fedora - 20090618

I have checked for faulty hardware using memtest86+ for a whole night, no errors showed up.
Comment 1 Clemens Eisserer 2009-06-18 20:21:31 EDT
Created attachment 348586 [details]
dragon player received SIGABRT in free
Comment 2 Clemens Eisserer 2009-06-18 21:07:54 EDT
This is the message I got when azureus crashed after 2min uptime, no hs_err_pid file was generated:

Programme/azureus/azureus: line 113:  2156 Aborted                 /home/ce/Programme/jdk7b59/bin/java -server -XX:+AggressiveOpts -XX:+DoEscapeAnalysis -Xms16m -Xmx256m -XX:+UseSerialGC -XX:MaxDirectMemorySize=256m -cp "${CLASSPATH}" -Djava.library.path="${PROGRAM_DIR}" -Dazureus.install.path="${PROGRAM_DIR}" org.gudy.azureus2.ui.swt.Main "$@"
Comment 3 Rex Dieter 2009-06-18 23:29:41 EDT
One possible explanation for some of these issues on rawhide under kde is the use of 
in /usr/bin/startkde

fwiw, I've disabled this (by default) for kdebase-workspace-4.2.90-3 (and newer).
Comment 4 Clemens Eisserer 2009-07-24 12:33:52 EDT
Thanks, disabling that strict malloc checking solved the problem.
Comment 5 Rex Dieter 2009-07-24 12:37:11 EDT
Well, it's more of a makes-memory-errors-nonfatal workaround ...
Comment 6 Clemens Eisserer 2009-07-24 13:01:19 EDT
I am still no convinced that glibc's checking isn't flawed somehow.

I got errors for applications that usually run for months without problems (like java), and don't cause any troubles now with the checks disabled.
Comment 7 Tom Lane 2009-08-25 13:49:48 EDT
FWIW, I am seeing problems in this area in mysql also --- with MALLOC_CHECK_=3 I get random complaints about free() calls, but they're not reproducible, and in most cases it doesn't look like the calling code could possibly be wrong.
Comment 8 Tom Lane 2009-08-25 21:46:15 EDT
I am thinking this is a duplicate of bug #504963 ...

Note You need to log in before you can comment on or make changes to this bug.