Re: [lmi] boost regex segfault in wx_test

[Greg Chicares]

On 02/09/2016 11:24 PM, Vadim Zeitlin wrote:
> On Tue, 9 Feb 2016 15:51:37 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Using the new compiler to build lmi HEAD, I get a segfault in 'wx_test'.
> 
>  Unfortunately I don't see this, so I can't debug it. On a related note, I
> did see another crash and a pretty bad one as I hadn't seen it before when
> using multiple wx libraries but it now appears reliably to me when using
> the monolithic library because, apparently, the initialization order has
> changed, and some code executed from a global object dtor now resulted in
> an infinite recursion and stack overflow due to using another global
> objects which had been already destroyed. I've fixed this now in
> 
> https://github.com/wxWidgets/wxWidgets/commit/aece1f81b6334e0ea55453d23147f127932735b9
> 
> and while this doesn't seem to have any direct relationship to this
> problem, I'd still advise you to update your wxWidgets once again, if not
> now then soon, once I fix a few more things for 3.1.0.

Until recently, I'd have been sorely vexed at the prospect of rebuilding wx.
But...
  http://lists.nongnu.org/archive/html/lmi/2016-02/msg00004.html
|     --jobs=32
|   3238.23s user 175.19s system 1605% cpu 3:32.59 total
three and a half minutes...no problem.

> GC>     p1=0x52d2258
> GC> 
> "\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272",
> GC> <incomplete sequence \360\255\272>...,
> GC> 
> GC>     p2=0x52d2258 
> "\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272\r\360\255\272---Type
>  <return> to
> GC> continue, or q <return> to quit---
> 
>  Well, this definitely doesn't look like a valid wxString. I suspect this
> happens in a version compiled without debug information,

Actually, we build with '-ggdb -O2' for production. But my favorite
debugger is printf(), so...

> so you probably
> can't look at the "line_utf8" object in extract_last_copyright_year() under
> gdb, but perhaps you could add a printf() to show its contents? If it's
> really this, something is very wrong and it's not Boost.Regex fault at all.

I did this:
-----------------------8<-----------------------------
     std::string const line_utf8(line.utf8_str());
+std::cerr << "line: "      << line      << std::endl;
+std::cerr << "line_utf8: " << line_utf8 << std::endl;
     boost::smatch m;
-----------------------8<-----------------------------
and included <iostream>, and now I get:

/opt/lmi/bin[0]$./wx_test.exe --ash_nazg --data_path=/opt/lmi/data

NOTE: starting the test suite

a: started

About dialog version string is "2".

line: Copyright ▒ 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 
2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016 Gregory W. Chicares.

line_utf8: Copyright © 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 
2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016 Gregory W. Chicares.

pure virtual method called

time=8ms (for a)

a: ok

b: started

...
Expiry dates: begin=2, end=2

time=0ms (for e)

e: ok

i: started

In file ../include/wx/msw/private.h at line 834: 'UnregisterClass' failed with 
error 0x00000584 (class still has open windows.).


Thus, it no longer segfaults, though it still terminates abnormally with
this messagebox:

  Error

  Abnormal-termination handler called. Please report this problem.


This is beginning to feel spooky. I just reran the program several times,
and once it stepped through the GUI tests very sluggishly, but other times
it sped through them. It could be that this VM is flaky, given that this:
  https://cygwin.com/ml/cygwin/2016-02/msg00119.html
happened in it earlier today. But we know that 'wx_test' has some sort of
anomaly, reproduced on four different machines already, so I'm inclined to
suspect nondeterministic behavior due to the stack overflow you mentioned
above.

>  I also wonder how did you manage to continue beyond this crash to see the
> problem with the strings being truncated to the first character mentioned
> in the next message (which I do see, BTW)?

I didn't, not in this msw VM. The other message reports results on my
other workstation, which I booted into msw just for this occasion; those
results were similar to what I'm seeing now, and similar (but not the same)
as what Kim observed on msw-7 (hers didn't terminate abnormally).

My results, by the way, are for binaries built on the platform on which
they're run; I haven't imported my cross-compiled binaries yet.