ansaurus

Question

Answer 1

+1 A:

You've probably run into bug 6960427, which was reported against 1.6.0_20 (dead lock issue).

Are you sure that the posted stack trace is complete? You have several threads waiting to lock on 0x1d485f80, but no thread with an actual lock on that monitor.

jarnbjo 2010-08-26 15:22:06

It's appears to be a different lock that's causing the problem, but related.

Tom Hawtin - tackline 2010-08-26 15:32:13

Hi, apologies for the delay in replying, I've just got to read the responses now. With regard to the lock on 0x1d485f80, I snipped this alright, it is being held by thread 0x05913400. It looks as follows: - locked <0x1d485f80> (a com.sun.deploy.security.CPCallbackHandler$ParentCallback)

PhilDin 2010-09-06 09:06:45

[Please ignore the above comment, here's the intended one] Hi, apologies for the delay in replying, I've just got to read the responses now. With regard to the lock on 0x1d485f80, I snipped this alright, it is being held by thread 0x05913400. It looks as follows: - locked <0x1d485f80> (a com.sun.deploy.security.CPCallbackHandler$ParentCallback) Am I right in interpretting this to mean that the type of object being locked is a ParentCallback? It does look similar to bug 6960427 but I notice that in the bug report, it lists one deadlock at the end, my jstack output doesn't identify any.

PhilDin 2010-09-06 09:17:26

Answer 2

+1 A:

There's a lot of thread claiming

- waiting to lock <0x1d485f80> (a com.sun.deploy.security.CPCallbackHandler$ParentCallback)

Is that held somewhere in the snipped output?

It seems like you are intentionally mixing trusted and untrusted code ("mixed code"), which is a Bad Thing. From 6u19 a warning dialog is shown (really the attempt should be automatically blocked, but there appears to be plenty of code out there exploiting the bug). It's this warning dialog that appears to be causing the problem.

To fix, don't mix trusted and untrusted code. It's a good idea to add "Trusted-Only: true" to the manifest of each jar.

Tom Hawtin - tackline 2010-08-26 15:31:23

Hi Tom, I have had problems with trusted/untrusted code warnings but this is not intentional. I have signed all jars (my own + third party) with a self signed cert so I wasn't expecting this to be a problem. May I ask how you are able to tell this from the stack output (is it the "16.3-b01 mixed mode, sharing" line at the top?) Secondly, how can you tell from the output that the warning dialog is the problem? Thanks.

PhilDin 2010-09-06 09:42:31

The stack traces include the likes of `showMixedTrustDialog` and other threads appear to be blocking in deployment code whilst loading classes. "16.3-b01 mixed mode, sharing" refers to the version of HotSpot (now decoupled from the JRE version), the fact that it is using both the bytecode compiler and interpreter, and sharing is "Class Data Sharing" which is the use of the `classes.jsa` file that gives faster start up performance. As I say, if you add `Trusted-Only: true` to your manifests, then that should silently prevent loading untrusted code whether unintentionally of from and adversary.

Tom Hawtin - tackline 2010-09-06 12:21:48

ansaurus

tags:

views:

answers:

Help with understanding jstack output

related questions