Bug 112523 – Crash in AXObjectCache::notificationPostTimerFired()

• Component: Accessibility
• Status: RESOLVED DUPLICATE

[Simon Fraser (smfr)]

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.

[Simon Fraser (smfr)]

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

[Simon Fraser (smfr)]

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.

[Simon Fraser (smfr)]

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()

[Simon Fraser (smfr)]

See also bug 112525

[Simon Fraser (smfr)]

See also bug 106106

[Simon Fraser (smfr)]

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?

[chris fleizach]

(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

[chris fleizach]

Duplicate of 
https://bugs.webkit.org/show_bug.cgi?id=106106

*** This bug has been marked as a duplicate of bug 106106 ***