1187055 - crash in mozilla::a11y::ProxyDestroyed(mozilla::a11y::ProxyAccessible*)

Status: RESOLVED FIXED

Description

[David Major [:dmajor]]

This bug was filed from the Socorro interface and is 
report bp-ec4bb98f-29a2-4481-9a98-d03ed2150722.
=============================================================

This spiked in nightly 20150721030212 and is 25% of current crashes on that channel.

Frame 	Module 	Signature 	Source
0 	xul.dll 	mozilla::a11y::ProxyDestroyed(mozilla::a11y::ProxyAccessible*) 	accessible/windows/msaa/Platform.cpp
1 	xul.dll 	mozilla::a11y::DocAccessibleParent::Destroy() 	accessible/ipc/DocAccessibleParent.cpp
2 	xul.dll 	mozilla::a11y::DocAccessibleParent::RecvShutdown() 	accessible/ipc/DocAccessibleParent.cpp
3 	xul.dll 	mozilla::a11y::PDocAccessibleParent::OnMessageReceived(IPC::Message const&) 	obj-firefox/ipc/ipdl/PDocAccessibleParent.cpp
4 	xul.dll 	mozilla::dom::PContentParent::OnMessageReceived(IPC::Message const&) 	obj-firefox/ipc/ipdl/PContentParent.cpp
5 	xul.dll 	mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&) 	ipc/glue/MessageChannel.cpp
6 	xul.dll 	mozilla::ipc::MessageChannel::DispatchMessageW(IPC::Message const&) 	ipc/glue/MessageChannel.cpp
7 	xul.dll 	mozilla::ipc::MessageChannel::OnMaybeDequeueOne() 	ipc/glue/MessageChannel.cpp
8 	xul.dll 	MessageLoop::DoWork() 	ipc/chromium/src/base/message_loop.cc

Comment 1

[David Major [:dmajor]]

|wrapper| is null at ProxyDestroyed. Is this a simple null-check or is there some deeper invariant being broken here?

Comment 2

[Trevor Saunders (:tbsaunde)]

(In reply to David Major [:dmajor] from comment #1)
> |wrapper| is null at ProxyDestroyed. Is this a simple null-check or is there
> some deeper invariant being broken here?

That function should be called whenever a proxy is destroyed, and called only once for a given proxy.  ProxyCreated always sets proxy->mWrapper to point at an object.  So that seems wrong, but I'm not sure we can really debug it, so I'd take / write a patch adding a null check.

Comment 3

[Guilherme Lima]

When Nightly crashes now it produces two entries on about:crashes?
I just crashed twice on http://9gag.com/gag/aDmzLmO and got

https://crash-stats.mozilla.com/report/index/e0690dbd-603e-4614-be64-ef15c2150725
https://crash-stats.mozilla.com/report/index/1217b1c1-f506-45ec-a95b-e09dd2150725
for the first crash

and
https://crash-stats.mozilla.com/report/index/57006baa-4de7-4dec-a2fa-ea97e2150725
https://crash-stats.mozilla.com/report/index/9708c630-7a7c-4aa0-889d-e8c912150725
for the second one

Comment 4

[Robert Kaiser]

(In reply to Guilherme Lima from comment #3)
> When Nightly crashes now it produces two entries on about:crashes?

That sounds wrong, we shouldn't do that. We should see to get one crash report with multiple dumps attached.

Comment 5

[David Major [:dmajor]]

Unless there's some bug in the code that causes simultaneous (but not directly-tied-together) crashes in both the parent and content processes.

Comment 6

[David Bolter [:davidb] (NeedInfo me for attention)]

One of the comments: "The site http://avengersalliance.wikia.com/ looks like a sure way to make it happen."

Comment 7

[David Bolter [:davidb] (NeedInfo me for attention)]

Trevor can you or Lorien write the patch (or debug)?

Comment 8

[Trevor Saunders (:tbsaunde)]

Created attachment 8639543 [details] [diff] [review]
check the proxy being destroyed has a wrapper before cleaning it up

All proxies should have wrappers on windows.  So it doesn't make much sense
that we need a null check here, however it seems to happen in the wild that
proxy->GetWrapper() returns null.

Comment 9

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b2dc6e6de6b6

Comment 10

[Wes Kocher (:KWierso)]

https://hg.mozilla.org/mozilla-central/rev/b2dc6e6de6b6

Comment 11

[David Bolter [:davidb] (NeedInfo me for attention)]

Crash stats seems to agree this is fixed. :)