pythongh-109534: get rid of bytearray as class member#115643
pythongh-109534: get rid of bytearray as class member#115643geraldog wants to merge 1 commit intopython:mainfrom
Conversation
Workaround horrendous memory leaks, does not solve the underlying issue of why bytearray as class member like that will cause leaks, at least in this case
|
The following commit authors need to sign the Contributor License Agreement: |
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
|
Tests will naturally fail as the function signature has changed, but before I put any more time into this I would like to hear from the maintainers about this kind of change. Naturally, the origin of the bug should be eventually traced and then finally after this hypothetical fix, bytearray as class member can be reinstated. That's the precise meaning of the term workaround. Meanwhile, real users are being affected by the issue, including at least me and @rojamit very badly. That's why we need this workaround for now until we can trace the real issue with memory allocating and never freeing outside the scope of the GC. |
|
This version isn't going to fly, the signature of |
|
Understood @gvanrossum I appreciate the sincere feedback. I do not have the time to track this further and it is beyond my expertise anyway, but let it be noted that bytearray as class member is causing at least the major part of the memory leak, and the description of the issue itself tells us 3.9 is unaffected - that's the timeframe for the introduction of bytearray as class member and I don't think it's mere coincidence. |
Confirmed by Issue author @rojamit that this workaround alleviates the memory leak.
This is just a simple workaround, it needs some more investigation on the C side of Python where the leak of bytearray as class member happens and why/how to fix it?