In menu site: Downloads > IRS It results Webkit crash. Safari e Firefox not crash.
Created attachment 13735 [details] Console Log
Created attachment 13736 [details] Safari Crash Log
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... ]
<rdar://problem/5080340>
*** Bug 13182 has been marked as a duplicate of this bug. ***
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.
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
Checking nightly builds, r19524 does not crash, r19562 does crash
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.
Created attachment 13813 [details] Patch
(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.
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
(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.
(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!
> > 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.
Comment on attachment 13813 [details] Patch r=me
Committed by Anders in r 20502. Tweaked changelog entry to add Radar bug number in r20505.