Re: [lmi] Group quote PDF: segfault on strlen

[Greg Chicares]

On 2017-03-08 16:39, Vadim Zeitlin wrote:
> On Wed, 8 Mar 2017 16:14:18 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> BTW, if you know specific steps that would have let me find this
> GC> myself in the wine environment, that's something I'd be glad to
> GC> learn. I couldn't get i686.../addr2line to do anything helpful
> GC> with the addresses in the crash report. I ran
> GC>   winedbg ./lmi_wx_shared [usual arguments]
> GC> and trapped the problem there so I could run 'bt', but it was
> GC> no less cryptic than the crash report posted earlier.
> 
>  I don't think winedbg understands DWARF debug symbols, it probably only
> supports the debug information supported by Windows dbghelp.dll. So you
> need to either use cv2pdb (https://github.com/rainers/cv2pdb) tool to
> convert debug info generated by gcc to the format it can understand or,

Thanks, I hadn't heard of that.

> better for this use, IMO, just run gdbserver under Wine and connect to it
> from gdb running under Linux and have the same debugging experience as
> usual.

I tried something like that (not today, but in the not-too-distant past),
but it wasn't usable. Maybe I tried connecting from a cross-built gdb.

> It might also be possible to run gdb itself under Wine, but it's not
> as convenient.

I think I also tried that, but didn't get any symbols. But I'm not sure.

These things are so painful that I haven't tried doing them unless
there's a problem that requires immediate attention. I should make time
to look into this in calmer circumstances.

>  However in this particular case I'm not even sure if gdb would be of much
> help. While you did get a crash, it's not certain at all that you got it at
> the location where the bug really happened and here I didn't see the crash
> when generating the PDF at all, but only got it later on program exit, so
> the (mis)behaviour doesn't seem to be completely deterministic and gdb
> wouldn't be able to pinpoint the place where it starts, i.e. where the
> invalid iterator is dereferenced for the first time.

Yes. Without your correction (which I've pushed now), the iterator was
getting incremented by two or three on certain passes, so the statement
that breaks when it's exactly equal to end() might never have executed.

>  And the way I actually found this bug was not by debugging at all, but
> just by running the program using debug MSVC build, which uses debug STL
> version which immediately detected the use of the invalid iterator. I'd
> expect that using "safestdlib" build would find it too, but wx code is not
> built at all for this build type currently, so it's a bit difficult to
> check. Making it easier to build lmi with _GLIBCXX_DEBUG might be a
> worthwhile goal...

Someone just mentioned the Baader-Meinhof phenomenon to me, and now it
arises again in the same day: Kim reported this problem just minutes
after I had done a "safestdlib" build and ran all the (wx-exclusive)
tests it's capable of running. The last time I considered it, it seemed
that maintaining a separate version of wx built with the _GLIBC*
debugging macros would have taken too much time, but in this century
computers are so much faster that such ideas become far more attractive.

It also wouldn't be a bad idea to add group-quote PDF generation to the
automated GUI tests. But I'm not sure whether that would necessarily
have caught this problem--perhaps the now-repaired code would have
"worked" by accident with some particular input.