Closed Bug 1751605 Opened 4 years ago Closed 4 years ago

Crash in [@ nsBaseWidget::Release]

Categories

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

Product:
Core
Component:
Widget: Gtk
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1756789

People

(Reporter: gsvelto, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: crash)

Crash Data

Crash report: https://crash-stats.mozilla.org/report/index/35061711-902b-4874-ac58-f418e0220109

Reason: SIGSEGV / SEGV_MAPERR

Top 10 frames of crashing thread:

0 libxul.so nsBaseWidget::Release /usr/src/debug/firefox-95.0-1.fc35.x86_64/widget/nsBaseWidget.cpp:137
1 libxul.so std::_Function_handler<void  
2 libxul.so moz_container_wayland_clear_initial_draw_callback 
3 libxul.so moz_container_wayland_unmap 
4 libgobject-2.0.so.0 g_signal_emit_valist /usr/src/debug/glib2-2.70.2-1.fc35.x86_64/gobject/gsignal.c:3406
5 libgobject-2.0.so.0 g_signal_emit /usr/src/debug/glib2-2.70.2-1.fc35.x86_64/gobject/gsignal.c:3553
6 libgtk-3.so.0 gtk_widget_unmap /usr/src/debug/gtk3-3.24.30-4.fc35.x86_64/gtk/gtkwidget.c:5081
7 libgobject-2.0.so.0 g_closure_invoke /usr/src/debug/glib2-2.70.2-1.fc35.x86_64/gobject/gclosure.c:830
8 libgobject-2.0.so.0 signal_emit_unlocked_R /usr/src/debug/glib2-2.70.2-1.fc35.x86_64/gobject/gsignal.c:3672
9 libgobject-2.0.so.0 g_signal_emit_valist /usr/src/debug/glib2-2.70.2-1.fc35.x86_64/gobject/gsignal.c:3497

Looking at the stack this appears like it might be a Wayland-specific issue. Going up several frames one always finds an invocation to nsWindow::HideWaylandWindow(). This seems to be mainly happening on Fedora but we have Ubuntu crashes on file too.

Priority: -- → P2

This comes from popup code but the backtrace is not very clear why nsBaseWidget::Release() is called on unmap. The stack looks wrong to me from moz_container_wayland_clear_initial_draw_callback() point.

Blocks: wayland-popup
No longer blocks: wayland

I don't quite understand how we can get:

0      nsBaseWidget::Release()
1 	std::_Function_handler<void (), nsWindow::EnableRenderingToWindow()::$_3>::_M_manager(std::_Any_data&, std::_Any_data const&, std::_Manager_operation) 
(2 	moz_container_wayland_clear_initial_draw_callback(_MozContainer*))
3 	moz_container_wayland_unmap(_GtkWidget*)

Yeah, that stack is really odd. However looking up we're capturing this in this lambda expression. Is it possible that we're getting the reference count wrong and the nsWindow object is being released when leaving the lamda function call?

I see. I think the scenario may be:

  1. we call EnableRenderingToWindow() and take refcount of nsWindow to lambda registered in initial_draw_callback()
  2. we clear all draw callbacks without calling them (by moz_container_wayland_clear_initial_draw_callback()).
  3. is the refcount taken in 1) cleared or not?

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

I see. I think the scenario may be:

  1. we call EnableRenderingToWindow() and take refcount of nsWindow to lambda registered in initial_draw_callback()
  2. we clear all draw callbacks without calling them (by moz_container_wayland_clear_initial_draw_callback()).
  3. is the refcount taken in 1) cleared or not?

So yes, the references are cleared as expected.

Could the refcount have been decremented somewhere else?

Hard to say. But this is Wayland (recently untested by testsuite) so I hope to catch this a similar ones when we enable Wayland testing (Bug 1725245).

I'd say it's dupe of Bug 1756789.

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