Created attachment 1293678 [details] A full backtrace from gdb attached to firefox-wayland. Aborted after >1 hour of backtrace generation. Description of problem: Version-Release number of selected component (if applicable): firefox-wayland-56.1-1.fc26.x86_64 from martin stransky's copr on https://copr.fedorainfracloud.org/coprs/stransky/firefox-wayland/ How reproducible: unclear, unknown What I did before the crash happened: 1. start firefox-wayland with $ firefox-wayland --new-instance -ProfileManager 2. in ProfileManager, create a new profile 3. select new profile 4. try to press the "Start Nightly" button Actual results: Instead of hiding the window and starting nightly, I got a crash. Additional info: Running on a fully updated Fedora 26 with gtk3-3.22.16-1.fc26.x86_64 glib2-2.52.3-1.fc26.x86_64 libwayland-client-1.13.0-1.fc26.x86_64 Truncated backtrace: #0 0x00007f4cd3ad843d in nanosleep () at ../sysdeps/unix/syscall-template.S:84 #1 0x00007f4cd3ad837a in __sleep (seconds=0) at ../sysdeps/posix/sleep.c:55 #2 0x00007f4cc57832ae in ah_crap_handler(int) (signum=11) at /usr/src/debug/firefox-wayland-56.1/toolkit/xre/nsSigHandlers.cpp:103 #3 0x00007f4cc6187683 in WasmFaultHandler<(Signal)0>(int, siginfo_t*, void*) (signum=<optimized out>, info=0x7ffc2d186530, context=0x7ffc2d186400) at /usr/src/debug/firefox-wayland-56.1/js/src/wasm/WasmSignalHandlers.cpp:1395 #4 0x00007f4cd48a02c0 in <signal handler called> () at /lib64/libpthread.so.0 #5 0x00007f4cd16f5d26 in gtk_widget_get_window (widget=0x7f4cb896a8d0) at gtkwidget.c:15937 #6 0x00007f4cd16a9512 in _gtk_widget_find_at_coords (window=window@entry=Python Exception <class 'KeyboardInterrupt'> : , window_x=<optimized out>, window_y=<optimized out>, widget_x=widget_x@entry=0x7ffc2d186910, widget_y=widget_y@entry=0x7ffc2d186914) at gtktooltip.c:644 #7 0x00007f4cd16aa20f in gtk_tooltip_show_tooltip (display=display@entry=0x7f4cd3863840 [GdkWaylandDisplay]) at gtktooltip.c:1124 #8 0x00007f4cd16aa6ff in tooltip_popup_timeout (data=0x7f4cd3863840) at gtktooltip.c:1235 #9 0x00007f4cd10a7b20 in gdk_threads_dispatch (data=data@entry=0x7f4ca781cc80) at gdk.c:743 #10 0x00007f4cce711cad in g_timeout_dispatch (source=0x7f4ca782dcf0, callback=0x7f4cd10a7b00 <gdk_threads_dispatch>, user_data=0x7f4ca781cc80) at gmain.c:4715
Thanks. That crash comes from showing a tooltip window - I see that sometime but don't know what causes that yet.
My colleague got another gtk tooltip related crash. Our crash report already reported in GTK+ bug tracker: https://bugzilla.gnome.org/show_bug.cgi?id=784319
Just to clarify, this is not Wayland, but firefox and CSD. See https://bugzilla.gnome.org/show_bug.cgi?id=784319#c10
Created attachment 1296141 [details] Remove moz_container_unrealize() It seems that the attached patch fixes a similar case (https://bugzilla.gnome.org/show_bug.cgi?id=784319). But I can't confirm this bug's case yet since I can't reproduce it yet. Someone, please test the patch.
Created attachment 1296147 [details] A stack trace of another crash bug Although it fixes tooltip's crash, sometimes another crash occurs on my environment (attached log) after I apply the patch. It's more rare than before. It seems that using a fresh profile is easier to reproduce. Probably it's different bug from this one and it would happen from before. Note that our code & hardware is different from yours (see https://bugzilla.gnome.org/show_bug.cgi?id=784319). If it's not reproduced on your environment, please ignore it.
Is that stack trace from attachment 1296147 [details] coming from a current gtk+-3.22 or an older version 3.20 as found in yocto iirc? Reason I'm asking is because this might be related: https://mail.gnome.org/archives/commits-list/2016-November/msg00706.html https://bugzilla.gnome.org/show_bug.cgi?id=773274 (and that was reported my Martin for Firefox on Wayland...)
backtrace says 3.20.9 btw, so this is an older issue. Therefore my advise would be to make sure to test with a current gtk+ version (this bug here being reported against fedora 26 which ships an up-to-date version of gtk+) otherwise we might end up fighting old bugs again.
I've installed Fedora 26 and built Firefox using https://github.com/stransky/gecko-dev/commit/de7ad4e633e6acb32a2a0d1403ef1a8c0539ad95. Now I've got a same backtrace with attachment 1293678 [details] on closing a browser window normally. Also I've confirmed that the patch in comment 4 (attachment 1296141 [details]) fixes the bug. In addition the crash described in comment 5 isn't occurred on this environment. (Although sometimes it still crashes at FcCacheFini(), it's obviously a different bug.)
Added as commit dba7baee43fd9f75ae70c76f5ec4850f392cf0b9 - please check if that fixes for you.
Created attachment 1296820 [details] Another solution to call GtkWidget's "unrealize" function From https://bugzilla.gnome.org/show_bug.cgi?id=784319#c23: (In reply to Martin Stransky from comment #23) > Well, and why is the "unrealize" handler call missing here? I think the > issue here is that the unrealize handler does not remove the GdkWindow > created in realize handler, right? Yes, that's right. When GtkWidget's "unrealize" function is called, GdkWindow will be destroyed by it: https://git.gnome.org/browse/gtk+/tree/gtk/gtkwidget.c#n10589 If "unrealize" function isn't overridden by a child class (like MozContainer), it will be called by default because initial "unrealize" function pointer is set as parent class's one (GtkContainer -> GtkWidget) by GTK+. If you want to override "unrealize" func, you should call GtkWidget's "unrealize" function by yourself (like attached patch). Otherwise it's never called. > With this patch we'll leak the wayland surfaces here. At first I wrote the attached patch. It also works fine. But I noticed that moz_container_unmap_surface() in moz_container_unrealize() isn't needed because it's also called at moz_container_unmap(). Since GTK+ make sure to call "unmap" function before "unrealize" function (if the window is already mapped), moz_container_unmap_surface() in moz_container_unrealize() is redundant. If we remove it, moz_container_unrealize() do nothing, it just calls parent class's unrealize. As I mentioned above, we don't need to override "unrealize" function in this case.
(In reply to Martin Stransky from comment #9) > Added as commit dba7baee43fd9f75ae70c76f5ec4850f392cf0b9 - please check if > that fixes for you. I have no way to reproduce this bug, so I won't be able to check if that patch works, sorry.
https://bugzilla.gnome.org/show_bug.cgi?id=784319 is related.
(In reply to ashie from comment #10) > Created attachment 1296820 [details] > If you want to override "unrealize" func, you should call GtkWidget's > "unrealize" function by yourself (like attached patch). Or do equivalent of it like your patch (https://github.com/stransky/gecko-dev/commit/dba7baee43fd9f75ae70c76f5ec4850f392cf0b9) :-)
You're right - let's remove the unrealize handler. commit e1acac5a44d411d6058b38c26596873867abf49e