JDK-8072147 : Preloading libjsig.dylib causes deadlock when signal() is called
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 8u31,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-02-02
  • Updated: 2015-11-23
  • Resolved: 2015-07-01
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 JDK 9
7u91Fixed 8u66Fixed 9 b74Fixed
Related Reports
Relates :  
JDK-8132561 - Fix for 8072147 breaks JDK 9 build with older gcc on Mac.
Description
According to Oracle's document:
    http://www.oracle.com/technetwork/java/javase/signals-139944.html#gbzcj

Applications need to preload libjsig library to enable signal chaining. However, after libjsig.dylib is preloaded, any call from native code to signal() causes a deadlock.
Comments
Suggested note: Applications need to preload the libjsig library to enable signal chaining. Previously, on OS X, after libjsig.dylib was preloaded, any call from native code to signal() caused a deadlock. This has been fixed
14-10-2015
Deadlock happens because OS X c runtime implements signal() by calling sigaction() (instead of an internal name like __sigaction()). So the sigaction() resolves back to libjsig, and we deadlock, because we are clearly not reentrant. Example hang: User stack: __psynch_mutexwait (in libsystem_kernel.dylib) + 10 (0x7fff86b8b166) signal_lock (in libjsig.dylib) + 19 (0x1072fb5e3) sigaction (in libjsig.dylib) + 24 (0x1072fba08) signal__ (in libsystem_c.dylib) + 77 (0x7fff8b70319b) call_os_signal (in libjsig.dylib) + 180 (0x1072fb6f4) set_signal (in libjsig.dylib) + 279 (0x1072fb8a7) signal (in libjsig.dylib) + 39 (0x1072fb8f7) 0x00000001071f3c7f (in cp) + 643 (0x1071f3c7f) start (in libdyld.dylib) + 1 (0x7fff858a25c9) 0x00000004 (in cp) (0x4) In other words, this single thread is "deadlocking" with itself. It has already taken the lock in signal() and then is trying to recursively retake the lock in sigaction(). As it is not a recursive lock (nor should it be), we deadlock. Can be reproduced easily with any executable that calls signal(): === DYLD_FORCE_FLAT_NAMESPACE=0 DYLD_INSERT_LIBRARIES="/Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home/jre/lib/libjsig.dylib" cp -f testfile testfile ===
29-06-2015