GNOME Bugzilla – Bug 763748
segfault in g_datalist_id_dup_data
Last modified: 2018-02-10 12:47:43 UTC
From the downstream bug report at https://bugzilla.redhat.com/show_bug.cgi?id=1299747 gnome-terminal is segfaulting multiple times a day now. Here's the backtrace from downstream: [New LWP 23935] [New LWP 23937] [New LWP 23936] [New LWP 23938] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/usr/libexec/gnome-terminal-server'. Program terminated with signal SIGSEGV, Segmentation fault.
+ Trace 236086
Thread 1 (Thread 0x7f15f6a73a80 (LWP 23935))
There may also be a duplicate filed here: https://bugzilla.redhat.com/show_bug.cgi?id=1283127
-> gtk+
what version of gtk is this with ?
From the downstream bug report in attachment https://bugzilla.redhat.com/attachment.cgi?id=1116074: /usr/lib64/libgtk-3.so.0.1800.6 gtk3-3.18.6-1.fc23.x86_64 (Fedora Project) 1449653338
https://retrace.fedoraproject.org/faf/problems/1838386/ has a bunch of similar backtraces. While they originate from different widgets, they all end up in: style_context = _gtk_widget_get_style_context (widget); gtk_style_context_get (style_context, _gtk_widget_get_state_flags (widget), "font", &font_desc, NULL); Crazy guess: did you happen to have changed the theme or fonts? I am asking since this is against GNOME 3.18.x / Fedora 23, and I run the stock gnome-terminal and gtk3 binaries from F23 and have never once seen this, nor has the vast majority of users. Otherwise the bug would be much more popular. While it does seem to be common for some people. Makes me wonder if a particular tweak to the default install triggers this.
No font, theme or other change. Was just watching a video with mplayer, perhaps mplayer ended or not, I don't exactly recall but then poof, all my terminals disappear.
I think this is related to running mplayer in the terminal session. It always seems to happen when mplayer is involved. I got another interesting case where all of my gnome-terminals are wedged although it didn't crash. The stacktrace for that looks like this:
+ Trace 236119
Thread 1 (Thread 0x7f8e92a0da80 (LWP 9793))
(In reply to Brian J. Murrell from comment #3) > From the downstream bug report in attachment > https://bugzilla.redhat.com/attachment.cgi?id=1116074: > > /usr/lib64/libgtk-3.so.0.1800.6 gtk3-3.18.6-1.fc23.x86_64 (Fedora Project) > 1449653338 The stacktraces in comment #0 has css nodes, so it can not be from gtk 3.18
gtk 3.18 is what I have installed here on F23: $ rpm -qa | grep gtk3 zukitwo-gtk3-theme-0.0.2-1.fc23.noarch libappindicator-gtk3-12.10.0-10.fc23.x86_64 avahi-ui-gtk3-0.6.32-0.4.rc.fc23.x86_64 ibus-gtk3-1.5.11-1.fc23.x86_64 webkitgtk3-2.4.9-3.fc23.x86_64 libindicator-gtk3-12.10.1-5.fc23.x86_64 gtk3-devel-3.18.6-1.fc23.x86_64 gtk3-debuginfo-3.16.6-1.fc22.x86_64 libcanberra-gtk3-0.30-10.fc23.x86_64 caribou-gtk3-module-0.4.19-1.fc23.x86_64 spice-gtk3-0.30-1.fc23.x86_64 libdbusmenu-gtk3-12.10.2-9.fc23.x86_64 gtk3-immodule-xim-3.18.6-1.fc23.x86_64 gtk3-3.18.6-1.fc23.x86_64
(In reply to Matthias Clasen from comment #7) > (In reply to Brian J. Murrell from comment #3) > > From the downstream bug report in attachment > > https://bugzilla.redhat.com/attachment.cgi?id=1116074: > > > > /usr/lib64/libgtk-3.so.0.1800.6 gtk3-3.18.6-1.fc23.x86_64 (Fedora Project) > > 1449653338 > > The stacktraces in comment #0 has css nodes, so it can not be from gtk 3.18 That is a very good point. I should have thought of that before. (In reply to Brian J. Murrell from comment #8) > gtk 3.18 is what I have installed here on F23: Are you sure that the libgtk-3.so ($ ldd /usr/libexec/gnome-terminal-server | grep gtk) is not coming from a newer non-RPM build of gtk+?
(In reply to Debarshi Ray from comment #9) > > Are you sure that the libgtk-3.so ($ ldd /usr/libexec/gnome-terminal-server > | grep gtk) $ ldd /usr/libexec/gnome-terminal-server | grep gtk libgtk-3.so.0 => /lib64/libgtk-3.so.0 (0x00007fd4fa276000) $ rpm -qf /lib64/libgtk-3.so.0 gtk3-3.18.6-1.fc23.x86_64 $ rpm -Vf /lib64/libgtk-3.so.0 $ > is not coming from a newer non-RPM build of gtk+? Yes, absolutely, without a doubt, as you can see above. Plus, I don't locally build/install software here. I strictly install only via RPM. I don't believe in "make install" except as a vehicle to getting software into an RPM, even if I were to build something locally. The Fedora RPM looks like a pretty clean build: http://pkgs.fedoraproject.org/cgit/rpms/gtk3.git/tree/gtk3.spec?h=f23 They don't even apply 1 patch.
Sorry, I was mistaken - gtkcssnode.c does in fact exist on the 3.18 branch already.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.