[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] NDEBUG
Re: [lmi] NDEBUG
Sun, 26 Oct 2014 18:50:53 +0000
Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
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
> 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
+ #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?
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>  "gdb...woefully inconvenient"
> GC> /opt/lmi/bin$gdb ./lmi_wx_shared
> GC> (gdb) set arg --ash_nazg --data_path=/opt/lmi/data
> 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> [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:
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:
where it seems that switching to TDM makes the problem go away. This is
just one more reason to replace MinGW...in 2015.
Re: [lmi] Manual test of automated GUI test, Vadim Zeitlin, 2014/10/18
- Re: [lmi] PDF opening errors (was: Manual test of automated GUI test), (continued)
- Re: [lmi] PDF opening errors (was: Manual test of automated GUI test), Vadim Zeitlin, 2014/10/19
- Re: [lmi] PDF opening errors, Greg Chicares, 2014/10/19
- Re: [lmi] PDF opening errors, Vadim Zeitlin, 2014/10/19
- [lmi] NDEBUG [Was: PDF opening errors], Greg Chicares, 2014/10/23
- Re: [lmi] NDEBUG, Vadim Zeitlin, 2014/10/23
- Re: [lmi] NDEBUG [Was: PDF opening errors], Greg Chicares, 2014/10/23
- Re: [lmi] NDEBUG, Vadim Zeitlin, 2014/10/24
- Re: [lmi] NDEBUG, Greg Chicares, 2014/10/26
- [lmi] Using wxLogStderr [Was: NDEBUG], Greg Chicares, 2014/10/26
- Re: [lmi] NDEBUG, Vadim Zeitlin, 2014/10/26
- Re: [lmi] NDEBUG,
Greg Chicares <=
- Re: [lmi] NDEBUG, Vadim Zeitlin, 2014/10/27
- Re: [lmi] NDEBUG, Greg Chicares, 2014/10/29