Bug#1124932: gnome-shell: Sometimes segfaults when attempting to unlock VeraCrypt volume with wrong password

[Simon McVittie]

On Wed, 07 Jan 2026 at 14:27:26 +0100, intrigeri wrote:
>I could not reproduce this bug on current sid so my best hope is that this
>behavior rings a bell to one of you, and the fix can cheaply be backported
>to Trixie.

There are various upstream crash fixes in both gnome-shell and mutter 
queued in trixie-proposed-updates to be released in this weekend's point 
release, although none of them look obviously related to this at first 
glance. *Possibly* 
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8651 ?

>I've installed systemd-coredump and the relevant -dbgsym packages until I got
>a core dump that's hopefully somewhat useful to you. The core dump is 411 MB
>large, I can upload it somewhere if someone has capacity to dive into this.

The core dump itself is unlikely to be amazingly useful (and might 
contain sensitive memory contents if this is a non-expendable install), 
but if you can attach gdb to it for post-mortem debugging and get a 
backtrace from gdb, that might help to point to specific code. See: 
https://wiki.debian.org/HowToGetABacktrace

gdb knows how to use -dbgsym packages and/or 
DEBUGINFOD_URLS=https://debuginfod.debian.net to provide extra detail in 
backtraces, such as the specific source file and line number at which a 
crash happened. systemd-coredump not so much, but it does save the 
core dump for later inspection by `coredumctl gdb`.

>6. Most of the time, this works, as in I see "Sorry, that didn't work.
>   Please try again." Sometimes gnome-shell and  gvfs-udisks2-volume-monitor
>   segfault and I'm back to GDM.

Regardless of anything that is happening in gnome-shell, 
gvfs-udisks2-volume-monitor shouldn't segfault, so there might be a 
separate bug in src:gvfs there.

>                #0  0x00007fc975065a56 CLUTTER_IS_CONTENT (libmutter-clutter-16.so.0 + 0x63a56)
>                #1  0x00007fc9758fcee2 g_cclosure_marshal_VOID__BOOLEANv (libgobject-2.0.so.0 + 0x19ee2)
>                #2  0x00007fc9758fab81 _g_closure_invoke_va (libgobject-2.0.so.0 + 0x17b81)
>                #3  0x00007fc9759108b8 signal_emit_valist_unlocked (libgobject-2.0.so.0 + 0x2d8b8)
>                #4  0x00007fc9759165a6 g_signal_emit_valist (libgobject-2.0.so.0 + 0x335a6)
>                #5  0x00007fc975916663 g_signal_emit (libgobject-2.0.so.0 + 0x33663)
>                #6  0x00007fc97509f70b emit_frame_signal (libmutter-clutter-16.so.0 + 0x9d70b)
>                #7  0x00007fc9750a0826 clutter_timeline_do_frame (libmutter-clutter-16.so.0 + 0x9e826)
>                #8  0x00007fc9750a11c0 _clutter_timeline_do_tick (libmutter-clutter-16.so.0 + 0x9f1c0)
>                #9  0x00007fc97507107d advance_timelines (libmutter-clutter-16.so.0 + 0x6f07d)

This looks like a use-after-free: something has set up a signal handler 
to call a method on a ClutterContent object (or involving a 
ClutterContent object in some way) every time a new frame is rendered, 
but has not disconnected the signal handler before the object is 
destroyed, and the precondition check "is this even a valid 
ClutterContent?" is accessing the freed memory and segfaulting.

It's difficult to tell *which* signal handler: it could be anything that 
connects to ClutterTimeline::new-frame. A traceback with source 
file/line markers from gdb might tell us more, if the necessary 
information hasn't been optimized out.

ClutterContent is something to do with how the Shell renders the scene 
internally - probably either a foreign window that it is compositing, or 
a UI widget in its own UI.

     smcv