Crash on OS X 10.5.6 Mac with -Xcheck:jni set
Status: Beta
Brought to you by:
smichaud
Menu
▾
▴
#106 Crash on OS X 10.5.6 Mac with -Xcheck:jni set
When loading an applet (no matter which) the Browser crashes when the -Xcheck:jni runtime applet parameter is set.
This is PPC only
MacOS X 10.4 and 10.5
Firefox 3.x, Camino 1.6, SeaMonkey 1.1.13
Does NOT crash with Firefox 2.x
Works fine with Safari.
How to reproduce:
set -Xcheck:jni Java applet runtime parameter via the Java Preferences application in /Applications/Utilities.
Launch an Applet.
i.e. http://java.sun.com/products/plugin/1.4/demos/applets/TicTacToe/example1.html
It starts to load and then the browser crashes.
I can confirm your report ... sort of.
In my tests, if -Xcheck:jni is included in the JVM's runtime
parameters, Firefox (all versions) always crashes on loading a Java
applet (any applet) when running on OS X 10.5.6. But there's no crash
on OS X 10.4.11.
Whenever I see a crash, I also see the following error in the system
console (not the Java console):
FATAL ERROR in native method: JNI call made with exception pending.
(In their latest JVM for OS X 10.5.X, Apple has made it difficult to
specify runtime parameters for Java applets. You need to edit the
deployment.javapi.jre.1.5.0.args property in
~/Library/Caches/Java/deployment.properties.)
-Xcheck:jni is used to debug problems with the JNI (Java Native
Interface). So it seems that the additional checking done by
-Xcheck:jni is what's crashing the JEP (and the browser).
The JNI is (of necessity) used by the JEP, but isn't accessible to
applets. So I wonder why you're using this setting.
You might respond that you're testing the JEP itself. In principle,
the JEP should be able to run without -Xcheck:jni showing errors.
This is something I intend to work on in the future. But I wonder how
seriously to take the -Xcheck:jni errors -- especially given the fact
the JEP seems to work fine without -Xcheck:jni. I suspect many of
these errors are due to the fact that the JEP runs many basic JVM
functions on the main thread that Safari usually runs on secondary
threads.
So at some point I'm going to look further into using -Xcheck:jni with
the JEP, but I'm not going to make it a high priority.
I can confirm your report ... sort of.
In my tests, if -Xcheck:jni is included in the JVM's runtime
parameters, Firefox (all versions) always crashes on loading a Java
applet (any applet) when running on OS X 10.5.6. But there's no crash
on OS X 10.4.11.
Whenever I see a crash, I also see the following error in the system
console (not the Java console):
FATAL ERROR in native method: JNI call made with exception pending.
(In their latest JVM for OS X 10.5.X, Apple has made it difficult to
specify runtime parameters for Java applets. You need to edit the
deployment.javapi.jre.1.5.0.args property in
~/Library/Caches/Java/deployment.properties.)
-Xcheck:jni is used to debug problems with the JNI (Java Native
Interface). So it seems that the additional checking done by
-Xcheck:jni is what's crashing the JEP (and the browser).
The JNI is (of necessity) used by the JEP, but isn't accessible to
applets. So I wonder why you're using this setting.
You might respond that you're testing the JEP itself. In principle,
the JEP should be able to run without -Xcheck:jni showing errors.
This is something I intend to work on in the future. But I wonder how
seriously to take the -Xcheck:jni errors -- especially given the fact
the JEP seems to work fine without -Xcheck:jni. I suspect many of
these errors are due to the fact that the JEP runs many basic JVM
functions on the main thread that Safari usually runs on secondary
threads.
So at some point I'm going to look further into using -Xcheck:jni with
the JEP, but I'm not going to make it a high priority.
Sorry for adding the same comment twice: Some kind of interface wierdness.
I had crashes with a JNI lib, that's why I turned on -Xcheck:jni!
FYI: With this lib it crashed only on PPC, very early when loading the library.
Maybe I find some more information, I'll keep you updated.