Closed Bug 1350568 Opened 5 years ago Closed 5 years ago

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

Categories

(Core :: WebRTC: Networking, defect, P1)

x86
Windows 10
defect

Tracking

()

RESOLVED FIXED
mozilla55
Tracking Status
firefox52 --- unaffected
firefox-esr52 --- unaffected
firefox53 --- unaffected
firefox54 --- unaffected
firefox55 --- fixed

People

(Reporter: calixte, Assigned: mjf)

References

(Blocks 1 open bug)

Details

(Keywords: crash, regression, Whiteboard: [clouseau])

Crash Data

Attachments

(1 file)

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)
It would appear so, yes.  I'll have to find an IPC expert to help me understand what is happening.
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
Flags: needinfo?(mfroman) → needinfo?(wmccloskey)
Rank: 15
Priority: -- → P1
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)
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 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+
Keywords: checkin-needed
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
https://hg.mozilla.org/mozilla-central/rev/777453c1b91a
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
You need to log in before you can comment on or make changes to this bug.