You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Memory leak when asyncio.open_connection raise #88863
This seems more like a gc issue as adding gc.collect() calls after each iteration fixes the leak.
That doesn't mean it is a GC issue. That means the GC is doing its work and the problem is that there are reference cycles to clean that until the GC runs they won't go away on their own.
It may be something to help here, but the GC is working as expected from this description.
After some investigation, the issue is that the raised exception's traceback forms ref cycles are eventually cleared by gc but causes increased memory usage. The following example does not form ref cycles and hence memory usage is constant.
As kumaraditya303 said, it seems like there are some local variables (exception and future instances) which makes reference cycles in asyncio library.
I uploaded a PR which breaks those cycles explicitly.
After the fix numbers from get_traced_memory does not grow linearly with the loop count anymore.
MacBookPro cpython % ./python.exe ~/dev/leak.py --loop_count 10
Working...
Done.
cur = 1311527, peak = 2365922 from tracemalloc.get_traced_memory()
------------------------------
MacBookPro cpython % ./python.exe ~/dev/leak.py --loop_count 100
Working...
Done.
cur = 1317149, peak = 2371520 from tracemalloc.get_traced_memory()
------------------------------
MacBookPro cpython % ./python.exe ~/dev/leak.py --loop_count 1000
Working...
Done.
cur = 1317050, peak = 2371421 from tracemalloc.get_traced_memory()
Activity
seer commentedon Jul 21, 2021
I write some short example.
100 cycles
"Memory usage 41980kb"
1000 cycles
"Memory usage 55412kb"
10000 cycles
"Memory usage 82880kb"
And so on...
Does anyone know workaround?
whoKilledLora commentedon Jul 22, 2021
Confirmed. I have the same problem. I suspect this is related to https://bugs.python.org/issue41699.
seer commentedon Jul 26, 2021
Checked on 3.9.6 - still leaking.
Strange stuff, but if I write
instead of
leak is disappearing.
aeros commentedon Jul 26, 2021
Thank you Arteem, that should help indicate where the memory leak is present.
kumaraditya303 commentedon May 28, 2022
This seems more like a gc issue as adding
gc.collect()calls after each iteration fixes the leak.cc @pablogsal
pablogsal commentedon May 28, 2022
That doesn't mean it is a GC issue. That means the GC is doing its work and the problem is that there are reference cycles to clean that until the GC runs they won't go away on their own.
It may be something to help here, but the GC is working as expected from this description.
kumaraditya303 commentedon Jul 11, 2022
This might be related to #81001
kumaraditya303 commentedon Jul 11, 2022
After some investigation, the issue is that the raised exception's traceback forms ref cycles are eventually cleared by gc but causes increased memory usage. The following example does not form ref cycles and hence memory usage is constant.
frostbyte134 commentedon Aug 6, 2022
As kumaraditya303 said, it seems like there are some local variables (exception and future instances) which makes reference cycles in asyncio library.
I uploaded a PR which breaks those cycles explicitly.
After the fix numbers from get_traced_memory does not grow linearly with the loop count anymore.
Checked in Windows 10/Mac Monterey/Centos 7.9
gh-88863: Clear ref cycles to resolve leak when asyncio.open_connectiâĶ
[3.11] pythongh-88863: Clear ref cycles to resolve leak when asyncio.âĶ
[3.10] pythongh-88863: Clear ref cycles to resolve leak when asyncio.âĶ
[3.11] gh-88863: Clear ref cycles to resolve leak when asyncio.open_câĶ
[3.10] gh-88863: Clear ref cycles to resolve leak when asyncio.open_câĶ