Re: [lmi] Getting stack trace on segfault (was: Upgrading wx: ellipsis buttons, and wxUSE_STACKWALKER)

[Vadim Zeitlin]

On Tue, 12 Jul 2016 00:25:33 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-06-09 15:22, Vadim Zeitlin wrote:
GC> > On Thu, 9 Jun 2016 14:57:01 +0000 Greg Chicares <address@hidden> wrote:
GC> [...]
GC> > GC> So we'd get a stack trace if lmi crashes?
GC> > 
GC> >  Well, almost.
GC> 
GC> Let me ask for a little more detail here. I understand that
GC> wxAppConsole::OnAssertFailure() can give a stack trace if a wxASSERT()
GC> condition is false. But does wx have a way of trapping a segfault in
GC> lmi and displaying a stack trace before lmi terminates?

 No, not when using MinGW currently because the way we do it is by
installing a SEH translator which is specific to MSVC. However, I don't
really know/remember why are we doing it like this, even for MSVC, because
using ::SetUnhandledExceptionFilter() is a better way of catching crashes
(even when using MSVC) and should work with MinGW too. As I think I already
proposed, I could look into changing wxWidgets to work like this and then
we would be able to do this.


GC> I suppose I could derive a class from wxAppTraitsBase,

 Yes, this is the way customizing global behaviour is supposed to work.

GC> but is there a simpler way to get the stack trace without the
GC> yes-no-cancel dialog?

 I'm afraid not. I supposed we could provide a (public) static
wxStackWalker::GetAssertStackTrace() function to make it simpler (I'd
prefer this to exposing it in wxAppTraits because it doesn't seem to
logically belong there).

GC> BTW, I've copied a specimen stack trace below (obtained by suppressing
GC> lmi's Skeleton::OnAssertFailure() override). This could be useful

 A full minidump would be even more useful, but this is definitely vastly
better than nothing. I think we need to (at least optionally) allow having
more than 20 stack frames, this is barely enough even in this simple case
(although this is partially due to including 6 more frames than necessary
because the code doesn't recognize the mangled "wxOnAssert", which would be
fixed by implementing demangling in MSW wxStackWalker properly, see below).

GC> if we could persuade end users to send it to us

 The best would be to send it automatically (after asking the user for
confirmation, of course), but this would require more work and I'm not
sure if your users execution environment would allow them to do this.

GC> (we can run it through the gcc demangler ourselves; end users wouldn't
GC> understand the demangled version anyway).

 But lmi developers could and it would be more convenient to see the
functions names with proper signatures immediately rather than having to
run them through c++filt manually. And it seems simple to do because we
actually have the same __cxxabiv1::__cxa_demangle() we already use under
Unix in MinGW-w64 4.9.1, so we could just reuse the same code under MSW
too.

 Regards,
VZ