Closed Bug 1563821 Opened 1 year ago Closed 1 year ago

Intermittent mozilla::ipc::MessageChannel::WillDestroyCurrentMessageLoop assertion in socket process


(Core :: Networking, defect, P2)




Tracking Status
firefox70 --- fixed


(Reporter: bwc, Assigned: kershaw)


(Blocks 1 open bug)


(Whiteboard: [necko-triaged])


(1 file)

This is causing bug 1536714, but I have seen it in other places too. It seems that the socket process isn't doing all the graceful shutdown stuff it should be, but I'm not entirely sure what is missing. Note that I have seen this in tests that do not involve any webrtc while working on bug 1555792; this problem is extremely common in the browser-chrome mochitests on OS X if the socket process is enabled.

I should also point out that this looks like shutdown bug.

Blocks: 1536714

Any ideas?

Flags: needinfo?(jmathies)

What protocol is the socket process using? can you point me to the ipdl?

Flags: needinfo?(jmathies) → needinfo?(docfaraday)

There are these two:

But since I have seen failures in tests that don't do any webrtc, and don't use PMediaTransport, I don't PMediaTransport.ipdl is involved.

Flags: needinfo?(docfaraday)

I'll take a look.

I think this might have something to do with SocketProcessBridgeChild, since SocketProcessBridgeChild::GetSocketProcessBridge is called every time in NeckoChild::InitNeckoChild without doing any webrtc.

Assignee: nobody → kershaw
Priority: -- → P2
Whiteboard: [necko-triaged]

From the log, I found that the problem happens because we create SocketProcessBridgeChild when content child is shutting down.
After adding some checks, the try looks good.

Pushed by
Check if content child is shuttingdown before create SocketProcessBridgeChild r=jld
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70
Regressions: 1242221
You need to log in before you can comment on or make changes to this bug.