Re: [lmi] boost regex segfault in wx_test

[Vadim Zeitlin]

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.

GC> One line of attack would be to use standard <regex> instead.

 I definitely plan to do it "soon" in any case, I just didn't have time to
do it yet...

GC> Program received signal SIGSEGV, Segmentation fault.
GC> 
GC> boost::basic_regex<char, boost::regex_traits<char, 
boost::cpp_regex_traits<char> > >::do_assign (
GC> 
GC>     this=0x4a5d6a <vtable for 
SkeletonTest::CreateDocManager()::DocManagerTest+1962>,
GC> 
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, 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 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)?

 Thanks,
VZ