Open Bug 1780190 Opened 3 months ago Updated 2 months ago

Parent process deadlock when hiding a window

Categories

(Core :: Widget: Gtk, defect, P3)

defect

Tracking

()

Tracking Status
firefox102 --- affected
firefox103 --- affected
firefox104 --- affected

People

(Reporter: emilio, Unassigned)

References

(Blocks 1 open bug)

Details

Crash report: bp-5f20c0bf-74dc-4035-9827-9199b0220719

It seems the parent process is sending a sync Pause() to the compositor, but the compositor is sending a sync Resume() to the parent process.

See Also: → 1777664

:stransky, can you comment to comment 1?

Flags: needinfo?(stransky)

(In reply to Sotaro Ikeda [:sotaro] from comment #1)

I wonder if WindowSurfaceWaylandMB::Commit() might cause a dead lock.

First lock was held in

And second lock was tried to be held in

moz_container_wayland_add_initial_draw_callback() could call a callback if it is ready.
https://searchfox.org/mozilla-central/rev/108c7843696fdf951083889d6fb858953139be96/widget/gtk/MozContainerWayland.cpp#216

Yes, that's correct - moz_container_wayland_add_initial_draw_callback() can fire the callback immediately so we have a deadlock here.

Flags: needinfo?(stransky)

Changed component according to comment 1.

Component: Graphics: WebRender → Widget: Gtk
Priority: -- → P3

Bug 1780389 should handle the scenario from comment 1. I think the root cause here is the Pause()/Resume() call so let's fix that deadlock as extra bug.

You need to log in before you can comment on or make changes to this bug.