Crash in Abort | corrupted actor state | mozalloc_abort | NS_DebugBreak | mozilla::ipc::LogicError | mozilla::net::PStunAddrsRequestParent::SendOnStunAddrsAvailable

RESOLVED FIXED in Firefox 55

Status

()

P1
critical
Rank:
15
RESOLVED FIXED
2 years ago
a year ago

People

(Reporter: calixte, Assigned: mjf)

Tracking

(Blocks: 1 bug, {crash, regression})

Trunk
mozilla55
x86
Windows 10
crash, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox52 unaffected, firefox-esr52 unaffected, firefox53 unaffected, firefox54 unaffected, firefox55 fixed)

Details

(Whiteboard: [clouseau], crash signature)

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
This bug was filed from the Socorro interface and is 
report bp-03133273-5f54-45d7-8d45-3ea152170324.
=============================================================

There is 1 crash in nightly 55 with buildid 20170324030205. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1345511.

[1] https://hg.mozilla.org/mozilla-central/rev?node=af9901df3d48f0c683551331507c3c0810e9fc8f
Flags: needinfo?(mfroman)
(Assignee)

Comment 1

2 years ago
It would appear so, yes.  I'll have to find an IPC expert to help me understand what is happening.
(Assignee)

Comment 4

2 years ago
It is definitely the second, based on this info from the crash report:
AdapterVendorID: 0x8086, AdapterDeviceID: 0x0102, AdapterSubsysID: 20178086, AdapterDriverVersion: 9.17.10.4459
FP(D00-L1000-W00001000-T000) DWrite? DWrite+ xpcom_runtime_abort(###!!! ABORT: corrupted actor state: file c:/builds/moz2_slave/m-cen-w32-ntly-000000000000000/build/src/ipc/glue/ProtocolUtils.cpp, line 311)

I just don't know what the possible causes are for corrupted actor state.  The PStunAddrsRequestParent.cpp file is auto generated from the ipdl file.
From looking at this: http://searchfox.org/mozilla-central/search?q=symbol:F_%3CT_mozilla%3A%3Anet%3A%3APStunAddrsRequestParent%3E_0&redirect=false
I'm guessing that the auto generated code assumes each actor can only be used for a single request/response pair once and then has to die.
So I would guess it's either:
- something tries to re-use an actor, which appears to be not legit
- or callbacks are received before the request came in from the client
Crash Signature: [@ Abort | corrupted actor state | mozalloc_abort | NS_DebugBreak | mozilla::ipc::LogicError | mozilla::net::PStunAddrsRequestParent::SendOnStunAddrsAvailable] → [@ Abort | corrupted actor state | mozalloc_abort | NS_DebugBreak | mozilla::ipc::LogicError | mozilla::net::PStunAddrsRequestParent::SendOnStunAddrsAvailable] [@ Abort | __delete__()d actor | mozalloc_abort | Abort | NS_DebugBreak | mozilla::net::PStunA…
Version: 52 Branch → Trunk
(Assignee)

Updated

2 years ago
Flags: needinfo?(mfroman) → needinfo?(wmccloskey)
(Assignee)

Updated

2 years ago
Rank: 15
Priority: -- → P1
(Assignee)

Updated

2 years ago
Assignee: nobody → mfroman
I see two problems:

1. The ActorDestroy method doesn't do anything:
http://searchfox.org/mozilla-central/rev/7419b368156a6efa24777b21b0e5706be89a9c2f/media/mtransport/ipc/StunAddrsRequestParent.cpp#43
For refcounted actors, it's necessary to set a flag or something that remembers that we're not allowed to send IPC messages anymore. Then you need to check that flag here:
http://searchfox.org/mozilla-central/rev/7419b368156a6efa24777b21b0e5706be89a9c2f/media/mtransport/ipc/StunAddrsRequestParent.cpp#68
and avoid sending the message.

2. I don't see anything that keeps |this| alive between the time these runnable are dispatched and when it runs:
http://searchfox.org/mozilla-central/rev/7419b368156a6efa24777b21b0e5706be89a9c2f/media/mtransport/ipc/StunAddrsRequestParent.cpp#56
http://searchfox.org/mozilla-central/rev/7419b368156a6efa24777b21b0e5706be89a9c2f/media/mtransport/ipc/StunAddrsRequestParent.cpp#56
I'm not familiar with WrapRunnable though. Maybe it does the right thing?

I suspect #2 is causing this crash, but #1 should also be fixed.
Flags: needinfo?(wmccloskey)
(Assignee)

Comment 8

2 years ago
Bill, thank you so much for the feedback!  I'd guessed at #1 based on a example from DNSRequestParent.cpp, but I had not considered #2.  Thank you.
Comment hidden (mozreview-request)

Comment 10

2 years ago
mozreview-review
Comment on attachment 8853993 [details]
Bug 1350568 - don't dispatch IPC call to StunAddrsRequestChild after content process IPC channel goes away.

https://reviewboard.mozilla.org/r/125996/#review128548
Attachment #8853993 - Flags: review?(rjesup) → review+
status-firefox54: --- → unaffected
(Assignee)

Updated

2 years ago
Keywords: checkin-needed

Comment 11

2 years ago
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/777453c1b91a
don't dispatch IPC call to StunAddrsRequestChild after content process IPC channel goes away. r=jesup
Keywords: checkin-needed

Comment 12

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/777453c1b91a
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox55: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
status-firefox52: --- → unaffected
status-firefox53: --- → unaffected
status-firefox-esr52: --- → unaffected
You need to log in before you can comment on or make changes to this bug.