Activity

1. ericsnowcurrently

   added

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   topic-C-API

   3.12only security fixesonly security fixes

   3.13only security fixesonly security fixes

   3.14bugs and security fixesbugs and security fixes

   on Sep 26, 2024
2. ZeroIntensity

   marked Debug build assertion failure with native threads attempting to acquire GIL on termination #131012 as a duplicate of this issue on Mar 10, 2025
3. picnixz

   marked Crash with PyGILState_Ensure called from background thread during finalization on Python 3.14.0a7 #132948 as a duplicate of this issue on Apr 25, 2025
4. ZeroIntensity

   marked Crash in PyGILState_Ensure during _Py_Finalize #142135 as a duplicate of this issue on Dec 1, 2025
5. Sccucci84 commented on Sep 1, 2026

   

   Sccucci84

   on Sep 1, 2026

   Last edited by Sccucci84

   More actions

   Hitting what looks like this same crash in real-world (non-synthetic) code, via PyGObject + GDBus, on Python 3.14.7 — so this is still unfixed on stable 3.14, not just the 3.14.0a7 build from #132948.

   Reproducer: powerprofilesctl get (a short-lived Python script shipped with power-profiles-daemon, using PyGObject to talk to power-profiles-daemon over D-Bus). It queries the current profile, prints it, and exits. Invoked frequently (once per status-bar poll interval) it segfaults intermittently with SIGSEGV / SEGV_MAPERR.

   coredumpctl info backtrace of the crashing thread (a GDBus worker thread, not the main thread):

   Stack trace of thread 284370 (gdbus):
   #0  0x00007fa616eaa612 n/a (libpython3.14.so.1.0 + 0x2aa612)
   #1  0x00007fa616e393ad PyEval_RestoreThread (libpython3.14.so.1.0 + 0x2393ad)
   #2  0x00007fa616f2a66a PyGILState_Ensure (libpython3.14.so.1.0 + 0x32a66a)
   #3  0x00007fa616a6156e n/a (_gi.cpython-314-x86_64-linux-gnu.so + 0x1156e)
   #4  0x00007fa615fd2cd9 n/a (libglib-2.0.so.0 + 0x35cd9)
   #5  0x00007fa615f5ca90 g_object_unref (libgobject-2.0.so.0 + 0x22a90)
   #6  0x00007fa614920720 n/a (libgio-2.0.so.0 + 0x10c720)
   ...
   #11 0x00007fa616001217 g_main_loop_run (libglib-2.0.so.0 + 0x64217)
   

   Frame #0 is unresolved (no debug symbols on this build), but given PyEval_RestoreThread → PyGILState_Ensure directly above it, it's almost certainly the same _PyThreadState_Attach/bind_gilstate_tstate path as the original report.

   At the same instant, the main thread is already inside exit():

   Stack trace of thread 284367 (main):
   #2  n/a (libc.so.6 + 0x40fbf)
   #3  exit (libc.so.6 + 0x4109e)
   #4  n/a (libc.so.6 + 0x27788)
   #5  __libc_start_main (libc.so.6 + 0x278b9)
   

   Mechanism appears to be: the main thread finishes and calls exit(), kicking off interpreter finalization, while a GDBus-owned worker thread is mid-g_object_unref on a proxy/connection object and its GObject finalizer calls back into Python (PyGObject's _gi), which calls PyGILState_Ensure() on a thread state that finalization has already begun tearing down.

   Reproduced twice on this machine so far (identical stack both times), a few days apart, under ordinary desktop use — no synthetic thread-spam required, just a program that talks to D-Bus from a background thread and exits promptly afterward. Given power-profiles-daemon, NetworkManager's Python bindings, and plenty of other GLib/GDBus-using Python tools follow this same "spin up async D-Bus, do one thing, exit" pattern, this is likely to affect more than just this one tool as more distros ship 3.14.
6. pull

   added a commit that references this issue on Sep 13, 2026

   Poll the active power profile over D-Bus instead of powerprofilesctl

   ...

   55799c4