On Wed, Apr 30, 2008 at 09:53:42AM -0700, Brian Dessent wrote:
> Bob Rossi wrote:
> > To follow up on my own thread, I know that each DLL in windows can have
> > it's own heap. I also know that you can't new an object in one, and
> > delete it in another, unless you use the /MD switch with cl.
> > So, how does this effect mingw's gcc? Is there a similar gcc flag or do
> > the rules not apply?
> cl /MD literally means "use MSVCRT.DLL" instead of statically linking
> the runtime into the executable.
OK, I know you are correct about this, however, I do know from
experience, that the actual translation unit is different when you
provide the /MD flag. It's not just a linker flag. I'm assumming that cl
does something terrible to ensure that when /MD is given, some part of
the translation unit is included or not included.
Does this happen for free with gcc? or is it perhaps a non issue?
(ie. if the /MD effects the windows.h include, does gcc need to mimmic
> The problem you are referring to is
> specific to MSVC because there you can choose between a vast combination
> of runtimes (static or dynamic; single or multithreaded; debug or
> non-debug) and so you run into problems if you try to use a library that
> was built with e.g. the static singlethreaded runtime linked to a main
> program that was built with the dynamic MT runtime. But MinGW supports
> only one option: dynamic MSVCRT.DLL, so this is pretty much
> irrelevant. It's not like we can distribute Microsoft's static
> Regarding heaps, gcc has no knowledge of how the underlying platform
> implements memory management; all it needs to know is that there is a
> malloc() in the libc on which it can base 'operator new', that's it.
> And since malloc() is implemented by MSVCRT.DLL, this means that all
> calls go through one instance.
OK, if what you say is true, how do I get this,
warning: Invalid Address specified to RtlFreeHeap( 003D0000, 06071070 )
Program received signal SIGTRAP, Trace/breakpoint trap.
Everything I read online says it happens when data is free'd from one
heap and malloc'd in another.
When I run my program from outside GDB, I don't get these warnings, that
strikes me as rather odd. A backtrace in gdb at this point is
essentially meaningless. GDB actually says,
frame inner to this frame (corrupt stack?)
When I do a search for this on the web, I find that just about everyone
in the mingw community has this issue and nobody can resolve it.
I'm going to continue researching. Any help would be appreciated.