Pillow: Image.close() does not deallocate memory

[eob]

What did you do?

Ran the following code (this is a toy reproduction of a large-scale deployment)

import PIL
from PIL import Image

@profile
def do_image_things():
  im = Image.open('foo.png')
  im.close()
  del im

if __name__ == '__main__':
  do_image_things()

Using the invocation: python -m memory_profiler experiment.py

What did you expect to happen?

The memory allocated for im to be deallocated.

What actually happened?

Python's memory_profiler shows that the memory usage does not go down:

Line #    Mem usage    Increment   Line Contents
================================================
     8   33.645 MiB   33.645 MiB   @profile
     9                             def do_image_things():
    12   37.383 MiB    3.738 MiB     im = Image.open(u'foo.png')
    13   37.387 MiB    0.004 MiB     im.close()
    14   37.387 MiB    0.000 MiB     del im

Has anyone been able to resolve this problem?

No

What are your OS, Python and Pillow versions?

• OS: Mac OSX Mojave
• Python: 2.7.14
• Pillow: 5.0.0

[mattBoros]

Does this happen when you open a second image? Because Image.open calls a function called preinit that imports from other files, so this should increase memory for the first Image.open call, but not for any Image.open calls after the first. I tested with two calls and the memory increase only happens on the first call.

```Line # Mem usage Increment Line Contents

 4     23.5 MiB     23.5 MiB   @profile
 5                             def do_image_things():
 6     24.1 MiB      0.6 MiB       im = Image.open('foo.png')
 7     24.1 MiB      0.0 MiB       im.close()
 8     24.1 MiB      0.0 MiB       del im
 9                             
10     24.1 MiB      0.0 MiB       im2 = Image.open('bar.png')
11     24.1 MiB      0.0 MiB       im2.close()
12     24.1 MiB      0.0 MiB       del im2

[wiredfool]

There’s also an optimization in the memory allocator that hangs on to memory so that repeated load/close cycles don’t continually free and reallocate memory. (See
https://github.com/python-pillow/Pillow/blob/master/src/libImaging/Storage.c#L316)

In this case though, it’s probably loading python modules, because you didn’t actually get to loading any image data.

[zishanahmed08]

Hello @aclark4life , Is there a timeline as to when this will be fixed. Also which is the last version unaffected from this bug

[aclark4life]

@zishanahmed08 Hmmm, good q, I don't actually recall moving this to In Progress … may have been when we first setup GitHub Projects … @hugovk or @radarhere may know if it's actually in progress, else it should go back to the Backlog, with no timeline that we know about.

[zishanahmed08]

@aclark4life Thanks for your reply. Which is the last version of Pillow unaffected from this bug?

[aclark4life]

@zishanahmed08 I'd see if you can get @eob to determine that … a lot of times bugs go all the way back to PIL 1.1.7

[wiredfool]

There's not enough in the original report to track this down, and there are two reasonable explanations. It should probably just be closed.

[aclark4life]

"not enough in the original report to track this down" == Invalid, closing. @eob Please reopen with more detail if still an issue for you.