This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Matlab mex files and cgywin


On Tue, 22 Dec 1998, Mark Levedahl wrote:

> 
> I think the primary problem is a conflict between cygwin's malloc and MATLAB's
> memory allocation: until b20, all my mex files were linked against libcygwin.a
> (hence using cygwin.dll), but I was careful to use mxMalloc, mxCalloc, and
> mxFree instead of malloc, calloc, and free. Using mingw (linking against mscrt),
> I don't need to do this. Obviously, the malloc in mscrt.dll avoids the conflict.
> 

I don't believe the trouble is in using malloc/free/etc in cygwin.dll, but
rather when you malloc something in your Cygwin DLL and then the allocated
memory is freed elsewhere (perhaps in Matlab), it causes trouble. You end 
up with a corrupted heap. This is a fundamental design flaw in MS DLLs and 
is quite well known. 

When I was porting our local extensions for Tcl/Tk way back before a 
proper cygwin port of tcl/tk were available, I had to take lots of care 
to avoid this issue and carefully use Tcl's allocator/deallocator to make 
sure all the memory was allocated and deallocated by the *same* DLL or 
app and didn't cross boundaries.

I don't know if Matthew is running into this particular problem, but this
would definitely be my first guess. Matthew, can you do a quick search
on malloc/free etc to see if this is happening?

Of course, it could be a variety of other bugs as well ;-) Netscape DLLs
are impossible to make currently with Cygwin DLL and I haven't been able
to track that one down (same symptom -- kills Netscape stone cold!).

Unfortunately, I don't have Matlab on a PC, so can't test it. The only
way to find out where things are going wrong would be run Matlab under
gdb and let it run and see if it dies in the Cygwin DLL (you'd need a
debuggable version of Cygwin DLL to do this of course).

> Thus, a partial solution is to recompile those portions of libc and libm that
> are of interest and are missing from mscrt to use mxMalloc, etc. However, a
> complete solution no doubt would require some fundamental changes to cygwin1.dll
> and may be more trouble than it is worth.

Definitely! Might not even be possible in the general case.

Regards,
Mumit


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]