Open Bug 1884815 Opened 2 years ago Updated 3 months ago

Crash in [@ mozilla::ipc::PortLink::SendMessage | IPC_Message_Name=PContent::Msg_NotifyVisited]

Categories

(Core :: DOM: Navigation, defect)

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.

Severity: -- → S3

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), …

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.

See Also: → 1983198
You need to log in before you can comment on or make changes to this bug.