1734566 - [wayland] Deleting bookmark reliably crashes browser [@ mozilla::dom::PlacesObservers::NotifyListeners]

Status: RESOLVED DUPLICATE of bug 1624384

(Core :: Widget: Gtk, defect)

Description

[Kestrel]

STR:

1. Start with MOZ_ENABLE_WAYLAND=1 on Ubuntu 21.04 installed on a slow USB drive.
2. Delete a single bookmark from the toolbar or sidebar with the context menu.

Crash report: https://crash-stats.mozilla.org/report/index/389ef3e4-9dd8-4156-a3ac-34eed0211007

MOZ_CRASH Reason: MOZ_RELEASE_ASSERT(!gCallingListeners)

Top 10 frames of crashing thread:

0 libxul.so mozilla::dom::PlacesObservers::NotifyListeners dom/base/PlacesObservers.cpp:280
1 libxul.so mozilla::dom::PlacesObservers_Binding::notifyListeners dom/bindings/PlacesObserversBinding.cpp:404
2 libxul.so js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:472
3 libxul.so Interpret js/src/vm/Interpreter.cpp:3239
4 libxul.so js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:504
5 libxul.so js::Call js/src/vm/Interpreter.cpp:549
6 libxul.so js::CallSelfHostedFunction js/src/vm/SelfHosting.cpp:1538
7 libxul.so js::jit::InterpretResume js/src/jit/VMFunctions.cpp:1346
8  @0x10109470f99f 
9  @0x10109470c56e 

This is a slow USB device where bookmarking operations can sometimes take several seconds to complete.

Crash can be avoided by changing widget.wayland.async-clipboard.enabled = false.

Regressed by Bug 1729423.

Comment 1

[Jan Alexander Steffens [:heftig]]

I can reproduce this reliably too, and I don't have a slow drive. This has been an annoying crash.

STR:

1. mozregression --launch 2021-10-07
2. Open bookmarks sidebar (Ctrl+B)
3. Open "Bookmarks Menu" folder
4. Right-click "Firefox Nightly Resources" folder and delete it

The stated workaround (mozregression --launch 2021-10-07 --pref widget.wayland.async-clipboard.enabled:false) does indeed prevent the crash.

The problem is PlacesObservers::NotifyListeners asserts when it is called while already running, and you can indeed see two frames in Kestrel's trace (frame 1 and frame 90). Between them is nsRetrievalContextWaylandAsync::WaitForClipboardContent and it reentering the mainloop via gtk_main_iteration.

There's also a bug for this crash in the Places component (bug 1624384), supposedly P1 but without activity for 2 years.

Comment 2

[Marco Castelluccio [:marco]]

[Tracking Requested - why for this release]: Important crash, Wayland becoming default on more and more systems.

Martin, is this something we can fix easily or should we consider flipping the pref to false?

Comment 3

[Martin Stránský [:stransky] (ni? me)]

(In reply to Marco Castelluccio [:marco] from comment #2)

[Tracking Requested - why for this release]: Important crash, Wayland becoming default on more and more systems.

Martin, is this something we can fix easily or should we consider flipping the pref to false?

See Bug 1624384 - it has a fix for it. If we flip the pref we break clipboard on Wayland.

Comment 4

[Marco Castelluccio [:marco]]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #3)

(In reply to Marco Castelluccio [:marco] from comment #2)

[Tracking Requested - why for this release]: Important crash, Wayland becoming default on more and more systems.

Martin, is this something we can fix easily or should we consider flipping the pref to false?

See Bug 1624384 - it has a fix for it. If we flip the pref we break clipboard on Wayland.

Should we dupe this one to bug 1624384?

Comment 5

[Martin Stránský [:stransky] (ni? me)]

Yes.