Repository navigation
Segfault in modesetting_drv.so on window teardown (DeleteWindow/FreeResource), hybrid Intel + NVIDIA (Blackwell), reproducible on lid-close and on ordinary app launch #3678
Description
Environment
- Distro: OpenMandriva ROME (rolling), KDE Plasma, X11 session (
plasmax11) - XLibre:
xlibre-25.1.2-1(also seen asXLibre X Server 1.25.1.2in the server's own version banner) - Kernel:
7.0.3-desktop-1omv2602 - GPU 0 (primary, drives the only physical outputs: internal panel
eDP-1and an external monitor via NVIDIA): Intel Arrow Lake HX iGPU,i915/xedriver, using themodesettingX driver - GPU 1 (secondary/render-offload, PRIME): NVIDIA GeForce RTX 5080 (Blackwell, GB203M), proprietary driver
610.43.02(nvidia-dkms-kmod-open),nvidia_drv.so - No MUX switch. Internal panel is wired only to Intel; NVIDIA drives an external monitor over HDMI when connected
xorg.conf.d: NVIDIAOutputClasspresent but withoutPrimaryGPU(explicitly removed; Intel stays primary since it's the only GPU with real outputs)
Symptom
Xorg segfaults (SIGSEGV at Segmentation fault at address 0x2b1, then SIGABRT on the coredump handler), killing the whole session. Identical crash address and backtrace reproduced from two unrelated triggers:
- Lid-close while an external monitor is actively connected to the NVIDIA GPU (internal
eDP-1disconnects abruptly as a hardware event) - Launching an ordinary app (KolourPaint, a plain Qt widget app, no GPU/monitor state change involved): same exact crash address and backtrace
This strongly suggests a general bug in window/resource teardown in modesetting_drv.so, not something specific to output hotplug.
Backtrace (identical across multiple occurrences, only ASLR base addresses differ)
Backtrace:
0: /usr/libexec/Xorg (xorg_backtrace+0x4d)
1: /usr/libexec/Xorg (+0x1f2b16)
2: /lib64/libc.so.6 (+0x40df0)
3: /usr/lib64/xorg/modules/xlibre-25/drivers/modesetting_drv.so (+0x1d65a)
4: /usr/libexec/Xorg (+0x15c974)
5: /usr/libexec/Xorg (+0x15cd00)
6: /usr/libexec/Xorg (_CallCallbacks+0x3f)
7: /usr/libexec/Xorg (+0x117efa)
8: /usr/libexec/Xorg (DeleteWindow+0x254)
9: /usr/libexec/Xorg (FreeResource+0x1ac)
10: /usr/libexec/Xorg (+0xc71eb)
11: /usr/libexec/Xorg (+0xdda44)
12: /usr/libexec/Xorg (+0x2a2963)
13: /lib64/libc.so.6 (+0x2ad75)
14: /lib64/libc.so.6 (__libc_start_main+0x87)
15: /usr/libexec/Xorg (_start+0x21)
Segmentation fault at address 0x2b1
Caught signal 11 (Segmentation fault). Server aborting
Reproduction
- Boot with the internal panel active and an external monitor connected via the NVIDIA GPU's HDMI output.
- Either:
- a) Close the laptop lid (internal panel disconnects), or
- b) Simply launch an ordinary application (e.g. KolourPaint)
- Xorg segfaults within about 1 second, session dies, SDDM restarts X.
Workarounds found
- For the lid-close trigger specifically: gracefully disabling the internal output via RandR before the hardware disconnect avoids the crash entirely.
xrandr --output eDP-1 --offbefore closing the lid,--autoafter opening. Automated this via a small systemd user service watchinglogind'sLidClosedD-Bus property, since a raw hardware-initiated disconnect (not a software-initiated one) appears to be what triggers the bug. - Tried switching KWin's X11 compositing backend from OpenGL to XRender as a possible general mitigation (theory: GPU-backed pixmap-per-window teardown via OpenGL/DRI3 is the trigger). This appeared to prevent one KolourPaint-triggered recurrence in testing, but the lid-close trigger still crashed afterward with XRender active, so this is not a confirmed fix; likely only reduces exposure, or the KolourPaint fix was coincidental.
Notes
- Not a KScreen/Plasma config issue. Checked Plasma's own saved per-topology display configs,
eDP-1stays enabled in every saved profile; Plasma isn't the one issuing a software output-disable. NVIDIA(0): Option "PrimaryGPU" is not usedwarning is expected/intentional in our config (Intel is primary since it's the only GPU with a physically wired output on this hardware).
Activity
DSanna commentedon Sep 2, 2026
Additional occurrence, same crash address and backtrace, but this one resolved a symbol the earlier reports did not have: the crash is inside
ms_present_abort_vblankinmodesetting_drv.so, called fromDeleteWindow. Full relevant frames:Also noting a side effect this time: since the internal laptop lid had been closed continuously for over a day (external monitor + external keyboard in use), when this crash killed the session it also released KDE PowerDevil's systemd inhibitor lock for lid-switch handling, which let systemd-logind fall back to its own default lid-close handling (since the lid switch was still reporting closed) and triggered an unwanted suspend/resume cycle on top of the crash. Not a new bug on its own, just a compounding effect worth noting for anyone else debugging a similar crash-plus-unexpected-suspend combination.
DSanna commentedon Sep 13, 2026
Another occurrence, same exact backtrace as before (
ms_present_abort_vblank->present_destroy_window->DeleteWindow->FreeResource,Segmentation fault at address 0x2b1), but this time from a third, previously unseen trigger: unlocking from the KDE lock screen (kscreenlocker_greet) after being locked overnight. Confirmed via the X11-connection-broke log lines,kscreenlocker_greetis in the list of processes that lost their connection at the exact crash timestamp, so the lock screen was up when it happened.So far this bug has now been triggered by three unrelated actions, all involving window teardown: an abrupt output disconnect (lid-close with an external monitor active), launching an ordinary app (a new window being created), and now unlocking (the lock screen's greeter window being torn down). Reinforces that this looks like a general bug in the window-delete/resource-free path in
modesetting_drv.so, not something specific to any one trigger.Environment unchanged from the original report (OpenMandriva ROME, XLibre 25.1.2, hybrid Intel + NVIDIA Blackwell, NVIDIA proprietary driver 610.43.02).
fish4terrisa-MSDSM commentedon Sep 13, 2026
Are u using systemd? If so maybe get the Xorg core dump from systemd-coredump. U can upload it somewhere(or just change the file extension and upload it here), since u are using xlibre from a repo it'll be simple to get the binary and source code so we can check the core dump and see what went wrong.
DSanna commentedon Sep 13, 2026
xorg-crash-dump-20260913-192532.zip
Core dump attached: xorg-crash-dump-20260913-192532.zip, contains the raw systemd-coredump .zst file for the Xorg process (PID 1783, crashed 2026-09-13 19:25:32 CEST). Binary/source should match this repo build, environment is unchanged from the original report (OpenMandriva ROME, XLibre 25.1.2, hybrid Intel + NVIDIA Blackwell, NVIDIA proprietary driver 610.43.02).
Trigger this time was slightly different again: killing (SIGTERM via kill ) a running app whose window was open, rather than a normal window-close request or any of the other three triggers already on this thread. Same window-teardown shape as the others though, so this is likely just another path into the same DeleteWindow code, not a fourth distinct bug.