Crash in [@ mozilla::ipc::PortLink::SendMessage | IPC_Message_Name=PContent::Msg_NotifyVisited]
Categories
(Core :: DOM: Navigation, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr115 | --- | unaffected |
| firefox-esr128 | --- | unaffected |
| firefox129 | --- | fix-optional |
| firefox130 | --- | fix-optional |
| firefox131 | --- | affected |
People
(Reporter: mccr8, Unassigned)
References
Details
(Keywords: crash)
Crash Data
Crash report: https://crash-stats.mozilla.org/report/index/e8737f1d-842a-4fab-a903-8ae330240311
MOZ_CRASH Reason: MOZ_CRASH(IPC message size is too large)
Top 10 frames of crashing thread:
0 XUL mozilla::ipc::PortLink::SendMessage ipc/glue/MessageLink.cpp:107
0 XUL mozilla::ipc::MessageChannel::SendMessageToLink ipc/glue/MessageChannel.cpp:806
0 XUL mozilla::ipc::MessageChannel::Send ipc/glue/MessageChannel.cpp:775
1 XUL mozilla::ipc::IProtocol::ChannelSend ipc/glue/ProtocolUtils.cpp:512
2 XUL mozilla::dom::PContentParent::SendNotifyVisited ipc/ipdl/PContentParent.cpp:2292
3 XUL mozilla::BaseHistory::SendPendingVisitedResultsToChildProcesses docshell/base/BaseHistory.cpp:213
4 XUL mozilla::detail::RunnableMethodArguments<>::apply<mozilla::BaseHistory, void const xpcom/threads/nsThreadUtils.h:1164
4 XUL std::__1::__invoke[abi:v160006]<mozilla::detail::RunnableMethodArguments<>::apply<std::__1::__invoke[abi:v160006]::BaseHistory, void /builds/worker/fetches/MacOSX14.2.sdk/usr/include/c++/v1/__functional/invoke.h:394
4 XUL std::__1::__apply_tuple_impl[abi:v160006]<mozilla::detail::RunnableMethodArguments<>::apply<std::__1::__apply_tuple_impl[abi:v160006]::BaseHistory, void /builds/worker/fetches/MacOSX14.2.sdk/usr/include/c++/v1/tuple:1816
4 XUL std::__1::apply[abi:v160006]<mozilla::detail::RunnableMethodArguments<>::apply<std::__1::apply[abi:v160006]::BaseHistory, void /builds/worker/fetches/MacOSX14.2.sdk/usr/include/c++/v1/tuple:1825
Crash spike report shows 4 of these on Nightly, though I think the issue has been around longer. Hopefully it is just a fluke and not the indication of a regression.
Updated•2 years ago
|
Comment 1•1 year ago
•
|
||
I can reproduce this. I had opened [DON'T LOAD]https://hg.mozilla.org/mozilla-central/rev/9b2a99adc05e53cd4010de512f50118594756650[DON'T LOAD] in a tab. My browser was crashing consistently a little bit after startup with this signature. I managed to catch it in a debugger, we're trying to send a very big message over IPC:
(lldb) p aMessage.mTuple.mFirstA->header_->payload_size
(uint32_t) 344522136
To be clear, this page is a bit ridiculous: it has an anchor element for every line of source, and there's more than 5 million lines. But the resultsForProcess at https://searchfox.org/mozilla-central/rev/261005fcc4d6f8b64189946958211259fb45e9e1/docshell/base/BaseHistory.cpp#220 seems to contain more than 3 million URIs of the form:
https://hg.mozilla.org/mozilla-central/rev/9b2a99adc05e53cd4010de512f50118594756650#l1.1
https://hg.mozilla.org/mozilla-central/rev/9b2a99adc05e53cd4010de512f50118594756650#l1.2
https://hg.mozilla.org/mozilla-central/rev/9b2a99adc05e53cd4010de512f50118594756650#l1.3
https://hg.mozilla.org/mozilla-central/rev/9b2a99adc05e53cd4010de512f50118594756650#l1.4
https://hg.mozilla.org/mozilla-central/rev/9b2a99adc05e53cd4010de512f50118594756650#l1.5
https://hg.mozilla.org/mozilla-central/rev/9b2a99adc05e53cd4010de512f50118594756650#l1.6
…
I'm not sure why we need to notify about unvisited links, but we shouldn't be crashing here.
There are multiple things we can do: limit the message size (by sending in chunks), maybe figure out a better encoding for multiple hrefs that are the same but have a different ref(/query), …
Updated•1 year ago
|
Comment 2•3 months ago
|
||
Same crash happens to me when trying to load https://hg-edge.mozilla.org/try/rev/86810dce9cf6f0b3abe67c84ae3c71da780d8489 [DONTLOAD]. Firefox crashes after about a minute or so.
Description
•