Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1467104 - [Wayland] Crash at gtk_tooltip_show_tooltip
Summary: [Wayland] Crash at gtk_tooltip_show_tooltip
Alias: None
Product: Fedora
Classification: Fedora
Component: firefox
Version: 26
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Martin Stransky
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: ffwayland
TreeView+ depends on / blocked
Reported: 2017-07-02 21:27 UTC by Christian Stadelmann
Modified: 2017-07-12 10:04 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-07-12 10:04:18 UTC
Type: Bug

Attachments (Terms of Use)
A full backtrace from gdb attached to firefox-wayland. Aborted after >1 hour of backtrace generation. (621.68 KB, text/plain)
2017-07-02 21:27 UTC, Christian Stadelmann
no flags Details
Remove moz_container_unrealize() (2.18 KB, patch)
2017-07-11 09:23 UTC,
no flags Details | Diff
A stack trace of another crash bug (4.83 KB, text/plain)
2017-07-11 09:41 UTC,
no flags Details
Another solution to call GtkWidget's "unrealize" function (1.69 KB, patch)
2017-07-12 09:48 UTC,
no flags Details | Diff

Description Christian Stadelmann 2017-07-02 21:27:24 UTC
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

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

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/
#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

Comment 1 Martin Stransky 2017-07-03 05:58:27 UTC
Thanks. That crash comes from showing a tooltip window - I see that sometime but don't know what causes that yet.

Comment 2 Hiroshi Hatake 2017-07-03 08:57:47 UTC
My colleague got another gtk tooltip related crash.
Our crash report already reported in GTK+ bug tracker:

Comment 3 Olivier Fourdan 2017-07-07 13:50:16 UTC
Just to clarify, this is not Wayland, but firefox and CSD.


Comment 4 2017-07-11 09:23:13 UTC
Created attachment 1296141 [details]
Remove moz_container_unrealize()

It seems that the attached patch fixes a similar case (
But I can't confirm this bug's case yet since I can't reproduce it yet.
Someone, please test the patch.

Comment 5 2017-07-11 09:41:13 UTC
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 If it's not reproduced on your environment, please ignore it.

Comment 6 Olivier Fourdan 2017-07-11 11:48:43 UTC
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:

(and that was reported my Martin for Firefox on Wayland...)

Comment 7 Olivier Fourdan 2017-07-11 11:53:44 UTC
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.

Comment 8 2017-07-12 04:55:14 UTC
I've installed Fedora 26 and built Firefox using

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

Comment 9 Martin Stransky 2017-07-12 09:47:14 UTC
Added as commit dba7baee43fd9f75ae70c76f5ec4850f392cf0b9 - please check if that fixes for you.

Comment 10 2017-07-12 09:48:48 UTC
Created attachment 1296820 [details]
Another solution to call GtkWidget's "unrealize" function


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

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.

Comment 11 Christian Stadelmann 2017-07-12 09:49:50 UTC
(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.

Comment 12 Martin Stransky 2017-07-12 09:50:30 UTC is related.

Comment 13 2017-07-12 09:55:58 UTC
(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 ( :-)

Comment 14 Martin Stransky 2017-07-12 10:03:21 UTC
You're right - let's remove the unrealize handler. 
commit e1acac5a44d411d6058b38c26596873867abf49e

Note You need to log in before you can comment on or make changes to this bug.