java/lc3/instanceof/instanceof-001.html crashed on Snow Leopard Debug Bot Is this just another test which needs new sekret Safari bits updated in order to pass? http://build.webkit.org/results/SnowLeopard%20Intel%20Leaks/r56893%20(5476)/java/lc3/instanceof/instanceof-001-stderr.txt ERROR: could not show status message (Applet lc3 stopped) because plug-in has already been destroyed (/Volumes/Data/WebKit-BuildSlave/snowleopard-intel-leaks/build/WebKit/mac/Plugins/WebPluginController.mm:360 void -[WebPluginController webPlugInContainerShowStatus:](WebPluginController*, objc_selector*, NSString*)) ERROR: could not show status message (Applet lc3 destroyed) because plug-in has already been destroyed (/Volumes/Data/WebKit-BuildSlave/snowleopard-intel-leaks/build/WebKit/mac/Plugins/WebPluginController.mm:360 void -[WebPluginController webPlugInContainerShowStatus:](WebPluginController*, objc_selector*, NSString*)) ASSERTION FAILED: _haveAdditionalClip (/Volumes/Data/WebKit-BuildSlave/snowleopard-intel-leaks/build/WebKit/mac/WebView/WebClipView.m:72 -[WebClipView resetAdditionalClip]) http://trac.webkit.org/browser/trunk/LayoutTests/java/lc3/instanceof/instanceof-001.html
I'm told this is caused by Java working with WebViews from secondary threads - other assertions in WebClipView.m can fail because of this, too. It's reasonably safe in release builds. Maybe there is way to change this assertion to not fire in such cases. We could skip the assertion if one of the clip-related methods was ever called from a secondary thread for this particular view.
…or perhaps turn the “additional clip”-related methods into no-ops when called on a secondary thread.
More (seemingly related) failures: http://build.webkit.org/results/SnowLeopard%20Intel%20Leaks/r56902%20(5485)/results.html http://build.webkit.org/results/SnowLeopard%20Intel%20Leaks/r56902%20(5485)/java/lc3/ConvertString/string-006-diffs.txt --- /Volumes/Data/WebKit-BuildSlave/snowleopard-intel-leaks/build/layout-test-results/java/lc3/ConvertString/string-006-expected.txt 2010-04-01 01:16:24.000000000 -0700 +++ /Volumes/Data/WebKit-BuildSlave/snowleopard-intel-leaks/build/layout-test-results/java/lc3/ConvertString/string-006-actual.txt 2010-04-01 01:16:24.000000000 -0700 @@ -1,3 +1,5 @@ +Invalid memory access of location 0xbbadbeef rip=0x10077e6bc + LiveConnect 3.0 JavaScript to Java Data Type Conversion Preferred argument conversion: string FAIL TEST_CLASS["ambiguous(java.lang.String)"](string) + '' should be STRING. Threw exception TypeError: Result of expression 'TEST_CLASS["ambiguous(java.lang.String)"]' [undefined] is not a function.
Different Java test, same assert: http://build.webkit.org/results/SnowLeopard%20Intel%20Leaks/r57311%20(5775)/java/lc3/ConvertString/string-001-stderr.txt java/lc3/ConvertString/string-001.html
There is an old bug with a similar signature. Bug 9141. I wonder if they're related at all.
*** Bug 56569 has been marked as a duplicate of this bug. ***
This just happened again: http://build.webkit.org/results/SnowLeopard%20Intel%20Leaks/r81398%20(15647)/java/lc3/JavaClass/ToJSObject-001-crash-log.txt
Just happened again! http://build.webkit.org/results/SnowLeopard%20Intel%20Leaks/r81472%20(15664)/results.html
The assertion should be removed, since it’s known to be false.
Per earlier discussion, isn't this a good assertion that Java does violate? Your suggestion in comment 2 seems safer if that's the case.
(In reply to comment #10) > Per earlier discussion, isn't this a good assertion that Java does violate? Your suggestion in comment 2 seems safer if that's the case. I agree with my suggestion in comment 2 and with comment 9.