[wayland] Deleting bookmark reliably crashes browser [@ mozilla::dom::PlacesObservers::NotifyListeners]
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
People
(Reporter: ke5trel, Unassigned)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: crash, regression)
Crash Data
STR:
- Start with
MOZ_ENABLE_WAYLAND=1
on Ubuntu 21.04 installed on a slow USB drive. - 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•3 years ago
|
||
I can reproduce this reliably too, and I don't have a slow drive. This has been an annoying crash.
STR:
mozregression --launch 2021-10-07
- Open bookmarks sidebar (Ctrl+B)
- Open "Bookmarks Menu" folder
- 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•3 years ago
|
||
[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•3 years ago
|
||
(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•3 years ago
|
||
(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?
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Description
•