Re: [lmi] NDEBUG

[Vadim Zeitlin]

On Sun, 26 Oct 2014 16:29:58 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2014-10-24 14:16Z, Vadim Zeitlin wrote:
GC> 
GC> >  This depends on what exactly is the goal here and I'm not quite sure 
about
GC> > this. Do we want to have all messages logged by wxWidgets shown in the
GC> > window? Or maybe only those that are not otherwise shown to the user? And
GC> > maybe in this case we don't even want to show the window at all unless
GC> > there are any messages to show in it?
GC> 
GC> With this discussion and some experimentation, I arrive at the true goal.
GC> 
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).

 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),
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. Hence it doesn't seem like we're going to be [easily]
able to detect it automatically.


GC> [BTW, the wx "Logging Overview" above gives this dead link:
GC>   http://www.microsoft.com/technet/sysinternals/Miscellaneous/DebugView.mspx
GC> It seems to have been replaced by:
GC>   http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx
GC> at least for the moment.]

 Thank you, I've updated the link.

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.

 Regards,
VZ