Re: [lmi] Suppressing exception stack dumps

[Vadim Zeitlin]

On Thu, 18 Mar 2021 00:45:22 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 3/17/21 8:05 PM, Vadim Zeitlin wrote:
GC> > On Wed, 17 Mar 2021 18:21:05 +0000 Greg Chicares 
<gchicares@sbcglobal.net> wrote:
GC> > 
GC> >  I really think the solution to this is using a debugger. It's a brute
GC> > force and less elegant option, but just a much more efficient one and
GC> > you're never going to be able to replicate it in lmi itself (because
GC> > breakpoints can be conditional and execute arbitrary gdb commands when 
hit,
GC> > which makes them much more powerful than doing anything unconditionally).
GC> 
GC> But suppose I've done a series of operations in lmi's GUI, and an
GC> exception is thrown. I might not remember everything I did, and
GC> might not be able to reproduce the problem later when running under
GC> a debugger. Then an automatic backtrace is invaluable.

 I believe that in this case you really want to see something similar to
wxWidgets assert dialog rather than a backtrace on console (that even you
might not notice). I.e. I think that you want to handle exceptions not
caught until they reach the top level catch handler differently from the
others, that are caught closer to their source.

 So IMO there are 2 important points and not just one:

1. Not all users should be treated alike. You should set some environment
   variable or whatever to opt in the behaviour you want, but normal lmi
   users should never be affected by it.

2. Not all exceptions should be treated alike. All exceptions are
   unexpected, but some of them are more unexpected than others.


GC> Besides, I never really liked debuggers very much.

 Nobody _likes_ debuggers (well, at least I hope so). But they're just a
much more efficient tool to solve problems than print-debugging because
they're strictly more powerful and, importantly, don't require
recompilation, relinking or even relaunching the program. Of course, there
are always some exceptions (kernels, performance-critical code, ...) where
logging is preferable, but in general using a debugger is just much faster.


GC> A tangential question occurs to me. In that commit, I had thought of
GC> using a static member instead of a global variable to toggle the
GC> "trace" output. Then I thought that I'd heard of a reason not to do
GC> that, and found it with git-grep:
GC> 
GC> gpt_test.cpp:// These could be made static members of class gpt_test, but 
this way
GC> gpt_test.cpp://   
https://www.securecoding.cert.org/confluence/display/cplusplus/MSC22-CPP.+Do+not+define+static+private+members
GC> 
GC> Intrigued, I tried following that link, but it's gone, and that
GC> site doesn't seem to advise against the practice any more. Is this
GC> a good guideline, for some reason I don't remember and cannot now
GC> imagine? (I've found some of that site's recommendations dubious.)

 I can't find anything about MSC22-CPP guideline (only MSC22-C, which is
about not using longjmp(), and I think we can agree about this one...), so
it's really difficult to say what could they have had against it, but I'm
pretty certain you can disregard it anyhow, these secure coding guides
basically tend to forbid everything they can afford to forbid IME.

GC> Do you have any strong opinion about that global variable?
GC> I tend to think that it's okay, and that it's better for it to
GC> be separate from the "toggler" class, but I'm not really sure.

 To be honest, I don't see much difference between them and I'm perfectly
fine with keeping a global, but I would hardly be against a static member
neither.

 OTOH I do wonder if the flag shouldn't be an int, rather than a bool, i.e.
if it couldn't be possible to have nested scoped_unwind_toggler (even if
unwittingly)?


GC> We don't have multiple builds, one for development and another
GC> for production. I know some people do that, but it strikes me as
GC> dangerous, because an issue present in production might not be
GC> observed in development. To me at least, it seems wiser to eat
GC> the same food we're serving.

 This is a good argument, but I'm not proposing to start using a separate
debug build for your testing (if only because you're concentrating on
performance characteristics that would be completely different in it). I'm
just suggesting using an environment variable to modify the behaviour of
the same binary post factum, i.e. there is no way for it to change the
behaviour up to the point when the unexpected exception is thrown.

GC> Users don't see console output, so it can't confuse them.

 Well, this is becoming very philosophical because this output is only
generated under Linux where there are no users, but if there were some,
they would definitely be able to see it there. I'm not enlightened enough
to understand what does this mean, but I still believe that it's better not
to generate any output that nobody sees and provide a way to turn it on
when you do want to see it. And IMHO the cost of setting an environment
variable in your shell profile is just too insignificant to worry about it.

GC> Backtraces in particular do have non-negligible overhead, and
GC> the code that generates them may have defects, true; but any
GC> defect that occurs with any frequency will probably be found
GC> and fixed quickly, and exception-reporting overhead isn't
GC> incurred unless an exception is thrown (and unwound).

 Are you sure this is happening so rarely to be negligible?

GC> But I think practical experience should be our guide. I'd like
GC> to know of any concrete circumstances where this backtrace is
GC> inconvenient for you (now that I've suppressed it in unit tests).

 I'm going to finish some unrelated local changes and try it a.s.a.p. and
let you know.

 Thanks again for suppressing them in the tests, at least, this is already
very helpful!
VZ

pgpBkEeJscEjH.pgp
Description: PGP signature