<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&#39;t find the culprit thread in the gdb thread dump. This problem occurs when a library uses a native dynamic loader hook (I&#39;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&#39;m using mysql-connector-java-5.1.6 which according to MySQL documentation, is &quot;a native Java driver&quot;, and indeed doesn&#39;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&#39;t see that culprit in the stack traces, but typically it happens when someone installs an &quot;on-load&quot; 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&#39;t work for me.<br>

<br>Thanks again for all the help.<br></div>