RESOLVED FIXED Bug 13142
REGRESSION (r19559): Java applet crash
https://bugs.webkit.org/show_bug.cgi?id=13142
Summary REGRESSION (r19559): Java applet crash
José Luís Andrade
Reported 2007-03-21 08:02:52 PDT
In menu site: Downloads > IRS It results Webkit crash. Safari e Firefox not crash.
Attachments
Console Log (2.18 KB, text/plain)
2007-03-21 08:03 PDT, José Luís Andrade
no flags
Safari Crash Log (36.15 KB, text/plain)
2007-03-21 08:04 PDT, José Luís Andrade
no flags
Reduced Test case (1.08 KB, application/octet-stream)
2007-03-25 05:42 PDT, David Carson
no flags
Patch (5.59 KB, patch)
2007-03-25 07:35 PDT, David Carson
darin: review+
José Luís Andrade
Comment 1 2007-03-21 08:03:50 PDT
Created attachment 13735 [details] Console Log
José Luís Andrade
Comment 2 2007-03-21 08:04:45 PDT
Created attachment 13736 [details] Safari Crash Log
Matt Lilek
Comment 3 2007-03-21 10:56:16 PDT
Confirmed with a local build of r20355. Console spew! /Users/matt/Code/WebKit/JavaScriptCore/bindings/jni/jni_instance.cpp:343 -- JObjectWrapper: new global ref 0x7c0cb5c for 0x7c0d730 /Users/matt/Code/WebKit/JavaScriptCore/bindings/jni/jni_instance.cpp:343 -- JObjectWrapper: new global ref 0x7c0cb60 for 0x7c0d74c [snip about a dozen of the same lines] /Users/matt/Code/WebKit/JavaScriptCore/bindings/jni/jni_instance.cpp:128 -- invokeMethod: call checkVersion ()Z on 0x7c12c9c # [ timer expired, abort... ]
Mark Rowe (bdash)
Comment 4 2007-03-21 22:30:53 PDT
David Kilzer (:ddkilzer)
Comment 5 2007-03-24 15:08:21 PDT
*** Bug 13182 has been marked as a duplicate of this bug. ***
David Carson
Comment 6 2007-03-25 05:42:02 PDT
Created attachment 13812 [details] Reduced Test case Reduced test case. HTML file, compiled java file that returns a boolean (true) and the source code for the java file. Unzip and and load.
David Carson
Comment 7 2007-03-25 05:44:18 PDT
Took a look at it and resolving the JVM and the JNI calls seem quite reasonable. The crash happens in code where source is not available, MethodSwizzle onwards. #0 0x9b58e0cd in JVM_MonitorWait #1 0x9b70ca05 in JNI_GetDefaultJavaVMInitArgs_Impl #2 0x172290c1 in ConvertJavaToJValue #3 0x1722e99d in MethodSwizzle #4 0x00520a0d in KJS::Bindings::dispatchJNICall at jni_objc.mm:56 #5 0x00516fe7 in KJS::Bindings::JavaInstance::invokeMethod at jni_instance.cpp:156 #6 0x005177ff in KJS::RuntimeMethod::callAsFunction at runtime_method.cpp:89 #7 0x004fb216 in KJS::JSObject::call at object.cpp:97 #8 0x004f2164 in KJS::FunctionCallDotNode::evaluate at nodes.cpp:781 #9 0x004eb691 in KJS::AssignExprNode::evaluate at nodes.cpp:1536
David Carson
Comment 8 2007-03-25 06:09:05 PDT
Checking nightly builds, r19524 does not crash, r19562 does crash
David Carson
Comment 9 2007-03-25 06:58:50 PDT
It seems that JNIType enum defined in jni_instance.h is tightly bound with the Java implementation on Mac. Adding a type for arrays, ie array_type broke the JVM on Mac as the types were then out by one. The enum is used by jni_obj.mm to indicate the return type.
David Carson
Comment 10 2007-03-25 07:35:29 PDT
David Kilzer (:ddkilzer)
Comment 11 2007-03-25 07:42:44 PDT
(In reply to comment #8) > Checking nightly builds, r19524 does not crash, r19562 does crash This must have regressed with r19559 which fixed Bug 12636.
David Kilzer (:ddkilzer)
Comment 12 2007-03-25 08:55:39 PDT
Do the results of the WebCore/manual-tests/liveconnect-applet-array-parameters.html test change after this patch? The "Send object array" test would always throw an exception for me: /path/to/WebKit/JavaScriptCore/bindings/jni/jni_instance.cpp:128 -- invokeMethod: call objectFunction ([Ljava/applet/Applet;)V on 0xda0e6b0 /path/to/WebKit/JavaScriptCore/bindings/jni/jni_instance.cpp:139 -- invokeMethod: arg[0] = 0.1,0.1,0.2 objectArray called java.security.PrivilegedActionException: java.lang.reflect.InvocationTargetException at java.security.AccessController.doPrivileged(Native Method) at sun.plugin.liveconnect.SecureInvocation$2.run(SecureInvocation.java:212) at java.security.AccessController.doPrivileged(Native Method) at sun.plugin.liveconnect.SecureInvocation.CallMethod(SecureInvocation.java:191) at sun.plugin.liveconnect.SecureInvocation.access$300(SecureInvocation.java:51) at sun.plugin.liveconnect.SecureInvocation$CallMethodThread.run(SecureInvocation.java:122) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at sun.plugin.javascript.invoke.JSInvoke.invoke(JSInvoke.java:19) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at sun.plugin.javascript.JSClassLoader.invoke(JSClassLoader.java:44) at sun.plugin.liveconnect.PrivilegedCallMethodAction.run(SecureInvocation.java:580) ... 6 more Caused by: java.lang.NullPointerException at ArrayParameterTestApplet.objectFunction(ArrayParameterTestApplet.java:86) ... 17 more (event handler):java.security.PrivilegedActionException: java.security.PrivilegedActionException: java.lang.reflect.InvocationTargetException
David Carson
Comment 13 2007-03-25 09:02:37 PDT
(In reply to comment #12) > Do the results of the > WebCore/manual-tests/liveconnect-applet-array-parameters.html test change after > this patch? The "Send object array" test would always throw an exception for > me: That is a Java exception generated in the JVM and it was happening before. Maybe I should have been clearer in my comment in the test case, that says that it will fail.
David Kilzer (:ddkilzer)
Comment 14 2007-03-25 09:56:01 PDT
(In reply to comment #13) > (In reply to comment #12) > > Do the results of the > > WebCore/manual-tests/liveconnect-applet-array-parameters.html test change after > > this patch? The "Send object array" test would always throw an exception for > > me: > > That is a Java exception generated in the JVM and it was happening before. > Maybe I should have been clearer in my comment in the test case, that says that > it will fail. Does that only fail on Apple's JVM? For example, if the manual test were run on Windows, would it work? (This means that a bug needs to be filed with Apple's internal bug system to resolve the issue.) BTW, thanks for researching and providing a patch for this bug!
David Carson
Comment 15 2007-03-25 10:57:10 PDT
> > That is a Java exception generated in the JVM and it was happening before. > > Maybe I should have been clearer in my comment in the test case, that says that > > it will fail. > > Does that only fail on Apple's JVM? For example, if the manual test were run > on Windows, would it work? (This means that a bug needs to be filed with > Apple's internal bug system to resolve the issue.) Tested on FF in Windows, and it also fails there - as expected. Though I don't see the exception from the JVM. I don't see anything.
Darin Adler
Comment 16 2007-03-25 21:14:07 PDT
Comment on attachment 13813 [details] Patch r=me
David Kilzer (:ddkilzer)
Comment 17 2007-03-26 21:06:24 PDT
Committed by Anders in r 20502. Tweaked changelog entry to add Radar bug number in r20505.
Note You need to log in before you can comment on or make changes to this bug.