Re: [lmi] Segfault in wxGrid

[Vadim Zeitlin]

On Wed, 22 Jun 2016 00:47:34 +0000 Greg Chicares <address@hidden> wrote:

GC> Sadly, the product editor is a red-headed stepchild of lmi. Trying to
GC> improve it incrementally doesn't make much sense.

 FWIW it doesn't look unsalvageable to me, but there are things that really
need to be changed in it. I don't understand how could I fail to notice
this problem back when it was written :-(

GC> A segfault is always important, but I don't think this one is urgent:
GC> it's been in production for quite a while, and few if any end users
GC> these days use the product editor--so there's no need to try to work
GC> around this issue by changing lmi. Our code-freeze date for this month's
GC> release is Thursday. Upgrading wx always runs the risk of bringing in
GC> new anomalies. I believe we should upgrade wx only after this month's
GC> release, so that we have plenty of time for testing the upgrade.

 I understand, but, still, having an easily user-triggerable crash in
production software doesn't sit comfortably with me. What about applying
just the commit in question (ff5981230a1adc46c4ab3d895e2ff5d0c4cf96f0) as a
patch to the currently used sources? I'm pretty sure this commit is
completely independent of all the other changes in wx and also reasonably
certain it can't result in worse problems than the crash it fixes.

GC> >  I believe we should add -fno-omit-frame-pointer to wx_{cc,cxx}_flags to
GC> > have better stack traces with the current compiler. I'm not sure how
GC> > exactly do you generate them,
GC> 
GC> Generate what?
...
GC> Or...generate the stack traces that I've posted here?

 Yes, sorry for being unclear.

GC> I've been using the "Dr MinGW" JIT debugger for that.

 OK, I see it at https://github.com/jrfonseca/drmingw. Interestingly, the
README says that it can be used as a DLL, I wonder if we could just link
with it (ideally dynamically during run-time, to avoid any redistribution
problems/questions) to get this functionality.

GC> Would the wx stack walker be a suitable replacement? If so, then
GC> perhaps we should add that next month when we upgrade wx.

 As it stands right now, wxStackWalker would produce only addresses, not
symbolic information. My idea was to use addr2line to convert the former to
the latter and I am relatively confident that it's going to work because
this is what wxStackWalker does under Unix already (it's slow, of course,
but the goal here is not to generate millions of stack traces per second).
But this remains to be done...

 Regards,
VZ