Re: [lmi] Suppressing exception stack dumps

[Vadim Zeitlin]

On Wed, 17 Mar 2021 18:21:05 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 3/14/21 11:27 PM, Vadim Zeitlin wrote:
GC> > 
GC> >  The commit message of 12273527f (Add C++ exception unwinder for
GC> > pc-linux-gnu, 2021-02-07) mentions that "practical experience will guide
GC> > future use" and I'd like to provide some practical experience: IMHO, 
always
GC> > getting dumps of all exceptions and the corresponding stack trace is not
GC> > very useful, as it results in a huge amount of noise when running many
GC> > tests.
GC> 
GC> I've found it annoying in unit tests, myself; but only there.
GC> 
GC> When I'm running a GTK build, my problem more often is finding the
GC> backtrace among screensful of pink, yellow, and blue messages like:

 I really think the solution to this is using a debugger. It's a brute
force and less elegant option, but just a much more efficient one and
you're never going to be able to replicate it in lmi itself (because
breakpoints can be conditional and execute arbitrary gdb commands when hit,
which makes them much more powerful than doing anything unconditionally).

GC> Commit e0c15aab3 provides an on-off toggle, and toggles the backtrace
GC> off in a handful of places where we know we don't want it.

 Thanks, I'm going to test it a.s.a.p. but it should indeed fix the
immediate problem.

 The fundamental question about whether this exception stack reporting
should be enabled or disabled by default remains, however. IMO, as any
debugging helper, it must be disabled because the users really don't care
about this, but it may introduce some problems (more code to execute means
not only some, not that small in this case, overhead, but more chances of
something going wrong). Of course, right now no end users use a version
where this functionality is available, but if this changes in the future
(e.g. because we implement it for MSW too), I strongly believe this
shouldn't be enabled in production builds by default.


GC> > +    if (std::strcmp(std::getenv("LMI_VERBOSE_EXCEPTIONS"), "1") == 0)
GC> 
GC> That would offer much flexibility. But nothing else in lmi's C++ code
GC> reads the environment (except getopt(), as I was surprised to find).
GC> For pc-linux-gnu, it doesn't make much difference, but for msw, getenv()
GC> it has some drawbacks:

 Please feel free to ignore everything below, but I don't think any of
these drawbacks is actually relevant.

GC>  - it's inconvenient to set in an msw shortcut;

 This can indeed only be done from Cygwin/MSYS/WSL shell conveniently. Of
course, it just so happens that we always use one of those with lmi. And,
again, considering that I think it should be disabled by default, only lmi
developers should ever need to enable it.

GC>  - environment access may be blocked on corporate machines;
GC>  - corporations might flag getenv() specifically as a "security" risk;

 I don't think so, there is no mechanism for blocking environment access. I
think you might be thinking about permanently modifying the environment in
the registry, which could indeed be forbidden, even for the current user
(this is something that makes absolutely no sense but is at least
technically possible, so I'm ready to believe that somebody does this
somewhere). But there is just really no problem with neither setting nor
querying the current or child process environment and any program using CRT
does a bunch of getenv() calls anyhow.

GC>  - msw has traditionally limited the size of the total environment and
GC>    of each string, and then altered the limits in OS updates;

 AFAIK the limit of the total environment size was always 65KiB or 32K
Unicode characters in UTF-16. It is, I guess, indeed possible to overflow
this limit (my current environment is almost 8K characters and I try to
keep it trimmed down), but it doesn't change and if you do overflow it, I
think you're going to have worse problems than not being able to control
lmi variables display anyhow. In any case, we do plenty of environment
variables setting in install_msw.sh and if it works there, there is no
reason it shouldn't work here.

GC> so I'd rather sidestep all such potential problems by not using getenv()
GC> at all.

 Sorry again, but the arguments against using getenv() are extremely
unconvincing. From practical experience of using it in all my code
(including wxWidgets, BTW, which means that lmi already uses it too) for
25+ years, I've never, ever had any shadow of a problem due to using it and
I just don't understand how could it ever happen. The extra flexibility is
pretty nice, however.

 
GC> Except in situations where lmi catches an exception and does something
GC> interesting (e.g., displaying an abridged what() string),

 I wonder if what you really want is not this, instead:

1. Remember the stack when the exception is thrown (but _not_ print it out)
2. Show this stack if the exception is caught in one of the top-level catch
   statements, i.e. not caught before by some handler actually knowing what
   to do with it.

?

GC> I usually want
GC> to see a backtrace automatically. Restarting the program with a change
GC> in its environment is less convenient--often, extremely less. And if I
GC> don't want it, I just disregard it.

 IMHO this just means that you ought to set LMI_VERBOSE_EXCEPTIONS in your
environment, but all this doesn't apply to lmi users at all (it also
doesn't apply to me, but this is a much lesser problem, of course).

 Regards,
VZ

pgpUhXzyvbgeT.pgp
Description: PGP signature