Closed tolomea closed 6 years ago
Thanks for reporting the issue and investigation you made. I also saw that there are some situations where files handlers can leak but didn't investigated further yet, because of lack of time.
Proposed approach can lead to errors like Operation on closed file
or something like that.
If you have time I will be really glad if you can try to come up with proper fix and prepare a pull request.
P.S. the issue is more serious on Python 3 because this will lead to memory leak because of ResourceWarning
which is fired every time when Python garbage collect unclosed files (which will happen after some time). In Python 2 there is no such warning and after few requests the files are garbage collected and there is no leak. More info here https://bugs.python.org/issue27535
Python 3.6.1 Django==1.11.3 django-imagekit==4.0.1
When using FileSystemStorage Imagekit leaks open file handles. In specs/init.py:ImageSpec.generate the open_image call inside the try may result in an open call on the underlying file system and that open is never closed. My experimenting shows it can leak multiple file handles from here and the leak persists across requests, I don't know if they are ever cleaned up.
Here's a chunk of stack showing the actual open if that helps any:
As you can see this was found on a Windows system, I've no reason to think it's specific to the Windows system, but it is more noticeable there as Windows is fussy about not letting you delete(etc) open files.
This patch fixes it for my current usecase but I don't know if it breaks anything else:
In terms of reproduction I've been using this monkey patch to keep track of open files in the system and where they came from
I have a model with an image field and a couple of specs:
One of which is displayed in the admin:
Uploading successive files to it via the admin causes print_open_files to show files from previous requests still being open.
And applying the patch above fixes it.