-
Bug
-
Resolution: Fixed
-
P3
-
7, 8, 11, 12
-
b24
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8246322 | 13.0.4 | David Holmes | P3 | Resolved | Fixed | b04 |
JDK-8235409 | 11.0.7-oracle | David Holmes | P3 | Resolved | Fixed | b01 |
JDK-8235652 | 11.0.7 | David Holmes | P3 | Resolved | Fixed | b01 |
JDK-8243921 | openjdk8u262 | David Holmes | P3 | Resolved | Fixed | b01 |
JDK-8235477 | 8u251 | Fairoz Matte | P3 | Resolved | Fixed | b01 |
JDK-8239624 | emb-8u251 | Fairoz Matte | P3 | Resolved | Fixed | team |
JDK-8242234 | na | David Holmes | P3 | Resolved | Fixed | team |
We've tested on the following operating systems: Debian 8 and 9, and Ubuntu 16.04.
And these OpenJDK JVM runtimes: multiple versions of 1.8 between 1.8.0.121 and 1.8.0.202, 1.9, and 1.11.
A DESCRIPTION OF THE PROBLEM :
We've run into an issue where our application deadlocks, and when looking at thread dumps we see that threads are waiting for an object monitor that no other thread is currently holding. The thread that the monitor references is parked in a threadpool waiting for its next task.
Test application - https://github.com/djscholl/jemalloc-java-deadlock
Example log output when a deadlock occurred - https://gist.github.com/djscholl/413071ef29671fb53b5a64e105421f1a
See https://github.com/jemalloc/jemalloc/issues/1392 for a more detailed description.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
https://github.com/djscholl/jemalloc-java-deadlock is a test application. There is a README with instructions.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The application should finish all iterations and not exit the loop early.
ACTUAL -
The application exits the loop early because of a timeout caused by the deadlock.
---------- BEGIN SOURCE ----------
https://github.com/djscholl/jemalloc-java-deadlock
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
So far we've worked around this by not upgrading to jemalloc 5.1. jemalloc 4.5 does not seem to cause the problem. Also glibc malloc does not seem to have the problem.
FREQUENCY : occasionally
- backported by
-
JDK-8235409 Object monitor deadlock with no threads holding the monitor (using jemalloc 5.1)
- Resolved
-
JDK-8235477 Object monitor deadlock with no threads holding the monitor (using jemalloc 5.1)
- Resolved
-
JDK-8235652 Object monitor deadlock with no threads holding the monitor (using jemalloc 5.1)
- Resolved
-
JDK-8239624 Object monitor deadlock with no threads holding the monitor (using jemalloc 5.1)
- Resolved
-
JDK-8242234 Object monitor deadlock with no threads holding the monitor (using jemalloc 5.1)
- Resolved
-
JDK-8243921 Object monitor deadlock with no threads holding the monitor (using jemalloc 5.1)
- Resolved
-
JDK-8246322 Object monitor deadlock with no threads holding the monitor (using jemalloc 5.1)
- Resolved
- relates to
-
JDK-8234372 Investigate use of Thread::stack_base() and queries for "in stack"
- Resolved
-
JDK-6699669 Hotspot server leaves synchronized block with monitor in bad state
- Closed
-
JDK-8213825 assert(false) failed: Non-balanced monitor enter/exit! Likely JNI locking
- Closed