Re: [Mingw-users] mingw && gdb

[Brian D. <br...@de...>]

Bob Rossi wrote:

> 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
> this)?

MSVCRT is the multithread version of the runtime, so _MT (or whatever
the define is called) gets defined, just as _ST (or whatever the define
or lack of a define is called) gets defined when you use the
singlethreaded version.  Whatever the headers do with that define is up
to them (e.g. stdio inlines), but the same thing happens when you use
-mthreads with gcc.

> OK, if what you say is true, how do I get this,
>   .....warning: HEAP[TestSuite.exe]:
>   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.

You can't get a backtrace because gdb has no debug information and
Windows system DLLs have FPO enabled so there's no way to unwind the
stack.

This is a debugging trap.  You don't see it outside of a debugger as
there is no debugger to act on it.  It doesn't sound that strange to me
that some system DLLs generate traps under some circumstances if the
process is being debugged.  If anything, the fact that you see the trap
when there is a debugger is just alerting you to something that's always
present but simply ignored under normal circumstances.  Just like
normally the output of "OutputDebugString()" goes nowhere, but if you
run dbgview or debug the program you'll see it.

The classic example are those "IsValid{Read,Write}Ptr()" functions in
kernel32.dll.  They generate access faults if the argument passed is in
fact not valid, and those faults are totally normal as the function has
installed a SEH handler to catch them.  But the debugger still gets the
first chance at handling the fault regardless of what handlers are
installed.  And therefore most Win32 debuggers have to have an option to
ignore access faults that occur within kernel32.dll for this very
reason.

Another random example that I've experienced is that I've seen
rpcrt4.dll (part of the operating system) generate SIGTRAP when calling
gethostbyname() if I have the 'DNS Client' service disabled.  Again,
there's nothing erronious going on here.  Name resolution works just
fine as I had a local bind9 server running.  But for whatever reason the
OS generated a debugging trap under those circumstances, and of course a
debugging trap with no debugger present cannot be detected so it's not
like this ever affected the program.

If anything this just indicates that gdb should be taught/configured to
ignore traps that it did not insert itself.

Brian