Closed Bug 1239697 Opened 10 years ago Closed 10 years ago

mozilla::ipc::FatalError crash in mozilla::dom::PContentChild::SendSyncMessage

Categories

(Core :: IPC, defect)

x86
Windows NT
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 1125220
Tracking Status
e10s m8+ ---

People

(Reporter: kairo, Assigned: billm)

Details

(Keywords: crash)

Crash Data

This bug was filed from the Socorro interface and is report bp-97f237f3-ae68-4475-874b-2d5af2160107. ============================================================= Stack: 0 mozglue.dll mozalloc_abort(char const* const) memory/mozalloc/mozalloc_abort.cpp 1 xul.dll NS_DebugBreak xpcom/base/nsDebugImpl.cpp 2 xul.dll mozilla::ipc::FatalError(char const*, char const*, unsigned long, bool) ipc/glue/ProtocolUtils.cpp 3 xul.dll mozilla::dom::PContentChild::FatalError(char const* const) obj-firefox/ipc/ipdl/PContentChild.cpp 4 xul.dll mozilla::dom::PContentChild::SendSyncMessage(nsString const&, mozilla::dom::ClonedMessageData const&, nsTArray<mozilla::jsipc::CpowEntry> const&, IPC::Principal const&, nsTArray<mozilla::dom::ipc::StructuredCloneData>*) obj-firefox/ipc/ipdl/PContentChild.cpp 5 xul.dll ChildProcessMessageManagerCallback::DoSendBlockingMessage(JSContext*, nsAString_internal const&, mozilla::dom::ipc::StructuredCloneData&, JS::Handle<JSObject*>, nsIPrincipal*, nsTArray<mozilla::dom::ipc::StructuredCloneData>*, bool) dom/base/nsFrameMessageManager.cpp 6 xul.dll JS_ResolveStandardClass(JSContext*, JS::Handle<JSObject*>, JS::Handle<jsid>, bool*) js/src/jsapi.cpp 7 xul.dll nsFrameMessageManager::SendSyncMessage(nsAString_internal const&, JS::Handle<JS::Value>, JS::Handle<JS::Value>, nsIPrincipal*, JSContext*, unsigned char, JS::MutableHandle<JS::Value>) dom/base/nsFrameMessageManager.cpp This has been one of the top 5 crashes on Developer Edition for a while, it's a crash in the content process.
Bill, is this strictly add-on related CPOWs?
Flags: needinfo?(wmccloskey)
This crash looks like it's MessageManager sync messages being affected by the (hypothetical?) response ordering bug here, not CPOWs. And this is a content crash, so it would be child->parent sync messages.
Jed is right, but I still suspect the ordering problem is caused by bugs in CPOW cancellation.
Flags: needinfo?(wmccloskey)
Assignee: nobody → wmccloskey
Duping for now. We can undupe if it doesn't get fixed.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.