Closed Bug 1882019 Opened 2 months ago Closed 2 months ago

Crash in [@ mozilla::dom::MessagePort::CloseInternal]


(Core :: DOM: postMessage, defect, P2)




125 Branch
Tracking Status
firefox-esr115 --- unaffected
firefox123 --- wontfix
firefox124 --- wontfix
firefox125 --- fixed


(Reporter: gsvelto, Assigned: asuth)



(Keywords: crash)

Crash Data


(1 file)

Crash report:

MOZ_CRASH Reason: MOZ_DIAGNOSTIC_ASSERT(mUnshippedEntangledPort)

Top 10 frames of crashing thread:

0  mozilla::dom::MessagePort::CloseInternal  dom/messagechannel/MessagePort.cpp:463
1  mozilla::dom::MessagePort::CloseForced  dom/messagechannel/MessagePort.cpp:449
1  mozilla::dom::MessagePort::Initialize  dom/messagechannel/MessagePort.cpp:269
2  mozilla::dom::MessagePort::Create  dom/messagechannel/MessagePort.cpp:208
3  mozilla::dom::MessageChannel::Constructor  dom/messagechannel/MessageChannel.cpp:65
4  mozilla::dom::MessageChannel::Constructor  dom/messagechannel/MessageChannel.cpp:43
4  mozilla::dom::MessageChannel_Binding::_constructor  dom/bindings/MessageChannelBinding.cpp:235
5  CallJSNative  js/src/vm/Interpreter.cpp:480
5  CallJSNativeConstructor  js/src/vm/Interpreter.cpp:496
5  InternalConstruct  js/src/vm/Interpreter.cpp:721

Low-volume because the assertion is only enabled on beta and nightly.

Assignee: nobody → bugmail
Component: DOM: Workers → DOM: postMessage

Hm, these all show the worker script loader seems to still be evaluating code after having been notified of shutdown. I'm inclined to suspect the involvement of bug 1837302 given the rarity of these.

See Also: → 1837302

In any event, this does need to be addressed as-is, as noted there are a few lingering edge cases where we can be in this situation.

The basic situation here is:

  • The MessagePort's invariants about eStateUnshippedEntangled won't hold until after we return from MessagePort::Initialize and the owning MessageChannel calls UnshippedEntangle.
  • nsIGlobalObject::IsDying or mozilla::GlobalTeardownObserver::CheckCurrentGlobalCorrectness are checks that we could also run earlier in the process and reliably would let us know we are headed for this eventual code path. In particular, it's not possible for control runnables to be processed anywhere in the MessageChannel creation process at this time. It's not particularly likely we would change that, as that would effectively constitute turning channel creation into a synchronous/blocking op.

Fix options:

  1. Bail earlier with an IsDying check as noted above so this control flow path doesn't happen. WorkerRef creation could then be made to more strongly assert success.
  2. Add a new state machine state like eStateInitializedUntangled which indicates our intent to advance to eStateUnshippedEntangled when mozilla::dom::MessagePort::UnshippedEntangle is called.
  3. Relax the assert.

I'm inclined to add a new state machine state for this case (2) in the interest of minimizing changes to the control flow and because it feels less prone to inadvertent breakage where it feels like the new dying check could be accidentally removed. Also, the WorkerRef handling for the 1st case still essentially would need to be there in some form. And also this is not a case we can really test.

Severity: -- → S2
Priority: -- → P2
Attachment #9382728 - Attachment description: WIP: Bug 1882019 - Handle failure to create a WorkerRef better. r=#dom-workers! → Bug 1882019 - Handle failure to create a WorkerRef better. r=#dom-workers!
Pushed by
Handle failure to create a WorkerRef better. r=dom-worker-reviewers,smaug
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 125 Branch
You need to log in before you can comment on or make changes to this bug.