Closed Bug 1631347 Opened 5 years ago Closed 3 years ago

Crash in [@ mozilla::ipc::MessageChannel::Send | mozilla::ipc::IProtocol::ChannelSend | IPC_Message_Name=PWebRenderBridge::Msg_SetDisplayList]

Categories

(Core :: Graphics: WebRender, defect, P3)

defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox-esr78 --- affected
firefox87 --- affected
firefox88 --- affected
firefox89 --- affected

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)
Blocks: wr-stability

@Dzmitry: Could you take a look?

Flags: needinfo?(dmalyshau)
Priority: -- → P3

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?

Flags: needinfo?(dmalyshau) → needinfo?(nical.bugzilla)

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.

Flags: needinfo?(nical.bugzilla)
Depends on: 1631752
Severity: -- → normal

The severity field is not set for this bug.
:jbonisteel, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jbonisteel)
Severity: normal → S3
Flags: needinfo?(jbonisteel)
Crash Signature: [@ mozilla::ipc::MessageChannel::Send | mozilla::ipc::IProtocol::ChannelSend | IPC_Message_Name=PWebRenderBridge::Msg_SetDisplayList] → [@ mozilla::ipc::IProtocol::ChannelSend | IPC_Message_Name=PWebRenderBridge::Msg_SetDisplayList] [@ mozilla::ipc::MessageChannel::Send | mozilla::ipc::IProtocol::ChannelSend | IPC_Message_Name=PWebRenderBridge::Msg_SetDisplayList] [@ mozilla::ipc::Messa…
Hardware: Unspecified → All
No longer depends on: 1631752

Closing because no crashes reported for 12 weeks.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.