Re: [lmi] NDEBUG

[Greg Chicares]

[All this, just so I could figure out I really want wxLogStderr...]

On 2014-10-24 14:16Z, Vadim Zeitlin wrote:
> On Fri, 24 Oct 2014 02:13:45 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2014-10-23 12:39Z, Greg Chicares wrote:
> GC> [...]
> GC> >> GC> The reason why I ask is that I'm wondering if there's some way I 
> could
> GC> >> GC> (optionally) enable messages like this in the production system 
> (say,
> GC> >> GC> only with a special command-line argument).
> GC> 
> GC> I could use some advice here. Clearly I can copy this code from 'wx_test':
> GC>   wxLogWindow(NULL, "Log Messages", true, false)
> GC> into Skeleton::OnInit(), and (subject to some command-line switch) see the
> GC> log messages. But I'm not sure about the best way to do this.

Let me put a concrete idea on the table in case others would like to
try it (and perhaps see why, after playing with it, I dislike it):

Index: skeleton.cpp
===================================================================
--- skeleton.cpp        (revision 5998)
+++ skeleton.cpp        (working copy)
@@ -631,6 +631,11 @@
             return false;
             }

+        if(contains(global_settings::instance().pyx(), "log"))
+            {
+            new wxLogWindow(frame_, "wx log messages", true, false);
+            }
+
         authenticate_system();

         wxInitAllImageHandlers();

With that experimental change, an extra flag creates a wxLogWindow:
  /opt/lmi/bin[0]$./lmi_wx_shared --pyx=log [...other option...]

[I chose an exotic command-line option partly for fear that, if I used
one of our accustomed "password" options, this technique would interfere
with automated GUI testing. I still can't guess whether this log window
leaks memory, or whether there are any other safety issues...and I don't
want to think about all of that, because...]

>  This depends on what exactly is the goal here and I'm not quite sure about
> this. Do we want to have all messages logged by wxWidgets shown in the
> window? Or maybe only those that are not otherwise shown to the user? And
> maybe in this case we don't even want to show the window at all unless
> there are any messages to show in it?

With this discussion and some experimentation, I arrive at the true goal.

While lmi is running, wx potentially generates diagnostic messages. Only
the most severe messages are displayed; others aren't by default, because
they would perplex end users. Yet all these diagnostics are potentially
helpful to me, as they may indicate latent defects, so I would like to
be able to see them all myself. And that's the entire goal.

Using a wxLogWindow, as above, is distracting. It would be ideal to write
these diagnostics to stdout or stderr, as I always run lmi from a zsh
command line, where I will surely notice them. I'd like to make this
optional, because some end users actually do run lmi in a command
interpreter that's beyond our control.

Of course, before noticing the direct answer to this in the wx
documentation, I tried it the hard way; so feel free to skip three
paragraphs ahead.

I could accomplish this with gdb, but that's woefully inconvenient [0].

The wx documentation
  http://docs.wxwidgets.org/trunk/overview_log.html
mentions "DebugView", which might work, but...
 - would it actually accomplish the goal above?
 - it displays "Win32 debug output"; does that mean 32-bit msw only?
 - it wouldn't work natively on GNU/Linux

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

I was actually about to ask you if a stderr-logging class could be
added to wx--we could call it wxLogStderr, for instance--which
brings us by a commodius vicus of recirculation back to
  http://docs.wxwidgets.org/trunk/classwx_log_stderr.html

>  Also, it's rare but possible that log messages are generated before
> OnInit() is called, so the possibility of losing them still remains
> present. Only overriding CreateLogTarget() as explained above guarantees
> that no messages are lost.

If it's inconvenient to capture wx diagnostics that arise before OnInit(),
or during or after OnExit(), then I could do without them.

---------

[0] "gdb...woefully inconvenient"

  /opt/lmi/bin[0]$gdb ./lmi_wx_shared
  (gdb) set arg --ash_nazg --data_path=/opt/lmi/data

  warning: HEAP[lmi_wx_shared.exe]:
  warning: Invalid Address specified to RtlFreeHeap( 003F0000, 66A7C42C )
  Program received signal SIGTRAP, Trace/breakpoint trap.
  0x7c90120f in ntdll!DbgBreakPoint ()
     from /cygdrive/c/WINDOWS/system32/ntdll.dll

[that'll repeat many times, so...]
  handle SIGTRAP nostop noprint pass
  (gdb) handle SIGTRAP nostop noprint pass
  SIGTRAP is used by the debugger.
  Are you sure you want to change it? (y or n) y
  Signal        Stop      Print   Pass to program Description
  SIGTRAP       No        No      Yes             Trace/breakpoint trap

  (gdb) c
  Continuing.
  warning: HEAP[lmi_wx_shared.exe]:
  warning: Invalid Address specified to RtlFreeHeap( 003F0000, 66A7C42C )
  warning: HEAP[lmi_wx_shared.exe]:
  warning: Invalid Address specified to RtlFreeHeap( 003F0000, 0065E3B0 )
[these warnings come thick and heavy...]

Usually there are no wx diagnostics at all. It's a chore to scroll through
meaningless gdb chatter just to verify that there are none.