lmi
[Top][All Lists]
Advanced

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

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


From: Vadim Zeitlin
Subject: Re: [lmi] wx_test: output strings truncated to one character
Date: Wed, 10 Feb 2016 14:08:15 +0100

On Wed, 10 Feb 2016 12:57:05 +0000 Greg Chicares <address@hidden> wrote:

GC> On 02/10/2016 12:09 PM, Greg Chicares wrote:
GC> > On 02/10/2016 12:51 AM, Vadim Zeitlin wrote:
GC> > [...]
GC> >>  If this happens during the application shutdown, it could well be the 
same
GC> >> bug with using the already destroyed global objects that I've just fixed.
GC> >> Otherwise I really have no idea :-( Could you please rebuild wxWidgets 
with
GC> >> --enable-debug and just drop the debug DLL in place of the one currently
GC> >> being used (and not containing the debug symbols)?
GC> 
GC> [...failed with PCH...]

 I won't even try to look into this right now because I have too many other
more urgent issues to address, but I'd just like to mention that I haven't
seen neither 0 size PCH creation nor silent (could adding "-###" to gcc
command line show more?) failure to build before.

GC> > My hypothesis is that this compiler can generate a zero-byte PCH file
GC> > that causes compilation to fail with no diagnostic. I'll try rebuilding
GC> > without PCH.
GC> 
GC> I modified 'install_wx.make':
GC> 
GC> +  --disable-precomp-headers \
GC> 
GC> ...
GC> +  --enable-debug \
GC> 
GC> 
GC> and did
GC>   /lmi/src/lmi[0]$time make --jobs=6 -f install_wx.make >../log 2>&1
GC> which replaces the old wx DLL with the new "debug" one, and now the
GC> GUI test runs to completion--no crash, but no wx "debug" diagnostics:

 This is bad because it seems to imply that only optimized code misbehaves
somewhere and this could well be a bug in the optimizer. On an off chance
that the build was somehow broken due to the PCH file corruption before,
would you mind rebuilding with --disable-precomp-headers but without
--enable-debug to check if it changes anything? Alternatively, I could make
my own binaries available to verify if the bugs you're seeing are due to
something on the machine where you run the tests or to the way you build
them.

 And if the bug does reappear, even with --disable-precomp-headers, when
you remove --enable-debug, the next step would be to use
--enable-debug_info instead which should still trigger the bug (as
optimizations remain in effect with it, unlike with the full
--enable-debug), but also allow to debug it.

 All this is obviously very worrisome because it's a clear regression
compared to MinGW 3.4, but unfortunately I just can't do much about it from
here as long as I can't even reproduce the bug :-(

 Regards,
VZ

reply via email to

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