python list comprehension shows as memory leak

[paniabhisek]

I was testing how memray will show leaks incase the global variable is changed by allocating memory in some way. This is because I was getting some leak information from libraries. After debugging, I realized it was modifying a global variable. I did not went into actually modifying the global variable yet.

Sample snippet

from time import sleep
from random import randint
import memray

def fun():
    nums = [randint(10 ** 8, 10 ** 9) for i in range(1)]
    nums = []
    for _ in range(1):
        nums.append(1)

memray_file_path = memray.FileDestination('output.bin', overwrite=True)
with memray.Tracker(destination=memray_file_path, trace_python_allocators=True):
    sleep(1)
    a = fun()
    sleep(1)

The result of memray flamegraph --leaks output.bin

Why is it showing memory leak for list comprehensions ? It seems to leave 440B. Even if I change range to range(100000), it leaves 440B behind. If I call the list comprehension multiple times. It leaves 440B each time.

Also If I remove the list comprehension out. It only shows a = fun(). Isn't it supposed to show nothing? Because after the function call, the memory is deallocated for that function. If I call fun twice, it shows the first instance as a = fun() and not the latter.

[godlygeek]

What Python version are you using? Can you show what the flame graph shows if you collect native stack traces, using:

with memray.Tracker(destination=memray_file_path, trace_python_allocators=True, native_traces=True):

I suspect you're seeing the line number cache or instrumentation data cache that the interpreter creates the first time a function is profiled. These caches don't scale with the number of calls to the function or to the size of the list it returns, but rather with the number of byte code instructions in the function, which is why the size is always the same. These are truly leaked by the interpreter, in the sense that they are not freed until after your program has finished running.

Also If I remove the list comprehension out. It only shows a = fun(). ... If I call fun twice, it shows the first instance as a = fun() and not the latter.

This supports my theory - the first time the function is called, the interpreter is creating some structure (like a cache of bytecode offsets to line numbers for the function). That cache is reused across every run of the function, and not destroyed until after the program has finished.

[paniabhisek]

$ python --version
Python 3.9.13

With native_traces:

[paniabhisek]

What is the use of this cache in terms of list comprehension? If I call the same list comprehension two times. It shows same amount of memory leak. Do you think, it is a bug in python. In the case of function call, it does not do. So, maybe it is understandable.

[godlygeek]

Looks like you're seeing the allocation of a Frame object. It's not freed when the function returns because the interpreter has a "free list" of existing frame objects which are pooled and re-used when new frames are needed. This is an optimization inside the interpreter to make calling functions faster, by reducing the amount of work needed for each function call.