Skip to content

Segfault from unicodedata.iter_graphemes on a free threaded build #145202

Description

@devdanzin

Crash report

What happened?

A free-threaded build will segfault when calling unicodedata.iter_graphemes() and storing the result, even with PYTHON_GIL=0.

import unicodedata

res = unicodedata.iter_graphemes("a")

Backtrace:

Program received signal SIGSEGV, Segmentation fault.
GBI_dealloc (self=0x20002ac2b60) at ./Modules/unicodedata.c:1992
1992        Py_DECREF(((GraphemeBreakIterator *)self)->iter.str);

#0  GBI_dealloc (self=0x20002ac2b60) at ./Modules/unicodedata.c:1992
#1  0x000055555573b0b7 in _Py_Dealloc (op=0x20002ac2b60) at Objects/object.c:3271
#2  0x000055555570cbce in Py_DECREF (lineno=513, op=0x20002ac2b60, filename=<optimized out>) at ./Include/refcount.h:356
#3  Py_XDECREF (op=0x20002ac2b60) at ./Include/refcount.h:513
#4  dictkeys_decref (dk=dk@entry=0x200020d4a10, use_qsbr=true) at Objects/dictobject.c:494
#5  0x000055555571132b in clear_lock_held (op=op@entry=0x2000270ccd0) at Objects/dictobject.c:2998
#6  0x0000555555711578 in PyDict_Clear (op=0x2000270ccd0) at Objects/dictobject.c:3027
#7  0x00005555557174a9 in dict_tp_clear (op=0x20002ac2b60) at Objects/dictobject.c:4843
#8  0x00005555558f5c61 in delete_garbage (state=0x7fffffffd5c0) at Python/gc_free_threading.c:1780
#9  gc_collect_internal (interp=0x555555d33880 <_PyRuntime+174016>, state=0x7fffffffd5c0, generation=2) at Python/gc_free_threading.c:2375
#10 gc_collect_main (tstate=0x555555d6bfd8 <_PyRuntime+405272>, generation=2, reason=_Py_GC_REASON_SHUTDOWN) at Python/gc_free_threading.c:2446
#11 0x000055555594203e in finalize_modules (tstate=tstate@entry=0x555555d6bfd8 <_PyRuntime+405272>) at Python/pylifecycle.c:1793
#12 0x000055555594081a in _Py_Finalize (runtime=<optimized out>) at Python/pylifecycle.c:2295
#13 0x00005555559aa459 in Py_RunMain () at Modules/main.c:774
#14 0x00005555559aafe1 in pymain_main (args=args@entry=0x7fffffffda40) at Modules/main.c:802
#15 0x00005555559ab042 in Py_BytesMain (argc=<optimized out>, argv=0xffffffffffffffe8) at Modules/main.c:826
#16 0x00007ffff7c2a575 in __libc_start_call_main (main=main@entry=0x5555555ed170 <main>, argc=argc@entry=2, argv=argv@entry=0x7fffffffdb98) at ../sysdeps/nptl/libc_start_call_main.h:58
#17 0x00007ffff7c2a628 in __libc_start_main_impl (main=0x5555555ed170 <main>, argc=2, argv=0x7fffffffdb98, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
    stack_end=0x7fffffffdb88) at ../csu/libc-start.c:360
#18 0x00005555555ed0a5 in _start ()

Found using fusil by @vstinner.

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

Output from running 'python -VV' on the command line:

Python 3.15.0a6+ free-threading build (heads/main:1ac9d138ae0, Feb 25 2026, 05:27:56) [Clang 21.1.2 (2ubuntu6)]

Linked PRs

Activity

  1. added a commit that references this issue on Feb 25, 2026
  2. added a commit that references this issue on Feb 25, 2026
  3. serhiy-storchaka commented on Feb 25, 2026

    @serhiy-storchaka
    Member

    Good catch. I think that remove the tp_clear slots would be a better solution. These objects are virtually immutable and cannot create a loop (they can only participate in a loop created by a str subclass).

  4. added a commit that references this issue on Feb 26, 2026
  5. added a commit that references this issue on Feb 28, 2026
  6. added a commit that references this issue on Apr 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions