On Apr 10, 2:24 am, "James Tursa" <aclassyguywithakno...@hotmail.com> wrote: > Praetorian <ashish.sadanan...@gmail.com> wrote in message <a018942f-5682-44ca-82bf-ea96eb58c...@a23g2000vbl.googlegroups.com>... > > > Thanks for coding up that example! So I went ahead and did things a > > little differently; instead of using CALLLIB from the command line I > > loaded the DLL using the Windows API LoadLibrary function from within > > mexmem. And what do you know, MATLAB garbage collects the memory in > > that case. The only other difference was that I created a Visual > > Studio project to compile my DLL instead of modifying mexopts.bat but > > I can't think of any project setting that would cause this change in > > behavior. Here's my modified mexmem.c > > > (snip) > > > I added the INMEM check because I was always under the impression that > > MATLAB didn't do any mex garbage collection until the mex file was > > cleared from memory. But these tests prove otherwise! Also, I tried > > commenting out the FreeLibrary call to see what would happen if the > > DLL remained in memory but that gave the same results. > > > Any thoughts on why CALLLIB doesn't work the same way? > > > Regards, > > Ashish. > > Ashish, > > I haven't had a chance to try out your example yet ... maybe this weekend. But I did modify some other dll code that I have that is a basic memory sharing example. Called it using Windows API functions from within a mex routine. The dll has functions for allocating memory, copying data to the memory, displaying the memory, and deallocating the memory. The dll works great using malloc and free, but when I switch to mxMalloc and mxFree the dll craps out with a seg fault. This doesn't always happen right away, but it always happens eventually. So I suspect that there is a fundamental restriction here that you can't use MATLAB API functions inside a shared library dll because it messes up the MATLAB memory manager in some way ... they are probably walking on each other. You apparently experienced seg faults as well when deallocating with one of your examples. So the garbage collection issue > is probably a moot point for shared library dll's since using any of the MATLAB API functions that allocate or deallocate memory will screw up the MATLAB memory manager and cause a seg fault. > > James Tursa
I'm not so sure you can't use the mxMalloc and mxFree from within a shared library. I modified the code so that I was calling the DLL's allocate function followed immediately by the deallocate function; I then called the mex file from the command line 1000 times and didn't get any seg faults. The reason I got one yesterday was because I allocated memory using the DLL in one call to the mex file and then tried to deallocate it during the next call. But my tests from yesterday show that the Matlab memory manager does garbage collection on the memory allocated by the DLL when the calling mex file exits. So the memory allocated in the first call had already been deallocated (by the memory manager) and I tried to explicitly deallocate it in the next call resulting in the segv.