[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] wx_test: output strings truncated to one character

From: Greg Chicares
Subject: Re: [lmi] wx_test: output strings truncated to one character
Date: Wed, 10 Feb 2016 01:36:58 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0

On 02/10/2016 12:51 AM, Vadim Zeitlin wrote:
> On Wed, 10 Feb 2016 00:15:25 +0000 Greg Chicares <address@hidden> wrote:
> GC> On 02/09/2016 06:30 PM, Greg Chicares wrote:
> GC> [...problems with 'wx_test'...]
> GC> > Here's the same thing, built and run in msw-xp running on bare metal.
> GC> > This is new--I guess it's a gcc-4.x runtime diagnostic:
> GC> >   "pure virtual method called"
> GC> > We didn't see that in msw-7 or in my msw-xp VM.
> GC> 
> GC> Three different results on three different machines, and you won't be
> GC> able to reproduce all three,
>  I can reproduce, and explain, the truncated output: MinGW now uses its own
> stdio implementation which means that its "%s" format specifier is standard
> compliant and expects "char*" arguments even in wide format strings, unlike
> the MSVC stdio which handles "%s" as "%ls" in this case. The good news is
> that it shouldn't be very difficult to fix this, as we already implement
> wxPrintf() in terms of printf() with such semantics under Unix. The bad
> news is that it definitely requires updating wxWidgets as it can only be
> fixed inside it. I'm working on this right now and will finish it today or
> tomorrow at the latest.

Well, I could wait for that, but...

> GC> so I figured I should take the obvious
> GC> next step here and break on '__cxa_pure_virtual'. My a priori
> GC> expectation is that I'd find a bad constructor, but the stack trace
> GC> points to wxTextAutoCompleteData::ChangeStrings(). However, that may
> GC> mean nothing, because three levels deep the backtrace points into
> GC> Shangri-La, so maybe all we can tell is that the stack is trashed.
>  If this happens during the application shutdown, it could well be the same
> bug with using the already destroyed global objects that I've just fixed.
> Otherwise I really have no idea :-( Could you please rebuild wxWidgets with
> --enable-debug and just drop the debug DLL in place of the one currently
> being used (and not containing the debug symbols)?

...instead let me just do that now. To avoid introducing another source
of variation, I'll do that in an msw VM. It's not like that's going to
lock up my comput

reply via email to

[Prev in Thread] Current Thread [Next in Thread]