Various tests randomly crash in AXObjectCache::notificationPostTimerFired() e.g. svg/custom/empty-className-baseVal-crash.html http://build.webkit.org/results/Apple%20Lion%20Release%20WK2%20(Tests)/r146025%20(8956)/results.html I'm not sure why accessibility is active there.
Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000010 VM Regions Near 0x10: --> __TEXT 0000000106a44000-0000000106a47000 [ 12K] r-x/rwx SM=COW /Volumes/VOLUME/*/WebKit2.framework/WebProcess.app/Contents/MacOS/WebProcess Application Specific Information: objc[91481]: garbage collection is OFF CRASHING TEST: svg/custom/embedding-external-svgs.xhtml Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.apple.WebCore 0x0000000107790537 WebCore::AXObjectCache::notificationPostTimerFired(WebCore::Timer<WebCore::AXObjectCache>*) + 87 (RefPtr.h:58) 1 com.apple.WebCore 0x00000001084a976f WebCore::ThreadTimers::sharedTimerFiredInternal() + 175 (ThreadTimers.cpp:132) 2 com.apple.WebCore 0x000000010833b833 _ZN7WebCoreL10timerFiredEP16__CFRunLoopTimerPv + 51 (SharedTimerMac.mm:166) 3 com.apple.CoreFoundation 0x00007fff8e0d5934 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20 4 com.apple.CoreFoundation 0x00007fff8e0d5486 __CFRunLoopDoTimer + 534 5 com.apple.CoreFoundation 0x00007fff8e0b5e11 __CFRunLoopRun + 1617 6 com.apple.CoreFoundation 0x00007fff8e0b5486 CFRunLoopRunSpecific + 230 7 com.apple.HIToolbox 0x00007fff8a3852bf RunCurrentEventLoopInMode + 277 8 com.apple.HIToolbox 0x00007fff8a38c56d ReceiveNextEventCommon + 355 9 com.apple.HIToolbox 0x00007fff8a38c3fa BlockUntilNextEventMatchingListInMode + 62 10 com.apple.AppKit 0x00007fff8e322779 _DPSNextEvent + 659 11 com.apple.AppKit 0x00007fff8e32207d -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 135 12 com.apple.AppKit 0x00007fff8e31e9b9 -[NSApplication run] + 470 13 com.apple.WebCore 0x00000001082f080d WebCore::RunLoop::run() + 77 (RunLoopMac.mm:43) 14 com.apple.WebKit2 0x0000000106c9814c int WebKit::ChildProcessMain<WebKit::WebProcess, WebKit::WebContentProcessMainDelegate>(int, char**) + 696 (ChildProcessEntryPoint.h:100) 15 com.apple.WebProcess 0x0000000106a45d97 main + 307 16 com.apple.WebProcess 0x0000000106a45c5c start + 52
It seems that if any test in a shard does accessibility, then accessibility remains on for the other tests in that process. That's unfortunate.
void Document::clearAXObjectCache() { // Clear the cache member variable before calling delete because attempts // are made to access it during destruction. topDocument()->m_axObjectCache.release(); } Two things odd: 1. Why might a subframe nuke the accessibility cache on the top document? Is this because we're unable to remove just a subframes accessibility objects from the cache, or a mistake? 2. .release() should be .clear()
See also bug 112525
See also bug 106106
Something very odd is happening with accessibility. See this sample: http://build.webkit.org/results/Apple%20MountainLion%20Debug%20WK2%20(Tests)/r146032%20(7849)/svg/wicd/sizing-flakiness-sample.txt notably: 911 WebCore::ThreadTimers::sharedTimerFiredInternal() (in WebCore) + 302 [0x1134a177e] ThreadTimers.cpp:129 911 WebCore::Timer<WebCore::AXObjectCache>::fired() (in WebCore) + 115 [0x111a19823] Timer.h:113 911 WebCore::AXObjectCache::notificationPostTimerFired(WebCore::Timer<WebCore::AXObjectCache>*) (in WebCore) + 400 [0x1119cbcd0] AXObjectCache.cpp:645 911 WebCore::AXObjectCache::postPlatformNotification(WebCore::AccessibilityObject*, WebCore::AXObjectCache::AXNotification) (in WebCore) + 597 [0x111b011e5] AXObjectCacheMac.mm:131 911 -[WebAccessibilityObjectWrapperBase accessibilityPostedNotification:] (in WebCore) + 161 [0x1134f70b1] WebAccessibilityObjectWrapperBase.mm:240 911 -[NSNotificationCenter postNotificationName:object:userInfo:] (in Foundation) + 64 [0x7fff918abe26] 911 _CFXNotificationPost (in CoreFoundation) + 2554 [0x7fff9351deda] 907 -[AccessibilityNotificationHandler _notificationReceived:] (in WebKitTestRunnerInjectedBundle) + 681 [0x119ea0fa9] AccessibilityNotificationHandler.mm:136 ! 907 JSObjectCallAsFunction (in JavaScriptCore) + 523 [0x110c5b56b] JSObjectRef.cpp:468 ! 907 JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) (in JavaScriptCore) + 306 [0x1109b3782] CallData.cpp:40 ! 907 JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) (in JavaScriptCore) + 1519 [0x110ba61cf] Interpreter.cpp:1059 ! 907 JSC::JITCode::execute(JSC::JSStack*, JSC::ExecState*, JSC::JSGlobalData*) (in JavaScriptCore) + 84 [0x110ba8f24] JITCode.h:135 ! 907 ??? (in JavaScriptCore) load address 0x110939000 + 0x2b3250 [0x110bec250] ! 796 cti_op_put_by_id_generic (in JavaScriptCore) + 203 [0x110bdfdfb] JITStubs.cpp:1415 ! : 796 JSC::JSValue::put(JSC::ExecState*, JSC::PropertyName, JSC::JSValue, JSC::PutPropertySlot&) (in JavaScriptCore) + 185 [0x110ad0859] JSCJSValueInlines.h:678 The test is svg/wicd/sizing-flakiness.html, which has nothing to do with accessibility. So why is an accessibility notification firing, and why is it running JS code?
(In reply to comment #6) > Something very odd is happening with accessibility. See this sample: > http://build.webkit.org/results/Apple%20MountainLion%20Debug%20WK2%20(Tests)/r146032%20(7849)/svg/wicd/sizing-flakiness-sample.txt > > notably: > 911 WebCore::ThreadTimers::sharedTimerFiredInternal() (in WebCore) + 302 [0x1134a177e] ThreadTimers.cpp:129 > 911 WebCore::Timer<WebCore::AXObjectCache>::fired() (in WebCore) + 115 [0x111a19823] Timer.h:113 > 911 WebCore::AXObjectCache::notificationPostTimerFired(WebCore::Timer<WebCore::AXObjectCache>*) (in WebCore) + 400 [0x1119cbcd0] AXObjectCache.cpp:645 > 911 WebCore::AXObjectCache::postPlatformNotification(WebCore::AccessibilityObject*, WebCore::AXObjectCache::AXNotification) (in WebCore) + 597 [0x111b011e5] AXObjectCacheMac.mm:131 > 911 -[WebAccessibilityObjectWrapperBase accessibilityPostedNotification:] (in WebCore) + 161 [0x1134f70b1] WebAccessibilityObjectWrapperBase.mm:240 > 911 -[NSNotificationCenter postNotificationName:object:userInfo:] (in Foundation) + 64 [0x7fff918abe26] > 911 _CFXNotificationPost (in CoreFoundation) + 2554 [0x7fff9351deda] > 907 -[AccessibilityNotificationHandler _notificationReceived:] (in WebKitTestRunnerInjectedBundle) + 681 [0x119ea0fa9] AccessibilityNotificationHandler.mm:136 > ! 907 JSObjectCallAsFunction (in JavaScriptCore) + 523 [0x110c5b56b] JSObjectRef.cpp:468 > ! 907 JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) (in JavaScriptCore) + 306 [0x1109b3782] CallData.cpp:40 > ! 907 JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) (in JavaScriptCore) + 1519 [0x110ba61cf] Interpreter.cpp:1059 > ! 907 JSC::JITCode::execute(JSC::JSStack*, JSC::ExecState*, JSC::JSGlobalData*) (in JavaScriptCore) + 84 [0x110ba8f24] JITCode.h:135 > ! 907 ??? (in JavaScriptCore) load address 0x110939000 + 0x2b3250 [0x110bec250] > ! 796 cti_op_put_by_id_generic (in JavaScriptCore) + 203 [0x110bdfdfb] JITStubs.cpp:1415 > ! : 796 JSC::JSValue::put(JSC::ExecState*, JSC::PropertyName, JSC::JSValue, JSC::PutPropertySlot&) (in JavaScriptCore) + 185 [0x110ad0859] JSCJSValueInlines.h:678 > > The test is svg/wicd/sizing-flakiness.html, which has nothing to do with accessibility. So why is an accessibility notification firing, and why is it running JS code? (In reply to comment #6) > Something very odd is happening with accessibility. See this sample: > http://build.webkit.org/results/Apple%20MountainLion%20Debug%20WK2%20(Tests)/r146032%20(7849)/svg/wicd/sizing-flakiness-sample.txt > > notably: > 911 WebCore::ThreadTimers::sharedTimerFiredInternal() (in WebCore) + 302 [0x1134a177e] ThreadTimers.cpp:129 > 911 WebCore::Timer<WebCore::AXObjectCache>::fired() (in WebCore) + 115 [0x111a19823] Timer.h:113 > 911 WebCore::AXObjectCache::notificationPostTimerFired(WebCore::Timer<WebCore::AXObjectCache>*) (in WebCore) + 400 [0x1119cbcd0] AXObjectCache.cpp:645 > 911 WebCore::AXObjectCache::postPlatformNotification(WebCore::AccessibilityObject*, WebCore::AXObjectCache::AXNotification) (in WebCore) + 597 [0x111b011e5] AXObjectCacheMac.mm:131 > 911 -[WebAccessibilityObjectWrapperBase accessibilityPostedNotification:] (in WebCore) + 161 [0x1134f70b1] WebAccessibilityObjectWrapperBase.mm:240 > 911 -[NSNotificationCenter postNotificationName:object:userInfo:] (in Foundation) + 64 [0x7fff918abe26] > 911 _CFXNotificationPost (in CoreFoundation) + 2554 [0x7fff9351deda] > 907 -[AccessibilityNotificationHandler _notificationReceived:] (in WebKitTestRunnerInjectedBundle) + 681 [0x119ea0fa9] AccessibilityNotificationHandler.mm:136 > ! 907 JSObjectCallAsFunction (in JavaScriptCore) + 523 [0x110c5b56b] JSObjectRef.cpp:468 > ! 907 JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) (in JavaScriptCore) + 306 [0x1109b3782] CallData.cpp:40 > ! 907 JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) (in JavaScriptCore) + 1519 [0x110ba61cf] Interpreter.cpp:1059 > ! 907 JSC::JITCode::execute(JSC::JSStack*, JSC::ExecState*, JSC::JSGlobalData*) (in JavaScriptCore) + 84 [0x110ba8f24] JITCode.h:135 > ! 907 ??? (in JavaScriptCore) load address 0x110939000 + 0x2b3250 [0x110bec250] > ! 796 cti_op_put_by_id_generic (in JavaScriptCore) + 203 [0x110bdfdfb] JITStubs.cpp:1415 > ! : 796 JSC::JSValue::put(JSC::ExecState*, JSC::PropertyName, JSC::JSValue, JSC::PutPropertySlot&) (in JavaScriptCore) + 185 [0x110ad0859] JSCJSValueInlines.h:678 > > The test is svg/wicd/sizing-flakiness.html, which has nothing to do with accessibility. So why is an accessibility notification firing, and why is it running JS code? It's informing the layout test that an accessibility notification (like ValueChanged perhaps) fired. It does that by storing a function callback which it will call when the notification comes in. However, things should be cleaned up when the test finishes, which is obviously not happening
Duplicate of https://bugs.webkit.org/show_bug.cgi?id=106106 *** This bug has been marked as a duplicate of bug 106106 ***