Re: [lmi] NDEBUG

[Greg Chicares]

On 2014-10-26 17:06Z, Vadim Zeitlin wrote:
> On Sun, 26 Oct 2014 16:29:58 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> While lmi is running, wx potentially generates diagnostic messages. Only
> GC> the most severe messages are displayed; others aren't by default, because
> GC> they would perplex end users. Yet all these diagnostics are potentially
> GC> helpful to me, as they may indicate latent defects, so I would like to
> GC> be able to see them all myself. And that's the entire goal.
> 
>  I agree that using wxLogStderr seems like a good match to your workflow in
> this case. For me it's not so great because while I do run LMI regularly
> from Cygwin shell prompt, I also often run it from MSVS debugger in which
> case there is no associated console, so I risk not noticing any debug log
> messages (right now I do see them because by default they end up exactly in
> the debug output, which is shown by the debugger).

I didn't think of that. I did think of you running it on GNU/Linux,
but concluded that there would be no problem in that case.

>  So from my point of view it would be ideal to use stderr only if it's
> available. Normally this would be done using
> 
>       wxTheApp->GetValidTraits().CanUseStderr()
> 
> under wxMSW (perhaps surprisingly, checking for this is quite non trivial),

(And I won't suggest making it worse by trying to detect MinTTY.)

> but I strongly suspect that this would return false when running inside
> MinTTY, which is used by Cygwin as terminal emulator nowadays, as it's not
> a real MSW console.

It does indeed return 'false'. And I wouldn't want to forsake MinTTY.

> Hence it doesn't seem like we're going to be [easily]
> able to detect it automatically.

Then let's look for a different way to handle the MSVC case.

How about this, using the LMI_MSC macro from 'config.hpp'?

+ #if defined LMI_MSC
  wxLog::SetActiveTarget(new wxLogStderr);
+ #endif // defined LMI_MSC

But I guess the condition you want is not whether it was compiled
with ms tools, but whether it's running under the ms debugger--so
are there any good ideas in this link?
  
http://stackoverflow.com/questions/101806/check-if-application-was-started-from-within-visual-studio
I haven't checked whether MinGW's headers offer IsDebuggerPresent(),
but I guess we can just write its prototype inline; though I don't
know whether that would create a problem for you with gdb. How about
testing whether the...
| module name of the current process contains the string ".vshost"
?

> GC> [0] "gdb...woefully inconvenient"
> GC> 
> GC>   /opt/lmi/bin[0]$gdb ./lmi_wx_shared
> GC>   (gdb) set arg --ash_nazg --data_path=/opt/lmi/data
> GC> 
> GC>   warning: HEAP[lmi_wx_shared.exe]:
> GC>   warning: Invalid Address specified to RtlFreeHeap( 003F0000, 66A7C42C )
> GC>   Program received signal SIGTRAP, Trace/breakpoint trap.
> GC>   0x7c90120f in ntdll!DbgBreakPoint ()
> GC>      from /cygdrive/c/WINDOWS/system32/ntdll.dll
> GC> 
> GC> [that'll repeat many times, so...]
> 
>  Just for the record, this doesn't seem normal at all and I don't see it
> (under Windows 7). If Windows built-in heap debugging code says that the
> address is invalid, it almost certainly is, and it seems potentially very
> dangerous to ignore something that results in freeing invalid addresses.

I looked at this:
  
https://social.msdn.microsoft.com/Forums/vstudio/en-US/2c816330-899a-44cd-b363-ffdc90796693/invalid-address-specified-to-rtlfreeheap-error-trying-to-deallocate-memory?forum=vclanguage
and a few other "Invalid Address specified to RtlFreeHeap" search results,
and concluded--perhaps prematurely--that this is just some goofy msw
stuff that we can't do anything about.

I glanced very quickly at this thread:
  https://groups.google.com/forum/#!topic/wx-users/xFCaZDmXc88
where it seems that switching to TDM makes the problem go away. This is
just one more reason to replace MinGW...in 2015.