Closed Bug 1734566 Opened 3 years ago Closed 3 years ago

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

Categories

(Core :: Widget: Gtk, defect)

Firefox 94
Unspecified
Linux
defect

Tracking

()

RESOLVED DUPLICATE of bug 1624384

People

(Reporter: ke5trel, Unassigned)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: crash, regression)

Crash Data

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.

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.

[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?

Flags: needinfo?(stransky)
Summary: [wayland] Deleting bookmark reliably crashes browser on system with slow drive [@ mozilla::dom::PlacesObservers::NotifyListeners] → [wayland] Deleting bookmark reliably crashes browser [@ mozilla::dom::PlacesObservers::NotifyListeners]

(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.

Flags: needinfo?(stransky)

(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?

Yes.

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