Make `xml.etree.ElementTree.Element` usable on free-threaded builds

[sampsonc]

Crash report

What happened?

Descriptino
_elementtree.c declares Py_MOD_GIL_NOT_USED but has zero @critical_section annotations. element_getitem() checks self->extra != NULL then dereferences self->extra->children[index], but with no lock between the check and the use. Concurrent elem.clear() sets self->extra = NULL and frees the children array between those two operations, causing a NULL dereference.

Repro Code

import sys
import threading
from xml.etree.ElementTree import Element

if sys._is_gil_enabled():
    sys.exit("SKIP: requires --disable-gil build")

NUM_THREADS = 4
ITERS = 5_000_000

elem = Element('root')
for i in range(10):
    elem.append(Element(f'child{i}'))

def reader():
    for _ in range(ITERS):
        try:
            _ = elem[0]
        except IndexError:
            pass

def writer():
    for _ in range(ITERS):
        elem.clear()
        for i in range(10):
            elem.append(Element(f'child{i}'))

readers = [threading.Thread(target=reader) for _ in range(NUM_THREADS)]
writers = [threading.Thread(target=writer) for _ in range(NUM_THREADS)]
for t in writers + readers:
    t.start()
for t in writers + readers:
    t.join()

print("Completed without crash.")

Output
[1] 40136 segmentation fault ./python3 /tmp/test_elementtree_race.py

CPython versions tested on:

3.15, CPython main branch

Operating systems tested on:

macOS

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

Python 3.15.0a7+ free-threading build (heads/main:e167e06f8c6, Mar 15 2026, 09:14:39) [Clang 17.0.0 (clang-1700.6.4.2)]

Linked PRs

• gh-146022: Fix free-threading crash in xml.etree.ElementTree's Element #157000

[picnixz]

I am not entirely sure that ElementreTree is actually safe under free-threading. We did add some locks here and there but I don't recall having used critical sections when I fixed UAFs.

[picnixz]

FTR: I don't want an LLM doing those changes. I want a core developer doing them or someone that has contributed enough to CPython because the implementation is non-trivial.