Bug report
Bug description:
I'm reviewing the https://github.com/python/cpython/blob/main/Modules/_ctypes/callproc.c. I believe I found a possible UB if resize and byref/addressof are used from different threads without any locking (AFAIU it is valid for free-threaded build and not for GIL-enabled).
resize does realloc -
|
void * ptr = PyMem_Realloc(obj->b_ptr, size); |
|
if (ptr == NULL) |
|
return PyErr_NoMemory(); |
|
obj->b_ptr = ptr; |
|
obj->b_size = size; |
After realloc the old value of obj->b_ptr is no longer valid, and any access to it is UB. If another thread calls addressof
|
return PyLong_FromVoidPtr(((CDataObject *)obj)->b_ptr); |
or
byref
|
parg->value.p = (char *)((CDataObject *)obj)->b_ptr + offset; |
, it may potentially get UB under heavy contention (I believe it is zero or less real cases so far).
Should we protect them with LOCK_PTR?
CPython versions tested on:
CPython main branch
Operating systems tested on:
No response
Linked PRs
Bug report
Bug description:
I'm reviewing the https://github.com/python/cpython/blob/main/Modules/_ctypes/callproc.c. I believe I found a possible UB if
resizeandbyref/addressofare used from different threads without any locking (AFAIU it is valid for free-threaded build and not for GIL-enabled).resizedoesrealloc-cpython/Modules/_ctypes/callproc.c
Lines 1934 to 1938 in d07e9eb
After
reallocthe old value ofobj->b_ptris no longer valid, and any access to it is UB. If another thread callsaddressofcpython/Modules/_ctypes/callproc.c
Line 1847 in d07e9eb
byrefcpython/Modules/_ctypes/callproc.c
Line 1827 in d07e9eb
Should we protect them with
LOCK_PTR?CPython versions tested on:
CPython main branch
Operating systems tested on:
No response
Linked PRs