Re^2: Memory Leak using Win32::OLE::Variant for a SafeArray passed by Reference

The function GetMassListFromScanNum is part of a DLL (MSFileReader) to read scientific data from a file that uses a proprietary format.

The memory leak occurs even if I never declare the array @TempScan. Calling the GetMassListFromScanNum is sufficient to allocate the memory. The documentation for pvarMassList is given here:

The mass list contents are returned in a SafeArray attached to the pvarMassList VARIANT variable. When passed in, the pvarMassList variable must exist and be initialized to VARIANT type VT_EMPTY. If the function returns successfully, pvarMassList is set to type VT_ARRAY | VT_R8. The format of the mass list returned is an array of double precision values in mass intensity pairs in ascending mass order (for example, mass 1, intensity 1, mass 2, intensity 2, mass 3, intensity 3, and so on).

Unfortunately, ->DESTROY is not a valid method for the MSFileReader software.

undef $pvarMassList does not clear the memory leak. It will prevent the script from accessing the SafeArray with the data. The memory leak is on the order of 400 kb where the compressed data file is about 300 kb. Only the SafeArray referred to by $pvarMassList is large enough to explain the memory leak. If appears that simply calling the GetMassListScanNum brings the data into memory.

Even the $thermo_raw_file->Close(); command does not deallocate the memory associated with perl in the Task manager.

I think I need a way to deallocate the SafeArray using perl (prefered) or a way to deallocate all memory associated with the MSFileReader.

I am not sure how a foreach loop helps since the memroy leak when I call the GetMassListFromScanNum function outside the loop, the loop just makes the memory leak blow up.

Thanks for the help, any further thoughts are appreciated.

Comment on Re^2: Memory Leak using Win32::OLE::Variant for a SafeArray passed by Reference

Replies are listed 'Best First'.
Re^3: Memory Leak using Win32::OLE::Variant for a SafeArray passed by Reference by Anonymous Monk on Jun 22, 2014 at 08:20 UTC
Unfortunately, ->DESTROY is not a valid method for the MSFileReader software. Its not supposed to be. DESTROY is perl name for the destructor, destructors usually do things like break circular references (parent/child/parent) ... things that leak memory; Re: cpu, memory, and permissions issues with Win32::OLE Win32::OLE::Variant provides a DESTROY method http://cpansearch.perl.org/src/JDB/Win32-OLE-0.1712/OLE.xs Read more... (479 Bytes) I think I need a way to deallocate the SafeArray using perl (prefered) or a way to deallocate all memory associated with the MSFileReader. undef does that -- if undef doesn't do it, something else is holding a reference ... say the dll itself You have to find what MSFileReeader needs in the docs Another thing to try http://search.cpan.org/grep?cpanid=JDB&release=Win32-OLE-0.1712&string=destroy&i=1&n=1&C=0 reveals SafeArrayDestroy is used internally. SafeArrayDestroy finds SafeArrayDestroy function (Automation) which says Destroys an existing array descriptor and all of the data in the array. If objects are stored in the array, Release is called on each object in the array So next you can try SafeArrayDestroy and Release Also, from DESTROy above, there is ClearVariantObject, another one to try See also http://search.cpan.org/dist/Win32-OLE/lib/Win32/OLE/NEWS.pod#Enumerate_all_Win32::OLE_objects If none of these works, you'll have to mine the MSFileReeader docs ... I am not sure how a foreach loop helps ... Its a tip about perl syntax, because of your writing `my $woo; for( $woo=0; ... )`	[reply] [d/l] [select]
Re^4: Memory Leak using Win32::OLE::Variant for a SafeArray passed by Reference by Anonymous Monk on Jun 24, 2014 at 05:57 UTC
Close method undef of Com object causes small deallocation of memory but bulk of problem remains. `$thermo_raw_file->Close;` `undef $thermo_raw_file;` I have looked for code examples on how to code ClearVariantObject, SafeArrayDestroy, or Win32::OLE::Destroy in perl without much sucess so I am not sure if my failures are based on approach or the wrong syntax. The $pvarMassList SafeArray changes type from VT_EMPTY to VT_R8 upon successful GetMassListFromScanNum. Could this change in type controlled by the DLL cause perl to loose control of the SafeArray? Thank you for the help. I appreciate all the suggestions.	[reply] [d/l] [select]
Re^5: Memory Leak using Win32::OLE::Variant for a SafeArray passed by Reference by Anonymous Monk on Jun 24, 2014 at 07:39 UTC
Close method undef of Com object causes small deallocation of memory but bulk of problem remains. Did you try Release-ing all the arguments to GetMassListFromScanNum? Could this change in type controlled by the DLL cause perl to loose control of the SafeArray? I don't think so ; what i've read so far, reference counting is how COM deals with keeping objects alive -- same as perl does ; its unlikely Win32::OLE is creating any circular references (:anymore:), so the problem is likely with MSFileReader... You might try VMMap or Virtual Memory Map Viewer to see if you can narrow it down say add a pause (scalar readline STDIN; ) before and after GetMassListFromScanNumk and see what you can see :/	[reply]