CachyOS / CachyOS/distribution

[Bug]: gtk4 4.22.4-1.1 lacks upstream GtkDragSource memory-corruption fix, causing Nautilus crashes

Open
#561 0 comments 0 reactions 0 assignees View on GitHub
bug
Dominant language
No language data
Stars
27
Forks
2
PR merge metrics
No merged PRs in 30d

Description

### Kernel

7.2.2-1-cachyos

### Desktop Environment / Window Manager

Other (specify in additional context)

### CPU

AMD Ryzen 5 7600 6-Core Processor

### GPU / Driver

AMD RX 6750 XT

### Description

Nautilus crashes when I navigate quickly through folders by double-clicking them
in rapid succession. The original crashes happened with `nautilus 50.2.2-1` and
were reproduced again with the current `nautilus 50.3-1.1`. GTK remained at
`1:4.22.4-1.1` in both tests. The crashes occurred as both `SIGABRT` and
`SIGSEGV`, with GTK/GObject widget and signal-handler teardown present in the
recorded backtraces.

Nautilus has since been updated to `50.3-1.1`, but GTK remains at
`1:4.22.4-1.1`. The Nautilus 50.3 NEWS and the complete diff from 50.2.2 to 50.3
do not contain changes related to `GtkDragSource`, double-click navigation or
this crash.

The evidence matches the upstream GTK bug and fix:

- GTK issue: https://gitlab.gnome.org/GNOME/gtk/-/work_items/8191
- Fix merged into GTK main: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/9913
- Backport for the `gtk-4-22` branch, currently still open:
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/10188

The fix adds the following cleanup before scheduling another timeout in
`gtk_drag_source_begin()`:

```c
g_clear_handle_id (&source->timeout_id, g_source_remove);
source->timeout_id = g_timeout_add (...);
```

I inspected `gtk_drag_source_begin()` in the installed CachyOS
`/usr/lib/libgtk-4.so.1`. The corresponding debug source and disassembly still
show only:

```c
source->timeout_id = g_timeout_add (MIN_TIME_TO_DND, drag_timeout, source);
```

The preceding `g_clear_handle_id()` call is absent. This indicates that the
installed CachyOS GTK build does not contain the upstream memory-corruption fix.

### Steps to Reproduce

1. Enable Nautilus double-click navigation:

```sh
gsettings set org.gnome.nautilus.preferences click-policy 'double'
```

2. Start Nautilus with a clean PATH, the stock Adwaita dark theme and OpenGL:

```sh
PATH=/usr/bin:/bin GTK_THEME=Adwaita:dark GSK_RENDERER=gl nautilus
```

3. Navigate quickly through several folders, opening each folder with a
double-click in rapid succession.

4. Repeat until Nautilus terminates.

5. The effective workaround is to use single-click navigation:

```sh
gsettings set org.gnome.nautilus.preferences click-policy 'single'

### Expected Behavior

Nautilus should continue navigating through folders without terminating,
regardless of how quickly folders are opened with double-click.

### Actual Behavior

With Nautilus 50.2.2, the application terminated with either `SIGABRT` or
`SIGSEGV`. One run ended with:

```text
g_signal_handler_disconnect: assertion 'handler_id > 0' failed
handler_unref_R: assertion failed: (hlist->tail_before == handler)
```

The coredump backtraces consistently passed through GTK/GObject teardown while
Nautilus cleared its view model, including frames such as:

```text
g_closure_unref
g_signal_handlers_destroy
g_object_unref
gtk_widget_remove_controller
g_hash_table_remove_all
g_hash_table_destroy
g_list_store_remove_all
Nautilus view/model frames
```

Current `nautilus 50.3-1.1` retest result:

The problem remains reproducible. I observed two visible crash attempts, while
systemd-coredump recorded three Nautilus `SIGSEGV` events within 25 seconds:

```text
2026-08-31 13:51:40 -03 PID 23821 SIGSEGV 15.2M
2026-08-31 13:51:58 -03 PID 25012 SIGSEGV 7.2M
2026-08-31 13:52:04 -03 PID 25074 SIGSEGV 7.3M
```

PID 23821 was the controlled terminal test using the clean `PATH`, Adwaita and
`GSK_RENDERER=gl`; PIDs 25012 and 25074 were launched by Niri. The first two
stacks reached GTK rendering/Wayland dispatch. PID 25074 again shows the prior
GTK/GObject teardown pattern, including repeated `g_object_unref`,
`g_hash_table_destroy`, `g_signal_emit`, `g_list_store_remove_all` and Nautilus
view/model frames. Because corruption can surface after its cause, the exact
top frame differs between runs.

### Logs / Error Messages

General CachyOS bug report captured after the original crashes: https://paste.cachyos.org/p/95b192d.log Sanitized Nautilus terminal logs and coredump excerpts: https://paste.cachyos.org/p/d359ae8 Current Nautilus 50.3 retest, sanitized log: https://paste.cachyos.org/p/5bd8752 Fresh CachyOS bug report for the current system state: https://paste.cachyos.org/p/b769a7b.log The original general report contains three Nautilus coredumps. The original sanitized log includes four recorded crashes, the controlled clean-environment reproduction and the fatal GLib assertion. The current retest log adds the three new `nautilus 50.3-1.1` coredumps listed above.

### Additional Context

My WM is Niri. Installed versions at the time of this report:

```text
nautilus 50.3-1.1
gtk4 1:4.22.4-1.1
glib2 2.88.3-1.1
libadwaita 1:1.9.3-1.1
```

The single-click preference is an effective workaround. Forcing
`GSK_RENDERER=gl`, using the stock Adwaita theme and removing the custom Python
environment from `PATH` did not prevent the original crash.

Could CachyOS please consider backporting the one-line GTK fix into its 4.22
package, or rebuilding GTK from a stable revision containing the fix?

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by comparing the CachyOS gtk4 1:4.22.4-1.1 package with the upstream gtk-4-22 branch and merge request 10188. Inspect gtk_drag_source_begin() and verify whether the timeout cleanup is present. Done means rebuilding or updating the package with the upstream fix and confirming that the reported Nautilus rapid double-click crash no longer reproduces.

Written by the indexing model from the issue text.

Assessment

Tech stack
linux
Domain
desktop
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
58/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.