Crash in [@ mozilla::recordreplay::child::ChannelMessageHandler]
Categories
(Core Graveyard :: Web Replay, defect)
Tracking
(firefox-esr68 unaffected, firefox72 unaffected, firefox73 unaffected, firefox74 disabled)
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox72 | --- | unaffected |
firefox73 | --- | unaffected |
firefox74 | --- | disabled |
People
(Reporter: calixte, Unassigned)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: crash, regression)
Crash Data
This bug is for crash report bp-37865c67-0ab0-4567-985f-919d70200107.
Top 6 frames of crashing thread:
0 XUL mozilla::recordreplay::child::ChannelMessageHandler toolkit/recordreplay/ipc/ChildIPC.cpp:89
1 XUL std::__1::__function::__func<void /builds/worker/fetches/clang/include/c++/v1/functional:1707
2 XUL mozilla::recordreplay::Channel::ThreadMain toolkit/recordreplay/ipc/Channel.cpp:145
3 libsystem_pthread.dylib _pthread_start
4 libsystem_pthread.dylib thread_start
5 XUL XUL@0x3d1691f
There are 2 crashes (from 1 installation) in nightly 74 with buildid 20200106215403. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1606447.
[1] https://hg.mozilla.org/mozilla-central/rev?node=052285013972
Comment 1•5 years ago
|
||
Adding a similar signature which shows up with the same build id.
Comment 2•5 years ago
|
||
I think this was fixed as part of bug 1603945 --- we would previously try to forward messages to processes that have crashed or terminated, which could end up going to the wrong process because the fd had been closed and its number reused by the kernel later on.
Comment 3•5 years ago
|
||
We're still seeing crashes after the fix in bug 1603945 landed though.
Updated•5 years ago
|
Updated•5 years ago
|
Comment 4•5 years ago
|
||
WebReplay frontend has been removed, and it looks like this crash has gone away.
Updated•5 years ago
|
Description
•