Directional segfault when dragging tab downwards or onto new window
Demo: [https://youtu.be/DEBopBzdzHw] (YouTube link demonstrating the bug and how to reproduce)
- Mousepad version 0.6.5
- gtk3 version 1:3.24.49-2
- gtk4 version 1:4.18.6-1
- I have not customized via a ~/.config file.
- The monitor that I am sharing in this video is the Samsung one, at the center of the setup.
Steps to reproduce:
- Open mousepad with multiple tabs
2a) Drag a tab out of the mousepad window, downwards (repeat until step 3)
2b) Drag a tab out of the mousepad window, into a different monitor
- Segfault (nullptr exception, 0x28)
Basic Valgrind output:
==23675== Invalid read of size 8
==23675== at 0x52DE12E: gtk_notebook_drag_end (gtknotebook.c:3743)
==23675== by 0x4AE448A: g_cclosure_marshal_VOID__OBJECTv (gmarshal.c:1910)
==23675== by 0x4B065F6: UnknownInlinedFun (gclosure.c:898)
==23675== by 0x4B065F6: signal_emit_valist_unlocked (gsignal.c:3438)
==23675== by 0x4B069DF: g_signal_emit_by_name (gsignal.c:3638)
==23675== by 0x5464E95: gtk_drag_source_info_destroy.lto_priv.0 (gtkdnd.c:2807)
==23675== by 0x4B065F6: UnknownInlinedFun (gclosure.c:898)
==23675== by 0x4B065F6: signal_emit_valist_unlocked (gsignal.c:3438)
==23675== by 0x4B069DF: g_signal_emit_by_name (gsignal.c:3638)
==23675== by 0x56A8CCC: data_source_dnd_finished (gdkselection-wayland.c:1169)
==23675== by 0x599EAC5: ffi_call_unix64 (unix64.S:104)
==23675== by 0x599B76A: ffi_call_int.lto_priv.0 (ffi64.c:676)
==23675== by 0x599E06D: ffi_call (ffi64.c:713)
==23675== by 0x61B690F: wl_closure_invoke.constprop.0 (connection.c:1228)
==23675== Address 0x28 is not stack'd, malloc'd or (recently) free'd
==23675==
==23675==
==23675== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==23675== Access not within mapped region at address 0x28
==23675== at 0x52DE12E: gtk_notebook_drag_end (gtknotebook.c:3743)
==23675== by 0x4AE448A: g_cclosure_marshal_VOID__OBJECTv (gmarshal.c:1910)
==23675== by 0x4B065F6: UnknownInlinedFun (gclosure.c:898)
==23675== by 0x4B065F6: signal_emit_valist_unlocked (gsignal.c:3438)
==23675== by 0x4B069DF: g_signal_emit_by_name (gsignal.c:3638)
==23675== by 0x5464E95: gtk_drag_source_info_destroy.lto_priv.0 (gtkdnd.c:2807)
==23675== by 0x4B065F6: UnknownInlinedFun (gclosure.c:898)
==23675== by 0x4B065F6: signal_emit_valist_unlocked (gsignal.c:3438)
==23675== by 0x4B069DF: g_signal_emit_by_name (gsignal.c:3638)
==23675== by 0x56A8CCC: data_source_dnd_finished (gdkselection-wayland.c:1169)
==23675== by 0x599EAC5: ffi_call_unix64 (unix64.S:104)
==23675== by 0x599B76A: ffi_call_int.lto_priv.0 (ffi64.c:676)
==23675== by 0x599E06D: ffi_call (ffi64.c:713)
==23675== by 0x61B690F: wl_closure_invoke.constprop.0 (connection.c:1228)
==23675== If you believe this happened as a result of a stack
==23675== overflow in your program's main thread (unlikely but
==23675== possible), you can try to increase the size of the
==23675== main thread stack using the --main-stacksize= flag.
==23675== The main thread stack size used in this run was 8388608.
==23675==
==23675== HEAP SUMMARY:
==23675== in use at exit: 20,678,221 bytes in 275,969 blocks
==23675== total heap usage: 995,266 allocs, 719,297 frees, 147,719,901 bytes allocated
==23675==
==23675== LEAK SUMMARY:
==23675== definitely lost: 198,170 bytes in 875 blocks
==23675== indirectly lost: 249,339 bytes in 9,928 blocks
==23675== possibly lost: 906,697 bytes in 15,297 blocks
==23675== still reachable: 15,508,815 bytes in 221,238 blocks
==23675== suppressed: 208 bytes in 1 blocks
==23675== Rerun with --leak-check=full to see details of leaked memory
==23675==
==23675== Use --track-origins=yes to see where uninitialised values come from
==23675== For lists of detected and suppressed errors, rerun with: -s
==23675== ERROR SUMMARY: 236 errors from 230 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)I've attached a video where I show my display setup and os info, but I will include them as attachments here as well:
OS: Arch Linux x86_64
Host: Laptop 16 (AMD Ryzen 7040 Series) (A7)
Kernel: Linux 6.15.4-arch2-1
Uptime: 2 hours, 24 mins
Packages: 1454 (pacman), 16 (flatpak)
Shell: bash 5.2.37
Display (Non-PnP): 1024x768 @ 75 Hz [External]
Display (LF22T35): 1920x1080 @ 75 Hz (as 1834x1031) in 22" [External]
Display (VG27AQ1A): 2560x1440 @ 144 Hz (as 2229x1253) in 27" [External] *
Display (BOE0BC9): 2560x1600 @ 165 Hz (as 2048x1280) in 16" [Built-in]
DE: KDE Plasma 6.4.2
WM: KWin (Wayland)
WM Theme: Breeze
Theme: Breeze (Dark) [Qt], Breeze-Dark [GTK2], Breeze [GTK3]
Icons: breeze-dark [Qt], breeze-dark [GTK2/3/4]
Font: Noto Sans (10pt) [Qt], Noto Sans (10pt) [GTK2/3/4]
Cursor: breeze (24px)
Terminal: konsole 25.4.3
CPU: AMD Ryzen 7 7840HS (16) @ 5.14 GHz
GPU 1: AMD Radeon RX 7700S [Discrete]
GPU 2: AMD Radeon 780M Graphics [Integrated]
Memory: 10.45 GiB / 54.72 GiB (19%)
Swap: Disabled
Disk (/): 40.03 GiB / 914.83 GiB (4%) - ext4
Disk (/mnt/data): 1.69 TiB / 3.58 TiB (47%) - ext4
Local IP (eth0): 10.0.0.241/24
Battery (FRANDBA): 93% [Charging, AC Connected]
Locale: en_US.UTF-8As you can see, I have a lot of monitors and they make an odd shape. That may contribute, it seems that the null pointer dereference (0x28) only occurs when I drag a tab out of the mousepad window downwards or onto different displays. I haven't tested via xfce running Wayland, so this could be a KWin only issue... not sure. That's my guess - but it could also be a Wayland issue, it occurs when I drag across different monitor contexts. I know that Mousepad's primary focus is on the Xfce desktop. However, since it is so easy to trigger I kindly request that you consider investigating, Mousepad is my preferred editor for now... The Valgrind output points to gtk_notebook_drag_end, suggesting maybe underlying GTK protocol issue that might manifest differently across compositors (unlikely), or it could be invalid data passed to it from Mousepad's understanding of the display/coordinate information it got from the compositor (very likely attempting to get the display information structure and getting a null pointer).