arraymodule, _decimal: possible lazy import caches reference leaks in free-threaded builds

@htjworld

Bug description:

As pointed out by @htjworld in #148088 (comment):

I was wondering about the lazy init pattern in a free-threaded build. If two threads enter build_struct_time concurrently with st->time_struct_time == NULL, both would call PyImport_ImportModuleAttrString and one overwrite would leave a reference with an incremented refcount that never gets decref'd.

I noticed arraymodule.c and _decimal.c have the same pattern, so maybe this is just accepted. But _asynciomodule.c initializes eagerly in module_init() which avoids this structurally. Was lazy chosen deliberately here over eager init in init_state()?

While I've addressed this in #148088, I think that this is a valid concern, and import caches should use CAS, just like:

cpython/Modules/_sre/sre.c

Lines 1173 to 1188 in 7e0a0be

    
               PyObject *func = FT_ATOMIC_LOAD_PTR(module_state->compile_template); 
        
               if (func == NULL) { 
        
                   func = PyImport_ImportModuleAttrString("re", "_compile_template"); 
        
                   if (func == NULL) { 
        
                       return NULL; 
        
                   } 
        
           #ifdef Py_GIL_DISABLED 
        
                   PyObject *other_func = NULL; 
        
                   if (!_Py_atomic_compare_exchange_ptr(&module_state->compile_template, &other_func, func))  { 
        
                       Py_DECREF(func); 
        
                       func = other_func; 
        
                   } 
        
           #else 
        
                   Py_XSETREF(module_state->compile_template, func); 
        
           #endif 
        
               }

If there's interest, I can do it.

(It seems similar to #149000, so perhaps a more thorough check warranted.)

CPython versions tested on:

CPython main branch

Operating systems tested on:

macOS

@maurycy

Hi @maurycy — interested in helping with this one. Happy to follow your lead since you opened it, but a couple of things I could pick up:

Take a first pass at the CAS fix for arraymodule.c or _decimal.c, whichever you're not already on
Grep around for other sites with the same pattern and post a checklist here

Or if you'd rather drive both, happy to just review. Let me know what works.

Hi @maurycy — interested in helping with this one. Happy to follow your lead since you opened it, but a couple of things I could pick up:

Take a first pass at the CAS fix for arraymodule.c or _decimal.c, whichever you're not already on

Grep around for other sites with the same pattern and post a checklist here

Or if you'd rather drive both, happy to just review. Let me know what works.

I'm not a core dev! Let's wait for a green light from the higher ups :-)

Navigation Menu

Repository navigation

`arraymodule`, `_decimal`: possible lazy import caches reference leaks in free-threaded builds #149006

Bug description:

CPython versions tested on:

Operating systems tested on:

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

	PyObject *func = FT_ATOMIC_LOAD_PTR(module_state->compile_template);
	if (func == NULL) {
	func = PyImport_ImportModuleAttrString("re", "_compile_template");
	if (func == NULL) {
	return NULL;
	}
	#ifdef Py_GIL_DISABLED
	PyObject *other_func = NULL;
	if (!_Py_atomic_compare_exchange_ptr(&module_state->compile_template, &other_func, func)) {
	Py_DECREF(func);
	func = other_func;
	}
	#else
	Py_XSETREF(module_state->compile_template, func);
	#endif
	}

arraymodule, _decimal: possible lazy import caches reference leaks in free-threaded builds #149006

Description

Bug description:

CPython versions tested on:

Operating systems tested on:

Activity

htjworld commented on Apr 26, 2026

maurycy commented on Apr 26, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

`arraymodule`, `_decimal`: possible lazy import caches reference leaks in free-threaded builds #149006