<div dir="ltr">Hi.<br><br>Thanks for the explanation.<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
The underlying problem looks familiar to me though I can't find the culprit thread in the gdb thread dump. This problem occurs when a library uses a native dynamic loader hook (I'll call it dlsym) to make a call into the JVM. This is done while holding an internal dlsym mutex lock and the end result is a deadlock if any of the other threads in the Java application need to perform a dlsym related operation (which you can see in the thread dump that they do and are all blocked on that internal mutex).<br>
<br></blockquote><div><br>I noticed this happening mostly in DB related operations. I'm using mysql-connector-java-5.1.6 which according to MySQL documentation, is "a native Java driver", and indeed doesn't seem to contain any native code library, but I wonder if this related to what you experienced in past. <br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
The culprit is whomever calls into the VM from inside the dlsym code. As I said I can't see that culprit in the stack traces, but typically it happens when someone installs an "on-load" hook or something of that nature.<font color="#888888"></font><br>
</blockquote></div><br>Is there any good way to detect the exact library causing this deadlock?<br>This happens quite rarely and spontaneously, so just disabling native libraries one by one and trying to find the cause didn't work for me.<br>
<br>Thanks again for all the help.<br></div>