[SciPy-Dev] memory leak in scipy.fftpack.ifft2?

[Matt Terry]

I'm assuming that you are expecting the address of CC to remain
constant.  As written, it should not.  fft2 returns a new array, as
does ifftshift and ifft2.  You can fill an existing array with the
answer by creating ffta and CC outside the loop and then filling them
with the CC[:,:] = blah() syntax.  The modified script is attached.

WIth these changes, the script still uses a lot of memory (high water
mark of 2.4 GB), but the memory usage does not grow without bound.  At
least for me, using the same platform (mac, epd 7.2).

-matt

On Sat, Mar 24, 2012 at 12:35 PM, Brian Toby <brian.toby at anl.gov> wrote:
> The attached a ~30 line short demo file that unexpectedly eats more memory
> on each iteration. I have tried it with python on windows and on the mac,
> and in both cases I typically run out of memory before the loop completes.
> As best as I can tell, the final scipy.fftpack.ifft2 call in the loop
> malloc's a 256Mb block of memory inside that is never referenced in python
> and is never freed.
>
> With 32-bit EPD 7.1-2 (numpy 1.6.1; scipy 0.9.0) on the Mac, I can see 256Mb
> blocks that seem to be created during each call to scipy.fftpack.ifft2. With
> EPD 7.2-2 (numpy 1.6.1; scipy 0.10.0), there are fewer, but larger,
> allocated blocks of memory and the test does complete, but the malloc's grow
> to a total use of 2.2Gb.
>
> Could someone confirm for me that this is a real scipy bug and not user
> error? Is there a ticket mechanism?
>
> Brian
>
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sft2.py
Type: application/octet-stream
Size: 1091 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20120324/6ef11093/attachment.obj>