The following tests are crashing on Apple Lion Debug WK1 (Tests) in r125427 <http://trac.webkit.org/changeset/125427>: media/controls-strict.html platform/mac/editing/pasteboard/dataTransfer-set-data-file-url.html platform/mac/accessibility/search-with-frames.html editing/pasteboard/paste-TIFF.html They are all some variant of JSC issues, but not all the same.
Two kinds of crashes, it seems. Is anyone from JSC land available to look into these? 0 com.apple.WebCore 0x0000000107f3ba4a JSC::Bindings::Instance::createRuntimeObject(JSC::ExecState*) + 218 (BridgeJSC.cpp:91) 1 com.apple.WebCore 0x000000010902bcff JSC::Bindings::convertObjcValueToValue(JSC::ExecState*, void*, JSC::Bindings::ObjcValueType, JSC::Bindings::RootObject*) + 1599 (objc_utility.mm:206) 2 com.apple.WebCore 0x0000000109027b7e JSC::Bindings::ObjcInstance::invokeDefaultMethod(JSC::ExecState*) + 1134 (objc_instance.mm:394) 3 com.apple.WebCore 0x00000001093f2b69 _ZN3JSC8BindingsL17callRuntimeObjectEPNS_9ExecStateE + 217 (runtime_object.cpp:261) ... 0 com.apple.WebCore 0x000000010bbd6c4c WebCore::JSEventListener::jsFunction(WebCore::ScriptExecutionContext*) const + 348 (JSEventListener.h:90) 1 com.apple.WebCore 0x000000010bd68cec WebCore::JSEventListener::handleEvent(WebCore::ScriptExecutionContext*, WebCore::Event*) + 220 (JSEventListener.cpp:80)
<rdar://problem/12123637>
The JSC::Bindings::Instance::createRuntimeObject(JSC::ExecState*) + 199 (BridgeJSC.cpp:91) crash has only been seen manifesting in the following 2 tests and builds (not an exhaustive list): - editing/pasteboard/paste-TIFF.html (build 1670, 1720, 2141, 2171, 2194, 2195, 2247, 2250) - platform/mac/editing/pasteboard/dataTransfer-set-data-file-url.html (build 2057, 2130, 2205, 2211) The crash is intermittent. I verified that the crash manifest on each of these tests individually by running each test alone and repeatedly. Will skip these tests until this issue is resolved.
Regarding the JSC::Bindings::Instance::createRuntimeObject(JSC::ExecState*) crash, I have to run the test repeatedly in order for the failure to manifest. This was possible with the WK1 test. On the WK2 test, the same repetition approach was not successful at manifesting the issue. This suggests that the crash could be due to either a JS JIT or GC issue that requires a warm up period. On the WK2 test run, the VM is torn down and restarted on each test. Hence, it never got a chance to warm up to the state that can manifest the issue.
The JSC::Bindings::Instance::createRuntimeObject(JSC::ExecState*) tests have been skipped in r126801: <http://trac.webkit.org/changeset/126801> (https://bugs.webkit.org/show_bug.cgi?id=95116).
JSC::Bindings::Instance::createRuntimeObject(JSC::ExecState*) crash: The earliest incident of this crash that I found was in build 1670 which circa svn rev 124953 <http://trac.webkit.org/changeset/124953>.
*** Bug 95075 has been marked as a duplicate of this bug. ***
WebCore::JSEventListener::jsFunction(WebCore::ScriptExecutionContext*) crash: - This crash manifests in the following tests (verified by running them individually and repeatedly on platform mac WK1: - fast/events/keyevent-iframe-removed-crash.html (build 2055, 2218, 2222, 2227, 2234) - fullscreen/full-screen-iframe-zIndex.html (build 2250) - fullscreen/full-screen-restrictions.html (build 2832) - http/tests/security/MessagePort/event-listener-context.html (build 2211) - platform/mac/accessibility/search-with-frames.html - svg/custom/use-instanceRoot-as-event-target.xhtml (build 2222, 2223) - in the above, I've also listed the builds where I spotted the crashes (not an exhaustive listing). - The earliest build where I saw this crash is build 1713 <http://build.webkit.org/builders/Apple%20Lion%20Debug%20WK1%20%28Tests%29/builds/1713> which is circa svn rev 125128 <http://trac.webkit.org/changeset/125128>, 125126 <http://trac.webkit.org/changeset/125126>, and 125131 <http://trac.webkit.org/changeset/125131>. - Will skip these tests to green the bots.
How did I choose which tests to skip? ======================= I manually sampled hundreds of the bot test failure results including going back to very early tests whose results are still on the server but are not conveniently presented in the waterfall results. I did this by going to the following URL for Apple Lion WK1 debug: http://build.webkit.org/builders/Apple%20Lion%20Debug%20WK1%20%28Tests%29/builds/<build number> This is how I found build 1713 which was the earliest build I saw this crash manifest on. For each occurrence of the crash stack trace I encountered, I recorded the build number and the failing test that the crash stack trace was observed on. Based on these records, I was able to observe that there is a consistency in which tests fail due to this crash. Subsequently, I run each of those tests individually and repeatedly on my local machine like so: oss/webkit4$ perl ./Tools/Scripts/run-webkit-tests --no-launch-safari --no-new-test-results --no-sample-on-timeout --results-directory ./layout-test-results --use-remote-links-to-tests --debug --no-build --exit-after-n-crashes-or-timeouts 20 --exit-after-n-failures 500 -v --repeat-each 1000 <test name> If the test crashes as expected with the same stack trace, then I consider it a worthy candidate to be skipped. The fact that it crashes suggests that this test has the trigger / originating condition for manifesting the crash. There is no guarantee that once we exclude these tests that the crashes will go away altogether. Since the crashes are intermittent, there may be a few more straggles who just haven't manifested with this symptom yet. We would expect the set of the stragglers to be less in count than the set I am now skipping. Alternatively, there's a chance that the symptom will just start manifesting on other tests. But if that case happens, then we will see a whole new set of failures with this crash of about the same size as the original set. If that occurs, we will now have evidence that the crash can occur just anywhere, and we can and should revert this current change set for skipping these tests. Note: there were some tests that were seen to manifest the crash failure, but when run alone, do not manifest the crash. This suggests that there are tests that do not have the trigger / originating condition of the crash. As a result, if we successfully skip all the tests that do trigger the crash, there is a possibility that the crash will cease to manifest. Also, the test that do not manifest the crash when run alone, though previously seen in reported bot failures, are excluded from the skip list.
WebCore::JSEventListener::jsFunction(WebCore::ScriptExecutionContext*) crash: The crashing tests have been skipped in r126821: <http://trac.webkit.org/changeset/126821> (https://bugs.webkit.org/show_bug.cgi?id=95144).
(In reply to comment #8) > WebCore::JSEventListener::jsFunction(WebCore::ScriptExecutionContext*) crash: This now only happens with svg/custom/use-instanceRoot-as-event-target.xhtml. Adam fixed some cases in bug 93654. Also, event-listener-context.html hits a different assertion failure, tracked as bug 94458.
> svg/custom/use-instanceRoot-as-event-target.xhtml Now tracked as bug 93812. So, this bug only tracks JSC::Bindings::Instance::createRuntimeObject crashes in these two tests now: - editing/pasteboard/paste-TIFF.html - platform/mac/editing/pasteboard/dataTransfer-set-data-file-url.html
> - editing/pasteboard/paste-TIFF.html This one passes now. > - platform/mac/editing/pasteboard/dataTransfer-set-data-file-url.html This one is now editing/mac/pasteboard/dataTransfer-set-data-file-url.html, and it times out. the are still skipped in TestExpectations.