Log in

View Full Version : fftw3.dll usage. Memor leak?


vcmohan
14th October 2006, 09:46
I use fftw3.dll for the FFTQuiver plugin. I use virtualdub for monitoring the output of the avisynth script. I have been observing that whenever I have this plugin in the script and repeatedly open and close at certain point virtualdub at the time of closing file gives an error and the information I get is
At this pont even if I close virtualdub and reopen it the error persists.
modname fftw3.dll.
code0xc0000005 flags 0 record 0 address 0x0....67c17c8

I have no idea as to what it means. In my destructor I have code like

fftwf_free (buf);
fftwf_free (freqbuf);
fftwf_cleanup();
fftwf_destroy_plan(pf);
fftwf_destroy_plan(pinv);
delete []powerspectrum;


While all the buffers etc created using fftw are destroyed or freed, buffer created separately is deleted. So I do not expect any memory leak. In any case those created directly by me using new call should automatically get deleted when I close virtualdub. So I think something is amiss with my usage of fftw3 dll.
can FIZICK or any one familiar with this suggest remedy?

Fizick
14th October 2006, 16:52
I will try.
Questions:
1)what version of FFTW do you use?
2) What CPU?
3) what avisynth?
4) Have you similar problems with DeFreq?

I try read you source f1Quiver.cpp dated 10.march.2006
Comments:
1)You put memory allocation calls to GetFrame (with check if it been already done).
IMHO, you must move them to Constructor.
2)In Destructor you does not check if these memories were allocated, please try to add this check here.
3) I see dangerous MakeWritable call. Now I very afraid to use it (ask IanB why :) )
In any case, try move all GetPitch calls to below MakeWritable and GetWritePtr. You may get pitch from one instance of frame, and get other copy of them with different pitch after MakeWritable.
(We still wait when IanB write some article about this to AviSynth SDK :) )

But may be all this is not important, and you simple have some bad memory module? :(
code 0xc0000005

vcmohan
15th October 2006, 04:54
I use fftw3win32mingw dll actually named as fftw3.dll of Jan 2004. I have no version number on it. I will try to use one from fftw site, which I find is in 3 parts.

My system is AMD xp Athlon 2000+ , msi k7v motherboard, 512mb RAM, 40GB HDD, Windows XP pro

Avisynth 2.5.6

Regarding the deletion or freeing of buffers. Yes I also noted it but in my testing it does not matter as I am always closing the virtualdub after just examining one frame, and so other parts of code do not come into play.

I need to create buffers in GetFrame method as I have an option of inputting frame numbers to process. This option I have originally inherited from my TransAll plugins where it is required and also in EffectsMany. So I am just continuing. I think creating buffers in GetFrame should not be a problem.

I have all my calls to GetPitch after getting write pointers now, after my recent posting about separatefields giving different pitch values from frame to frame.

Yes I will change MakeWritable some time soon, but so far I experienced no problem with it.

Possibly as you mentioned there may be some problem with my memory bank. I will check it over.

Sorry I did not check with your defreq, as my copy was lost and I need to down load it again.

Many thanks for your time

Fizick
15th October 2006, 06:30
I have the similar system config.
You can allocate buffers in Constructor and fill them in GetFrame.

vcmohan
16th October 2006, 03:39
I deallocate buffers / or do not create buffers if one is out of frame range specified. So I need to create them in GetFrame method when one comes into the frame range. I do not have any problem with this. This hopefully will reduce memory blocking.

While trying to compile with the new dlls on FFTW site I am getting errors during linkage as unresolved .... . There is a line in the header or somewhere else that mentions one call is required to be made if trying to compile with VC++. Since I do not go to command line I have no idea how to go about this.
regards

Fizick
16th October 2006, 15:42
Old fftw3.DLL works fine for me.
And now I use dynamic loading of the DDL instead of static linking (see my plugins and fftwlite.h file). So way we can use any new DLL without recompiling the plugins.
I did not try use static linkinkg with new fftw.

You can send your new source code to me.
I do not understand your buffers things.
And how about Defreq test?