Repository: gwastro/pycbc

Issue:
memory leak in mkl fft useage. 
https://github.com/gwastro/pycbc/blob/master/pycbc/fft/mkl.py#L112

It should have been fixed by the above, but this seems not to be the case for mkl. Not sure what is causing the leak at this point, but it does not occur with FFTW.

This was observed in pycbc live testing.


Discussion:
@ahnitz Just to be sure, in the tests, you are calling the function API as at the line above, and not the class API? Do you have a test case you can point me to that reproduces the problem?
I'm assuming it's from the few calls that are using the API interface, merely because with the class interface it's only created once anyway.
Can you point me to a test? It's hard to investigate without one. Point me in slack if it's more appropriate to do there.

I don't have a simple test case yet, but didn't want to forget this issue, since we found it again with tito. In my original tests, I fear I may have only done as long a test on fftw. 
btw, *most* calls are using the class interface, but a few data handling things are *not* simply because they are fast and it wasn't worth the codespace.
OK. Well, I'll wait for you to come up with a test case, and then try to run under some debugging tools. Since, like you, it seems to me that the obvious sources of memory leaks have been fixed, I'm not sure how to know what's causing the problem without doing that.
Reproducing case.

```
import pycbc.types
from pycbc.scheme import MKLScheme
from pycbc.fft import fft

a = pycbc.types.zeros(2**10, dtype=pycbc.types.complex64)
b = a * 1

ctx = MKLScheme()

with ctx:
    while 1:
        fft(a, b)
```
@josh-willis Did you ever have a chance to reproduce this? 
> @josh-willis Did you ever have a chance to reproduce this?

@ahnitz I'll take a look this week or early next, but I have not yet tried to reproduce it.
> > @josh-willis Did you ever have a chance to reproduce this?
> 
> @ahnitz I'll take a look this week or early next, but I have not yet tried to reproduce it.

So I can reproduce it.  I'll start trying to debug it.
Still have not found the cause of this.  I have tried the following:
 1. Running under various Python memory debugging tools, which have not shown anything particularly suspicious.
 1. I have added code to explicitly delete some temporary arrays and the variable that holds the status from MKL function calls (shouldn't have been necessary, as these should have been garbage collected)
 1. Following [this guidance](https://software.intel.com/en-us/mkl-linux-developer-guide-avoiding-memory-leaks-in-intel-mkl), I have tried both setting `MKL_DISABLE_FAST_MM=1` , calling `mkl_free_buffers()`, and calling `mkl_thread_free_buffers()`. None of these has impacted the leak. 
@josh-willis If we get the chance, maybe we should test two things. (1) old version of pycbc (2) old version of mkl. My recollection is that this *used* to work so maybe we'll figure out if this started happening with some code change?

Resolving patch:
diff --git a/pycbc/fft/mkl.py b/pycbc/fft/mkl.py
--- a/pycbc/fft/mkl.py
+++ b/pycbc/fft/mkl.py
@@ -100,7 +100,7 @@ def fft(invec, outvec, prec, itype, otype):
     f = lib.DftiComputeForward
     f.argtypes = [ctypes.c_void_p, ctypes.c_void_p, ctypes.c_void_p]
     status = f(descr, invec.ptr, outvec.ptr)
-    lib.DftiFreeDescriptor(descr)
+    lib.DftiFreeDescriptor(ctypes.byref(descr))
     check_status(status)
 
 def ifft(invec, outvec, prec, itype, otype):
@@ -109,7 +109,7 @@ def ifft(invec, outvec, prec, itype, otype):
     f = lib.DftiComputeBackward
     f.argtypes = [ctypes.c_void_p, ctypes.c_void_p, ctypes.c_void_p]
     status = f(descr, invec.ptr, outvec.ptr)
-    lib.DftiFreeDescriptor(descr)
+    lib.DftiFreeDescriptor(ctypes.byref(descr))
     check_status(status)
 
 # Class based API


Test patch: