Crash in [@ mozilla::ipc::MessageChannel::Send | mozilla::ipc::IProtocol::ChannelSend | IPC_Message_Name=PWebRenderBridge::Msg_SetDisplayList]
Categories
(Core :: Graphics: WebRender, defect, P3)
Tracking
()
People
(Reporter: gsvelto, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: crash)
Crash Data
This bug is for crash report bp-e3a9c1a0-b476-4d32-a5c4-9f8690200419.
Top 10 frames of crashing thread:
0 libxul.so mozilla::ipc::MessageChannel::Send ipc/glue/MessageChannel.cpp:1007
1 libxul.so mozilla::ipc::IProtocol::ChannelSend ipc/glue/ProtocolUtils.cpp:471
2 libxul.so mozilla::layers::PWebRenderBridgeChild::SendSetDisplayList ipc/ipdl/PWebRenderBridgeChild.cpp:258
3 libxul.so mozilla::layers::WebRenderBridgeChild::EndTransaction gfx/layers/wr/WebRenderBridgeChild.cpp:130
4 libxul.so mozilla::layers::WebRenderLayerManager::EndTransactionWithoutLayer gfx/layers/wr/WebRenderLayerManager.cpp:436
5 libxul.so nsDisplayList::PaintRoot layout/painting/nsDisplayList.cpp:2996
6 libxul.so nsLayoutUtils::PaintFrame layout/base/nsLayoutUtils.cpp:4115
7 libxul.so mozilla::PresShell::Paint layout/base/PresShell.cpp:6159
8 libxul.so nsViewManager::ProcessPendingUpdatesPaint view/nsViewManager.cpp:460
9 libxul.so nsViewManager::ProcessPendingUpdatesForView view/nsViewManager.cpp:395
The oldest buildid for this crash is 20200412214115. This seems to be happening on beta too. The raw crash reason is:
MOZ_CRASH(IPC message size is too large)
Updated•5 years ago
|
Updated•5 years ago
|
Comment 2•5 years ago
|
||
Looks like someone found a website (or constructed a page) that ends up in an encoded display list that's 283 Mb. I suppose it's not impossible, just takes for a really big page :) Even if these kind of pages aren't seen in real life, it would be nice if we didn't crash on them. At least, we could show an error page or something.
Nicola, from the IPC standpoint is this something you had to deal with previously?
Comment 3•5 years ago
|
||
283 Mb is excessive, it would be interesting to see what causes the DL to be so large and change the DL format so that these extreme cases are unlikely to happen.
Our approach when running into size limits (for example large textures in shmem) has generally been to be able to break large things up into smaller one (like texture tiles) instead of relying on being able to allocate arbitrarily large objects.
I think that this approach could work here as well. I filed bug 1631752 to propose a more efficient way to serialize and transfer the DL which would help here.
Updated•4 years ago
|
Comment 4•4 years ago
|
||
The severity field is not set for this bug.
:jbonisteel, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•4 years ago
|
Updated•3 years ago
|
Comment 5•3 years ago
|
||
Closing because no crashes reported for 12 weeks.
Description
•