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
|wrapper| is null at ProxyDestroyed. Is this a simple null-check or is there some deeper invariant being broken here?
(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.
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
(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.
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
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+
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.