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

RESOLVED FIXED in Firefox 42

Status

()

Core
Disability Access APIs
--
critical
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: dmajor, Assigned: tbsaunde)

Tracking

(Blocks: 1 bug, {crash})

42 Branch
mozilla42
x86
Windows NT
crash
Points:
---

Firefox Tracking Flags

(firefox42 fixed)

Details

(Whiteboard: [Nightly top crasher], crash signature)

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
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
(Reporter)

Comment 1

3 years ago
|wrapper| is null at ProxyDestroyed. Is this a simple null-check or is there some deeper invariant being broken here?
Flags: needinfo?(tbsaunde+mozbugs)
(Assignee)

Comment 2

3 years ago
(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.
Flags: needinfo?(tbsaunde+mozbugs)

Comment 4

3 years ago
(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.
(Reporter)

Comment 5

3 years ago
Unless there's some bug in the code that causes simultaneous (but not directly-tied-together) crashes in both the parent and content processes.
One of the comments: "The site http://avengersalliance.wikia.com/ looks like a sure way to make it happen."
Whiteboard: [Nightly top crasher]
Trevor can you or Lorien write the patch (or debug)?
Assignee: nobody → tbsaunde+mozbugs
(Assignee)

Comment 8

3 years ago
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.
Attachment #8639543 - Flags: review?(dbolter)
Attachment #8639543 - Flags: review?(dbolter) → review+
https://hg.mozilla.org/mozilla-central/rev/b2dc6e6de6b6
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox42: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
Crash stats seems to agree this is fixed. :)
You need to log in before you can comment on or make changes to this bug.