BZ #110: pthread_mutex_destroy fails when exiting Swing applications.

Status fields:

creation_ts:2008-09-18 13:04
component:locks
version:default branch
rep_platform:All
op_sys:All
bug_status:RESOLVED
resolution:INVALID
reporter:twisti@complang.tuwien.ac.at 
This happens with a number of applications, like JEdit and the SPECjvm2008 installer:

$ java -jar SPECjvm2008_1_00_setup.jar
LOG: [0x0000000040149950] Mutex::~Mutex(): pthread_mutex_destroy failedLOG:
[0x000000004018b950] : Device or resource busy
We received a SIGSEGV and tried to handle it, but we were
LOG: [0x000000004018b950] unable to find a Java method at:
LOG: [0x000000004018b950]
LOG: [0x000000004018b950] PC=0x00002b57d9994966
LOG: [0x000000004018b950]
LOG: [0x000000004018b950] Dumping the current stacktrace:
        at java.lang.Thread.isInterrupted(Z)Z(Native Method)
        at java.lang.Thread.interrupted()Z(Thread.java:890)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.checkIn
terruptWhileWaiting(Ljava/util/concurrent/locks/AbstractQueuedSynchronizer$Node;)I(Abstr
actQueuedSynchronizer.java:1940)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await()
V(AbstractQueuedSynchronizer.java:1979)
        at java.util.concurrent.DelayQueue.take()Ljava/util/concurrent/Delayed;(DelayQue
ue.java:189)
        at javax.swing.TimerQueue.run()V(TimerQueue.java:170)
        at java.lang.Thread.run()V(Thread.java:636)
LOG: [0x000000004018b950] Exiting...
LOG: [0x0000000040149950] Backtrace (8 stack frames):
LOG: [0x0000000040149950] /home/cthalinger/projects/openjdk/j2sdk-image-
cacao/jre/lib/amd64/server/libjvm.so [0x2b57d99adddb]
LOG: [0x000000004018b950] LOG: [0x0000000040149950] /home/cthalinger/projects/openjdk
/j2sdk-image-cacao/jre/lib/amd64/server/libjvm.so [0x2b57d99ad85e]
LOG: [0x0000000040149950] /home/cthalinger/projects/openjdk/j2sdk-image-
cacao/jre/lib/amd64/server/libjvm.so [0x2b57d99adac8]
LOG: [0x0000000040149950] /home/cthalinger/projects/openjdk/j2sdk-image-
cacao/jre/lib/amd64/server/libjvm.so [0x2b57d99918a4]
LOG: [0x0000000040149950] /lib/libc.so.6(exit+0x9d) [0x2b57d96339ed]
LOG: [0x0000000040149950] /home/cthalinger/projects/openjdk/j2sdk-image-
cacao/jre/lib/amd64/server/libjvm.so [0x2b57d99c04b0]
LOG: [0x0000000040149950] /home/cthalinger/projects/openjdk/j2sdk-image-
cacao/jre/lib/amd64/server/libjvm.so(JVM_Halt+0x41) [0x2b57d9990dfc]
LOG: [0x0000000040149950] [0x2aaab249bb09]

Comment #1 by stefan@complang.tuwien.ac.at on 2008-11-19 15:13:18

I actually think the best way to handle this would be to arrange for the shutdown
procedure to not destroy those mutexes.

Comment #2 by twisti@complang.tuwien.ac.at on 2008-11-19 16:05:31

And where is the point in having C++ wrappers for mutexes when the destructor does not
destroy the mutex?

Comment #3 by stefan@complang.tuwien.ac.at on 2008-11-20 11:05:43

IMHO, there's no point in destroying _anything_ at application shutdown. But that's not
the point.

I *believe* the reason for this bug is that other threads hold the mutexes that are
being destroyed here. And there is no reliable way to make them stop waiting.

Sure, one could try to shut down all threads in an orderly manner. But what if a thread
does not respond reasonably to a shutdown request? Then we wait forever instead of just
killing the remaining bits quickly and painlessly.

Comment #4 by stefan@complang.tuwien.ac.at on 2008-11-20 11:12:36

It's not that I oppose the idea of a surgically clean shutdown, when needed (might be
useful for a browser plugin). It's just that this feature would get a pretty low
priority on my list.

Comment #5 by twisti@complang.tuwien.ac.at on 2008-11-20 11:35:35

It's we are using these wrappers for other mutexes too which are destroyed during
runtime, not only at shutdown.

Comment #6 by stefan@complang.tuwien.ac.at on 2008-11-20 11:40:50

Yeah, I know that. That's why I wrote "arrange for the shutdown procedure to not destroy
those mutexes".

I meant something like this:

if (!shutdown_in_process)
  destroy_mutex()

Comment #7 by michi@complang.tuwien.ac.at on 2008-12-28 16:26:27

Created an attachment (id=55)
Simple testcase to trigger the problem

This is one of the simplest testcases I was able to come up with, to trigger this bug.
It starts a "stressing" thread which endlessly polls the isInterrupted() method on
itself. When the VM is forcefully shut down, the "stressing" thread crashes most of the
times.

Comment #8 by stefan@complang.tuwien.ac.at on 2010-12-29 20:01:02

Looks like this tests a different problem, though (PR120).

I have the impression that this doesn’t happen very frequently anymore.

Comment #9 by stefan@complang.tuwien.ac.at on 2011-08-30 14:22:00

I have an experimental branch for this.

Iteration 1 (2 changesets, original patch by Robert Schuster):
https://bitbucket.org/Ringdingcoder/cacao-dev/changeset/c391cf242d05

Iteration 2 (1 changeset, probably a better idea): https://bitbucket.org/Ringdingcoder
/cacao-dev/changeset/b658fab2a3ed

Comment #10 by stefan@complang.tuwien.ac.at on 2014-01-08 21:28:16

The code in question has seen numerous improvements, large parts of that in bug #120.
"pthread_mutex_destroy failed" can still happen, but for different reasons. I'm closing
this one now in favor of new bug #191.

Attachment id=55

date:2008-12-28 16:26
desc:Simple testcase to trigger the problem
type:text/plain
download:MutexCrash.java