I also found out that if the function returns successfully, the runtime won't immediately deallocate the object once it's reference count reaches zero, so e.g.
will cause an extra fd to be used, until the cyclic garbage collector ran. I think this is a problem I introduced years ago when I made them subclassable because that somehow required adding GC support or something - I don't remember.
In any case, this means, that these need to become context managers or at least gain a close() method so that they can be closed when no longer needed.
arfile_new has the same issue FWIW, if there's an error somewhere and the file was opened, it leaks it, as does tagfile_new; and both of them also have memory leaks as they never free those objects in these error cases.
### Issue 3: aptd file descriptor leak (GHSL-2020-170)
I also found out that if the function returns successfully, the runtime won't immediately deallocate the object once it's reference count reaches zero, so e.g.
def f(): inst.DebFile( "../apt_ 1.9.5_amd64. deb")
apt_
f()
will cause an extra fd to be used, until the cyclic garbage collector ran. I think this is a problem I introduced years ago when I made them subclassable because that somehow required adding GC support or something - I don't remember.
In any case, this means, that these need to become context managers or at least gain a close() method so that they can be closed when no longer needed.
arfile_new has the same issue FWIW, if there's an error somewhere and the file was opened, it leaks it, as does tagfile_new; and both of them also have memory leaks as they never free those objects in these error cases.