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.
Created attachment 348586 [details] dragon player received SIGABRT in free
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 "$@" Azureus TERMINATED.
One possible explanation for some of these issues on rawhide under kde is the use of MALLOC_CHECK_=2 in /usr/bin/startkde fwiw, I've disabled this (by default) for kdebase-workspace-4.2.90-3 (and newer).
Thanks, disabling that strict malloc checking solved the problem.
Well, it's more of a makes-memory-errors-nonfatal workaround ...
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.
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.
I am thinking this is a duplicate of bug #504963 ...