Eric Feigenson wrote:
>And it actually worked. I didn't think it would, only because the Java
>code is run via JNI calls, and the C/C++ program running everything
>generally traps signals. But not SIGQUIT apparently. Thank goodness.
It may be the JVM overrode a SIGQUIT handler previously installed. It will
normally install several signal handlers, so it can catch TERM, INT, and
HUP to terminate properly (it triggers shutdown hooks).
The JVM option to suppress all these signal handlers is -Xrs. In Terminal,
'java -X' by itself emits a brief summary. For more info, read 'man java'
and look for the -Xrs option. I also think there's some info in the JNI
reference guide about terminating a JVM cleanly when it doesn't have its
own signal handlers.
>So, the question now seems to be: Why, in Thread-0, is
>java.lang.ClassLoader$NativeLibrary.load just sitting there (yes, I know
>it's shown as "suspended" in the stack trace, but that's just because it's
>paused in the debugger! Normally, it's running). What could it be waiting
>on?
It could just be waiting for you to hit "run" in the debugger. Seriously.
I suggest running the program without the debugger, and without suspending
any threads. If you still get a hang, then at that point you can still
issue 'kill -QUIT pid', which might then show you an actual deadlock.
Right now, the only deadlock I can see is self-induced because the debugger
has suspended a thread holding locks that other threads need to progress.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
