PyCode_Addr2Line shouldn't lock in free threaded Python

[colesbury]

Bug report

In #138664 we added a critical section on the code object in PyCode_Addr2Line to fix crashes involving profiling.

There are two problems with using a lock here:

1. Code objects are shared across threads and PyCode_Addr2Line is a frequently function, leading to contention during profiling.

2. This introduces a stop-the-world safe point in profiling code, which can cause bugs if the profiling code isn't expecting it. For example, PyTorch's profiler isn't robust to a stop-the-world event (or GIL release) happening during profiling, and this leads to crashes. The problem is essentially:

• PyTorch assumes that after PyEval_SetProfileAllThreads(NULL, NULL); no threads are still in the PyTorch profile code. This is incorrect due to the PyCode_Addr2Line() critical section suspending the thread state in the middle of a profile
• PyTorch frees a bunch of profiler state, but thread suspended on PyCode_Addr2Line() resumes and tries reading that state leading to a crash.

This is a bug in PyTorch, so I'm going to fix it there as well, but the critical section in PyCode_Addr2Line() makes it much more likely to encounter the bug.

Proposed fix to CPython

1. No critical section in PyCode_Addr2Line. Use atomic reads on co->_co_monitoring and co->_co_monitoring->lines
2. Use atomic stores to initialize co->_co_monitoring and co->_co_monitoring->lines and reorder the stores so that the contents are initialized before the pointer is stored.

cc @kumaraditya303

Linked PRs

• gh-148037: remove critical section from PyCode_Addr2Line #148103
• [3.14] gh-148037: remove critical section from PyCode_Addr2Line (GH… #148353

[kumaraditya303]

I think update_instrumentation_data would also have to be modified to not mutate the existing _co_monitoring data so that concurrent readers can access fields without races, it should allocate a new _PyCoMonitoringData data every time instrumentation needs to be updated and old data should be freed with qsbr.

[colesbury]

I think it might be simpler than that. As I understand it, once code->_co_monitoring->lines is initialized, it's no longer modified until the code object is deallocated.

So I think it would look something like:

1. Initialize _co_monitoring fields to NULL / zero before assigning to code->_co_monitoring
2. Initialize line data before assigning it to code->_co_monitoring->lines

I think the other parts of update_instrumentation_data don't need to be changed.

I think it's also always safe, but less efficient, to fall back to the _PyCode_CheckLineNumber code path in _PyCode_Addr2Line.

[kumaraditya303]

@colesbury Are you planning to work on this or should I work on this?

[colesbury]

If you have time, please take it

…

On Sat, Apr 4, 2026 at 1:19 PM Kumar Aditya ***@***.***> wrote: @colesbury <https://github.com/colesbury> Are you planning to work on this or should I take on this? — Reply to this email directly, view it on GitHub <#148037 (comment)> or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFAD6SXAU24YJZJPOZJYW34UE72XBFKMF2HI4TJMJ2XIZLTTGBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDUOJ2WLJDOMFWWLLTXMF2GG2C7MFRXI2LWNF2HTAVFOZQWY5LFUVUXG43VMWSG4YLNMWVXI2DSMVQWIX3UPFYGLAVFOZQWY5LFVA2TSNRQG43DKNFENZQW2ZNIMFRXI33SL5UWJAVFOZQWY5LFVE2TGNRYG4YTONZQURXGC3LFVFUGC427NRQWEZLMQKSXMYLMOVS2UNBQGE4DMNRYG4YTRJDOMFWWLKLIMFZV63DBMJSWZAVFOZQWY5LFVI3DCNBQGQZDMNZRGOSG4YLNMWUWQYLTL5WGCYTFNSBKK5TBNR2WLKRWHEZDIOBYGEYDIMVENZQW2ZNJNBQXGX3MMFRGK3ECUV3GC3DVMWVDQNJXGQ2DENZQGMY2I3TBNVS2S2DBONPWYYLCMVWKY43VMJVGKY3UL52HS4DFVREXG43VMVBW63LNMVXHJJTUN5YGSY3TSKBKI5DZOBS2U4TFOBXXG2LUN5ZHTJLWMFWHKZNIHAYTKOJYHE3DDAVEOR4XAZNFNFZXG5LFUV3GC3DVMWVDIMRQGA3DONZZGQZKO5DSNFTWOZLSUZRXEZLBORSQ> . You are receiving this email because you are subscribed to this thread. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> .

[kumaraditya303]

I created #148103 which removes the critical section. For initializing code->_co_monitoring->lines one complication is that initialize_lines calls _Py_GetBaseCodeUnit which internally may access code->_co_monitoring->lines which would be NULL as the lines is not stored in the code object yet. I am not 100% sure but I think this access should not happen because it only happens when opcode=INSTRUMENTED_LINE which should not be the case when initialize_lines is called.