Bug 127387 – AX: Crash in WebKit::WebPageProxy::registerWebProcessAccessibilityToken

• Status: RESOLVED
• Resolution: FIXED
• Component: Accessibility

[chris fleizach]

37 com.apple.WebKit2:  WebKit::WebPageProxy::registerWebProcessAccessibilityToken + 11 <==
        37 com.apple.WebKit2:  WebKit::WebPageProxy::didReceiveMessage + 7257
          37 com.apple.WebKit2:  CoreIPC::MessageReceiverMap::dispatchMessage + 125
            37 com.apple.WebKit2:  WebKit::ChildProcessProxy::dispatchMessage + 13
              37 com.apple.WebKit2:  WebKit::WebProcessProxy::didReceiveMessage + 24
                37 com.apple.WebKit2:  CoreIPC::Connection::dispatchMessage + 101
                  37 com.apple.WebKit2:  CoreIPC::Connection::dispatchOneMessage + 106
                    28 com.apple.WebCore:  WebCore::RunLoop::performWork + 270
                    | 28 com.apple.WebCore:  WebCore::RunLoop::performWork + 34
                    |   28 com.apple.CoreFoundation:  __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
                    |     28 com.apple.CoreFoundation:  __CFRunLoopDoSources0 + 242
                    |       28 com.apple.CoreFoundation:  __CFRunLoopRun + 831
                    |         28 com.apple.CoreFoundation:  CFRunLoopRunSpecific + 309
                    |           28 com.apple.HIToolbox:  RunCurrentEventLoopInMode + 226
                    |             28 com.apple.HIToolbox:  ReceiveNextEventCommon + 479
                    |               28 com.apple.HIToolbox:  _BlockUntilNextEventMatchingListInModeWithFilter + 65
                    |                 28 com.apple.AppKit:  _DPSNextEvent + 1434
                    |                   28 com.apple.AppKit:  -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122
                    |                     28 com.apple.AppKit:  -[NSApplication run] + 553
                    |                       28 com.apple.quicklook.ui.helper:  main
                    |                         28 libdyld.dylib:  start + 1
                    9 com.apple.WebCore:  WebCore::RunLoop::performWork + 557
                      9 com.apple.WebCore:  WebCore::RunLoop::performWork + 34
                        9 com.apple.CoreFoundation:  __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
                          9 com.apple.CoreFoundation:  __CFRunLoopDoSources0 + 242
                            9 com.apple.CoreFoundation:  __CFRunLoopRun + 831
                              9 com.apple.CoreFoundation:  CFRunLoopRunSpecific + 309
                                9 com.apple.HIToolbox:  RunCurrentEventLoopInMode + 226
                                  9 com.apple.HIToolbox:  ReceiveNextEventCommon + 479
                                    9 com.apple.HIToolbox:  _BlockUntilNextEventMatchingListInModeWithFilter + 65
                                      9 com.apple.AppKit:  _DPSNextEvent + 1434
                                        9 com.apple.AppKit:  -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122
                                          9 com.apple.AppKit:  -[NSApplication run] + 553
                                            9 com.apple.quicklook.ui.helper:  main
                                              9 libdyld.dylib:  start + 1

<rdar://problem/15723355>
<rdar://probl;e

[chris fleizach]

Created attachment 221815 [details]
patch

[Alexey Proskuryakov]

Comment on attachment 221815 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=221815&action=review

> Source/WebKit2/UIProcess/mac/WebPageProxyMac.mm:390
> +    if (!isValid())
> +        return;

Is it semantically correct to ignore this call, or should the data be queued and sent once the process is (re)started?

[chris fleizach]

(In reply to comment #2)
> (From update of attachment 221815 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=221815&action=review
> 
> > Source/WebKit2/UIProcess/mac/WebPageProxyMac.mm:390
> > +    if (!isValid())
> > +        return;
> 
> Is it semantically correct to ignore this call, or should the data be queued and sent once the process is (re)started?

Good question. I should play with this some more

[WebKit Commit Bot]

Comment on attachment 221815 [details]
patch

Clearing flags on attachment: 221815

Committed r164887: <http://trac.webkit.org/changeset/164887>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.