GH-93728: fix memory leak in deepfrozen code objects #93729
Conversation
|
Skipping news as no release is affected. |
|
Valgrind report with fix: ==27367== HEAP SUMMARY:
==27367== in use at exit: 0 bytes in 0 blocks
==27367== total heap usage: 19,728 allocs, 19,728 frees, 2,629,532 bytes allocated
==27367==
==27367== All heap blocks were freed -- no leaks are possible
==27367==
==27367== Use --track-origins=yes to see where uninitialised values come from
==27367== For lists of detected and suppressed errors, rerun with: -s
==27367== ERROR SUMMARY: 40 errors from 12 contexts (suppressed: 0 from 0)
|
|
I had an inkling that something was off about my PR (things were going too well :), but I'm really glad you caught this before any releases went out. Thanks again Kumar. |
From my very rudimentary understanding of deepfreeze, this LGTM.
Yeah, its nice that no release has this leak and I caught this early in 3.12 dev cycle. |
LGTM.
The co_code field is a cache for the co_code attribute, initialized to NULL in init_code(), set to a bytes object (caching the deoptimized code) in _PyCode_GetCode() and decref'ed in code_dealloc(). It is also (implicitly) initialized to NULL in deepfreeze (since the real bytecode lives in co_code_adaptive). So it makes sense that clearing it is the right thing to do when restoring the initial state.
(Using .replace() sets co_code to the deoptimized code if it wasn't passed in, I think that is due to the way that API works.)
Closes #93728