The vectors PYJLVALUES and PYJLFREEVALUES are modified without any protection against GC-triggered re-entrancy.

  _pyjl_dealloc(o1) or PyJuliaValue_SetValue
    └→ push!(PYJLFREEVALUES, idx)          # begins resize (sets internal flag)
         └→ vector must grow → allocates → triggers Julia GC
              └→ GC collects a Py object → runs py_finalizer
                   └→ enqueue(ptr) → PyGILState_Check()==1 (same thread holds GIL)
                        └→ Py_DecRef(ptr) → refcount hits 0
                             └→ _pyjl_dealloc(o2)
                                  └→ push!(PYJLFREEVALUES, idx2)   ← BOOM: flag already set
                                     ConcurrencyViolationError!

1. push! needs to grow the vector (exceeds capacity), so it allocates
2. The allocation triggers Julia GC, which runs finalizers
3. A finalizer calls Py_DecRef (because enqueue sees the GIL is held on this same thread), dropping refcount to 0, which triggers _pyjl_dealloc re-entrantly on the same vector

This is especially likely during shutdown (at_jl_exit → jl_atexit_hook), because jl_gc_run_all_finalizers runs finalizers on the calling thread (the main thread, which holds the GIL).
Many Py objects are finalized at once, repeatedly pushing to PYJLFREEVALUES, and each push that triggers a reallocation can cause the re-entrant chain.

Disabled Julia's GC during the critical vector modifications, so that push!/pop! cannot trigger allocation-based GC,
which prevents the finalizer chain from re-entering.
Added a SpinLock as defense-in-depth against true multi-thread races.