Crash report: https://crash-stats.mozilla.org/report/index/f260aea6-d269-4f12-820a-a54100220607

MOZ_CRASH Reason: MOZ_CRASH(IPC message size is too large)

Top 10 frames of crashing thread:

0 xul.dll mozilla::ipc::IProtocol::ChannelSend ipc/glue/ProtocolUtils.cpp:493
1 xul.dll mozilla::layers::PWebRenderBridgeChild::SendSetDisplayList ipc/ipdl/PWebRenderBridgeChild.cpp:311
2 xul.dll mozilla::layers::WebRenderBridgeChild::EndTransaction gfx/layers/wr/WebRenderBridgeChild.cpp:127
3 xul.dll mozilla::layers::WebRenderLayerManager::EndTransactionWithoutLayer gfx/layers/wr/WebRenderLayerManager.cpp:458
4 xul.dll mozilla::nsDisplayList::PaintRoot layout/painting/nsDisplayList.cpp:2304
5 xul.dll static nsLayoutUtils::PaintFrame layout/base/nsLayoutUtils.cpp:3456
6 xul.dll mozilla::PresShell::PaintInternal layout/base/PresShell.cpp:6436
7 xul.dll nsViewManager::ProcessPendingUpdatesPaint view/nsViewManager.cpp:440
8 xul.dll nsViewManager::ProcessPendingUpdatesForView view/nsViewManager.cpp:375
9 xul.dll nsViewManager::ProcessPendingUpdates view/nsViewManager.cpp:948

Affected versions

• 103.0a1 (2022-06-06)
• 102.0b4
• 101.0

Affected platforms

• Windows 10
• macOS 12.1

Steps to reproduce

1. Create a large dummy file (eg. 50 MB - see attachment)
2. Drag and drop it on any tab

Regression range

• Last good revision: 63bc837753d653ab13635e432400c1b6d31d12ca (2019-05-07)
• First bad revision: fd9b8188501938a9306105a01db5beeefeab1a19 (2019-05-08)
• Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=63bc837753d653ab13635e432400c1b6d31d12ca&tochange=fd9b8188501938a9306105a01db5beeefeab1a19

Other notes

• Reproducible regardless of the gfx.webrender.all state.
• Chrome is stable using the same steps.

:Anca, since this bug is a regression, could you fill (if possible) the regressed_by field?
For more information, please visit auto_nag documentation.

Looks like this might be a dupe of Bug 1444615.

Hi Andrew, Can you please take a look at this? It's questioning if comment 2 is right. Bug 1707642 could be a bit related, however the message size limit increase was intended for fuzzing builds. Is there something actionable here? Perhaps based Nika's recent patches in bug 1681359? Thanks!

(In reply to Hsin-Yi Tsai (Fx104 REO) [:hsinyi] from comment #3)

Can you please take a look at this? It's questioning if comment 2 is right.

I don't think it is right. This is the generic crash you get when an IPC message is too large. In this specific case, it is happening during PWebRenderBridgeChild::SendSetDisplayList(), while the other bug is related to PContentChild::SendSetURITitle().

Bug 1707642 could be a bit related, however the message size limit increase was intended for fuzzing builds. Is there something actionable here? Perhaps based Nika's recent patches in bug 1681359? Thanks!

I think a WebRender person will have to look at this to figure out what is going wrong. It does seem weird that dragging and dropping a large file somehow causes a huge web render message, but maybe it makes sense to somebody else.

I'm going to clear the regression keyword because the regression range dates to 2019.

(In reply to Andrew McCreight [:mccr8] from comment #4)

(In reply to Hsin-Yi Tsai (Fx104 REO) [:hsinyi] from comment #3)

Can you please take a look at this? It's questioning if comment 2 is right.

I don't think it is right. This is the generic crash you get when an IPC message is too large. In this specific case, it is happening during PWebRenderBridgeChild::SendSetDisplayList(), while the other bug is related to PContentChild::SendSetURITitle().

Bug 1707642 could be a bit related, however the message size limit increase was intended for fuzzing builds. Is there something actionable here? Perhaps based Nika's recent patches in bug 1681359? Thanks!

I think a WebRender person will have to look at this to figure out what is going wrong. It does seem weird that dragging and dropping a large file somehow causes a huge web render message, but maybe it makes sense to somebody else.

Thanks for the response, Andrew.
Hi Glenn, can you help us address the comment and see what's up here?

I'm going to clear the regression keyword because the regression range dates to 2019.

I can reproduce this on Linux too - Gecko is generating an extremely large display list which is too big for IPC to handle (~603 MB).

It seems to be almost all coming from a huge number of very large text runs.

If I log out some information in push_text in the WR display list builder, I see:

push_text 65536 [p 283827 ==> 1074351]
push_text 65536 [p 1074351 ==> 1864875]
push_text 65536 [p 1864875 ==> 2655399]

[x 796 more text runs]
 
push_text 65536 [p 630331455 ==> 631121979]
push_text 65536 [p 631121979 ==> 631912503]
push_text 60456 [p 631912503 ==> 632641695]

This shows the length in glyphs of each text run and the delta change in display list size. So there are ~800 text runs of 64k glyphs, each of those contributing ~772 kB to the display list size.

I'm not sure if that might be related to a very long tab title? Or perhaps content within the tab itself? This might be something that Timothy is able to identify and track down the correct fix for?

There's a very long line in that text file, 52 million characters long. The gecko display list has one display item per line, but one of them is pointing to that monster text run. So I guess the code that create web render commands from that needs to be made a little smarter to avoid creating so many useless text items that are not visibl, it probably just iterates the whole text run, which is usually okay, but not in this extreme case.

Moving push_text crash signatures from bug 1760903.

Steps to reproduce [@OOM | large | mozalloc_abort | webrender_bindings::bindings::wr_dp_push_text]

1. Load https://firefoxci.taskcluster-artifacts.net/MzPweTrdRuWnU6NNjImVQA/0/public/logs/live_backing.log
2. Select and copy the log file contents.
3. Click in the address bar.
4. Ctrl+V paste the log file in the address bar.

Expected behavior

Firefox shouldn't crash. The content pasted into the address bar should be ignored or maybe truncated.

Actual behavior

Firefox chrome will hang and eventually OOM this signature: [@OOM | large | mozalloc_abort | webrender_bindings::bindings::wr_dp_push_text]. I can reproduce this in both 32- and 64-bit Firefox Nightly 110 on Windows.

https://crash-stats.mozilla.org/report/index/a9ce7503-6a40-4a00-8d1b-f4ba40230111

It seems like bug 1817184 fixed this. Do you want to confirm?

(In reply to Timothy Nikkel (:tnikkel) from comment #9)

It seems like bug 1817184 fixed this. Do you want to confirm?

I confirm this issue is no longer reproducible with the latest Nightly 112.0a1 (2023-02-21).