test_simple.py hangs about gpyfft HOT 7 CLOSED

I tried the same script on a different device. It works intermittently. Sometimes it works, sometimes I get this in stdout/err:

OPENCL_V< CLFFT_INVALID_PLAN > (3083): fftRepo.getPlan failed

and sometimes I get the following exception:

Exception gpyfft.gpyfftlib.GpyFFT_Error: GpyFFT_Error() in 'gpyfft.gpyfftlib.Plan.get_dim' ignored
---------------------------------------------------------------------------
GpyFFT_Error                              Traceback (most recent call last)
<ipython-input-2-38dd57c8a3ed> in <module>()
     30 
     31 
---> 32 print 'plan.strides_in', plan.strides_in
     33 print 'plan.strides_out', plan.strides_out
     34 print 'plan.distances', plan.distances

/Users/alex/.python-eggs/Gpyfft-0.2-py2.7-macosx-10.9-x86_64.egg-tmp/gpyfft/gpyfftlib.so in gpyfft.gpyfftlib.Plan.strides_in.__get__ (gpyfft/gpyfftlib.c:3447)()

/Users/alex/.python-eggs/Gpyfft-0.2-py2.7-macosx-10.9-x86_64.egg-tmp/gpyfft/gpyfftlib.so in gpyfft.gpyfftlib.errcheck (gpyfft/gpyfftlib.c:1534)()

GpyFFT_Error: 'Functionality is not implemented yet.'

and sometimes in stderr/out:

Python(26389,0x7fff766b7310) malloc: *** error for object 0x7fd95157fa48: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug

In some of these cases python dies (I assume segfault).

from gpyfft.

It appears that running these line repeatedly causes Python to crash:

G = gpyfft.GpyFFT(debug=False)
plan = G.create_plan(context, cl_data.shape)

from gpyfft.

cannot reproduce this on OS X 10.9.3, Python 2.7.6, python 0.21dev, on Nvidia GT 330M.

from gpyfft.

Python does not die even running the two lines repeatedly together?

I noticed that the end of the script explicitly calls del on G and plan. Why is that?

from gpyfft.

Could once reproduce a segfault on OS X, happens in FFTPlan::ReleaseBuffers(), when plan is released.

Perhaps during garbage collection DestroyPlan is called after Teardown. This should not happen, each Plan keeps a reference to the GpyFFT object, to keep it alive. Quick testing indicates this is not the case. Repeatedly calling only plan = G.create_plan(context, cl_data.shape) seems to be ok.

Perhaps clFFT does not like to be initialized and deallocated repeatedly. There must have been a good reason why I added the comment #TODO: need to initialize (and destroy) at module level to GpyFFT.
So for the moment, create a GpyFFT instance only once.

The explicit del for plan and G is to trigger deallocation (clfftDestroyPlan(), clfftTeardown() ) for testing, not necessary.

from gpyfft.

I will change how the library get initialized, needs some work. Anyhow, please use the high level interface as defined in fft.py, the lower level interface as tested in test_simple.py is likely to change.

from gpyfft.

Reworked resource deallocation, so time to close this issue...

from gpyfft.