#76 Frequent crashes in GTK CSS code when run as regular user

[Adam Williamson]

guvcview seems to always crash shortly after it is started, when run as a regular user on Fedora. https://bugzilla.redhat.com/show_bug.cgi?id=2269649 and https://bugzilla.redhat.com/show_bug.cgi?id=2254870 are reports of this kind of crash, and it was reported to me outside of Bugzilla by Matt Hartley from Framework (the laptop folks), and I can reproduce it myself on two machines.

Oddly, it doesn't crash when run as root. We're not sure why not yet.

There seem to be slightly different variants on the crash with different backtraces, but it's always shortly after startup and it's always in GTK CSS code. Matt got this interesting partial traceback:

#0  0x00007ffff776053b in _gtk_css_value_compute (value=0x7fffc40adc00, property_id=58, provider=0x7fffc40a12b0, style=0x555555adad80, parent_style=0x7fffc5b8b410) at ../gtk/gtkcssvalue.c:97
#1  0x00007ffff7720d34 in gtk_css_value_border_compute (value=0x7fffc40af940, property_id=Python Exception <class 'gdb.MemoryError'>: Cannot access memory at address 0x7fffffffd460
#2  0x00007ffff775dc95 in gtk_css_static_style_compute_value (section=Python Exception <class 'gdb.MemoryError'>: Cannot access memory at address 0x7fffffffd510
#3  _gtk_css_lookup_resolve
    (parent_style=0x7fffc5b8b410, style=0x555555adad80, provider=Python Exception <class 'gdb.MemoryError'>: Cannot access memory at address 0x7fffffffd508
#4  gtk_css_static_style_new_compute (provider=<optimized out>, matcher=<optimized out>, parent=<optimized out>)
    at ../gtk/gtkcssstaticstyle.c:195

The first few frames of my traceback looks like this (will attach the whole thing):

#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
        tid = <optimized out>
        ret = 0
        pd = <optimized out>
        old_mask = {__val = {88}}
        ret = <optimized out>
#1  0x00007fb49cc7b1a3 in __pthread_kill_internal (threadid=<optimized out>, signo=6) at pthread_kill.c:78
No locals.
#2  0x00007fb49cc2363e in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
        ret = <optimized out>
#3  0x00007fb49cc0b8ff in __GI_abort () at abort.c:79
        save_stage = 1
        act = {__sigaction_handler = {sa_handler = 0x20, sa_sigaction = 0x20}, sa_mask = {__val = {140413704061221, 140412884757136, 140412885491040, 0, 18446744073709551496, 88, 140412883054800, 140413216185552, 140413701234110, 140412883054816, 0, 0, 140412883054816, 96, 140413704859280, 140413216185584}}, sa_flags = -1661926795, sa_restorer = 0x60}
#4  0x00007fb49ced30dc in g_assertion_message (domain=domain@entry=0x7fb49d424014 "Gtk", file=file@entry=0x7fb49d42e24c "../gtk/gtkcssinheritvalue.c", line=line@entry=33, func=func@entry=0x7fb49d47c0f0 <__func__.0.lto_priv.92> "gtk_css_value_inherit_free", message=message@entry=0x7fb46c1e2a90 "code should not be reached") at ../glib/gtestutils.c:3331
        lstr = "33\000l\264\177\000\000`]\337\177\264\177\000\000P\224\"l\264\177\000\000\020\223)l\264\177\000"
        s = 0x7fb49cdc7b50 <lock> ""
#5  0x00007fb49cf3f427 in g_assertion_message_expr (domain=domain@entry=0x7fb49d424014 "Gtk", file=file@entry=0x7fb49d42e24c "../gtk/gtkcssinheritvalue.c", line=line@entry=33, func=func@entry=0x7fb49d47c0f0 <__func__.0.lto_priv.92> "gtk_css_value_inherit_free", expr=expr@entry=0x0) at ../glib/gtestutils.c:3357
        s = 0x7fb46c1e2a90 "code should not be reached"
#6  0x00007fb49d12382a in gtk_css_value_inherit_free (value=<optimized out>) at ../gtk/gtkcssinheritvalue.c:33
        __func__ = "gtk_css_value_inherit_free"
#7  0x00007fb49d149178 in _gtk_css_value_unref (value=0x7fb49d7b3b80 <inherit.lto_priv>) at ../gtk/gtkcssvalue.c:66
No locals.
#8  _gtk_css_value_unref (value=<optimized out>) at ../gtk/gtkcssvalue.c:57
No locals.

The "should not be reached" code it hit in my traceback is https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gtk/gtkcssinheritvalue.c?ref_type=heads#L29-34 . Some other projects have run into this kind of crash, which seems to relate to memory management and threading: https://github.com/lutris/lutris/issues/5092 , https://github.com/bottlesdevs/Bottles/issues/813 , https://github.com/haskell-gi/haskell-gi/issues/117 .

This affects both 2.0.8 and 2.1.0.

Matt reports that this doesn't happen on Ubuntu, which is weird but I can't see anything weird Fedora is doing here. We build guvcview from the upstream tarball with no patches and fairly standard build config:

%configure CC=gcc CXX=g++ --disable-debian-menu --disable-silent-rules --disable-static

it could involve our default compiler flags, I guess.

[Adam Williamson]

My full backtrace.

[Paulo Assis]

Hi, have you tried with the qt interface :
--disable-gtk3 --enable-qt5

You can also enable the sfml render:
--enable-sfml

and then: guvcview --render=sfml

As for the GTK interface, I really can't reproduce the problem in Arch.
Did you tried changing your gtk theme? If it works under root then it's most likely a permission issue. Just try with a default theme like Adwaita or installing a local theme.

Regards,

[Adam Williamson]

This is with default theme. I reproduced this on a completely clean fresh boot of Fedora (40).

I agree the different result with root points to some kind of permission situation, but the app still should not just crash, and I was hoping as the author you might have some kind of idea what different permissions might cause the app to go down different paths early in startup, so we could try and isolate exactly where the divergence is. I would like to try giving the regular user one additional permission at a time till I find whichever one makes it stop crashing, but I have no idea where to start.

[Paulo Assis]

I don't think fedora default theme is the same as gtk default (Adwaita).
In any case guvcview doesn't use any of the gtk css stuff directly.
For what I can see from your backtrace, there seems to be some calls to sdl decorate border, I'm not sure about sdl2 internals, but if you running gnome, maybe window decorations use gtk css.
Have you tried with sfml render instead of sdl2?

[Adam Williamson]

"I don't think fedora default theme is the same as gtk default (Adwaita)."

It is. We use pretty much all upstream GNOME defaults, these days.

"Have you tried with sfml render instead of sdl2?"

Not yet, I can try that if you think it may help. Switching to the qt5 backend will obviously produce different results, but...it feels like a weird way to resolve the gtk backend crashing when it shouldn't. :D

[Paulo Assis]

If the problem is in sdl2, then using the qt interface shouldn't make any difference.
The crash should happen any way.
If the problem is in the gtk interface, then yes, using the qt interface should produce a different output

[Adam Williamson]

OK, if it will help with triaging I'll try both and report back. thanks!

[Adam Williamson]

OK, so, found out a couple of things:

1. Building with SFML does indeed seem to avoid the problem. Tried running an SFML build twice and letting it run for a while, it didn't crash.
2. The crash seems to be Wayland-specific. When running on X.org, the crash doesn't happen. This might explain why folks have had trouble reproducing it outside of Fedora, I guess. Edit: looks like it may even be GNOME-on-Wayland specific; Neal Gompa says it doesn't crash on KDE-on-Wayland.

Didn't try qt UI-on-SDL yet, will try that next.

[Adam Williamson]

qt5 with SDL does not solve the crash, and we get a pretty weird backtrace that goes qt5->glib->gdk->gtk3:

               Stack trace of thread 266293:
                #0  0x0000000200400310 n/a (n/a + 0x0)
                #1  0x00007fa81573c979 gtk_css_node_real_update_style (libgtk-3.so.0 + 0x13c979)
                #2  0x00007fa8157398eb gtk_css_node_ensure_style.part.0 (libgtk-3.so.0 + 0x1398eb)
                #3  0x00007fa815739b88 gtk_css_node_validate_internal.part.0 (libgtk-3.so.0 + 0x139b88)
                #4  0x00007fa815739bdb gtk_css_node_validate_internal.part.0 (libgtk-3.so.0 + 0x139bdb)
                #5  0x00007fa815739bdb gtk_css_node_validate_internal.part.0 (libgtk-3.so.0 + 0x139bdb)
                #6  0x00007fa815739bdb gtk_css_node_validate_internal.part.0 (libgtk-3.so.0 + 0x139bdb)
                #7  0x00007fa81571b26b gtk_container_idle_sizer (libgtk-3.so.0 + 0x11b26b)
                #8  0x00007fa82d7a0e85 signal_emit_valist_unlocked (libgobject-2.0.so.0 + 0x33e85)
                #9  0x00007fa82d7a0f91 g_signal_emit_valist (libgobject-2.0.so.0 + 0x33f91)
                #10 0x00007fa82d7a1053 g_signal_emit (libgobject-2.0.so.0 + 0x34053)
                #11 0x00007fa81554ca17 gdk_frame_clock_paint_idle (libgdk-3.so.0 + 0x47a17)
                #12 0x00007fa815538c7d gdk_threads_dispatch (libgdk-3.so.0 + 0x33c7d)
                #13 0x00007fa82d312799 g_timeout_dispatch (libglib-2.0.so.0 + 0x5c799)
                #14 0x00007fa82d311e5c g_main_context_dispatch_unlocked.lto_priv.0 (libglib-2.0.so.0 + 0x5be5c)
                #15 0x00007fa82d36cf18 g_main_context_iterate_unlocked.isra.0 (libglib-2.0.so.0 + 0xb6f18)
                #16 0x00007fa82d30fad3 g_main_context_iteration (libglib-2.0.so.0 + 0x59ad3)
                #17 0x00007fa830d073b9 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x3073b9)
                #18 0x00007fa830cb383b _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2b383b)
                #19 0x00007fa830cbbacb _ZN16QCoreApplication4execEv (libQt5Core.so.5 + 0x2bbacb)
                #20 0x000055788d07f7bb main (guvcview + 0x137bb)
                #21 0x00007fa83044614a __libc_start_call_main (libc.so.6 + 0x2814a)
                #22 0x00007fa83044620b __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2820b)
                #23 0x000055788d0802c5 _start (guvcview + 0x142c5)

[Adam Williamson]

it's kinda starting to look a lot like this isn't a guvcview issue, anyway. will probably move it to gtk or mutter or something soon.

[Adam Williamson]

Filed https://gitlab.gnome.org/GNOME/gtk/-/issues/6611 .