gh-149816: Fix race conditions in Modules/_elementtree.c with free-threaded

[ByteFlowing1337]

This PR fixes (69) Unsynchronized extra pointer dereference in len in Modules/_elementtree.c mentioned in #149816.
It also fixes race condition in getting attrib.

• Issue: 22 free-threading race conditions #149816

[ByteFlowing1337]

@dpdani Thanks for you review!

[devdanzin]

Independent confirmation of item (69) "Unsynchronized extra pointer dereference in len in Modules/_elementtree.c", found by ThreadSanitizer fuzzing (fusil --tsan). Worth noting the race is a bit broader than a read-deref: it's a write/write on the lazily-allocated self->extra, because the if (!self->extra) create_extra(...) guard in the extra accessors isn't atomic. Two threads first-touching a shared Element both take the !self->extra branch and both run create_extra, which does self->extra = PyMem_Malloc(...) (_elementtree.c:274) with no critical section — so one allocation is overwritten (leaked) and readers can observe a torn pointer.

Minimal deterministic reproducer (exit 66 under TSan; create_extra:274 as the write, reached via element_attrib_getter / element_length):

importthreadingimportxml.etree.ElementTreeasETNTHREADS=8barrier=threading.Barrier(NTHREADS)
defworker(elem):
barrier.wait()
for_inrange(4000):
_=elem.attrib# if (!self->extra) create_extra(...) -- unlocked lazy init_=len(elem) # element_length reads self->extrafor_inrange(200):
shared=ET.Element("tag") # extra == NULL until first attrib/child touchts= [threading.Thread(target=worker, args=(shared,)) for_inrange(NTHREADS)]
fortints: t.start()
fortints: t.join()

Confirmed still present on current main (3.16.0a0), on both a debug and a release --with-thread-sanitizer build. PR #149918's approach — taking Py_BEGIN_CRITICAL_SECTION(self) around the if (!self->extra) create_extra(...) check-and-create and the other extra accessors — covers this (both the read-deref and the write/write faces). Faces the fuzzer also hit: create_extra | element_length and clear_extra | create_extra.

(Found by fusil --tsan, a ThreadSanitizer fuzzer; draft and reproducer by Claude Code, minimized and reviewed by hand.)

[dpdani]

Unfortunately, this approach is not going to be effective. While it does resolve the sharpest edges, it still leaves some race conditions that need to be resolved.

[dpdani]

Don't do locking here. There are a few callers of this function, and locking should be moved to the callers. For instance, this code in element_resize would not be thread safe with an inner critical section:

if (!self->extra) {
if (create_extra(self, NULL) <0)
return-1;
}

Allocations and init functions need not be thread safe.

[dpdani]

Do not add locking here. The only code path that may call this code concurrently is in element_setstate_from_attributes, and locking should be moved there. It is probably needed anyway by the looks of it.

[dpdani]

The GC runs during a stop-the-world pause, so there's no need for locking here.