Re: [lmi] Anomalies with wine

[Vadim Zeitlin]

On Mon, 15 Feb 2016 18:08:35 +0000 Greg Chicares <address@hidden> wrote:

GC> Running lmi under wine, thus:

 Hello,

 Sorry for the delay with the reply to this message, it took me much longer
than I thought to set up WINE and find a way to debug it under it in a
decent way.

GC> address@hidden:~/.wine/drive_c/opt/lmi/bin$ wine ./lmi_wx_shared.exe \
GC> --ash_nazg --data_path=../data
GC> 
GC> I do
GC>   File | New | Illustration
GC> and this appears on the console:
GC> 
GC> In file ../src/msw/toplevel.cpp at line 1207: 'DrawMenuBar' failed
GC> with error 0x00000000 (success.).

 I don't see it with wxWidgets 3.1.0 nor, if you decide to use it because
of the changes below, with the latest master, so I hope this problem might
have been already fixed. In any case, it is almost certainly harmless.

GC> Seems kind of strange to fail with a success code.

 FWIW this is just to the way the generic macro logs an error followed by
MSW last error code (roughly similar to POSIX errno), which is not always
set. So this is slightly confusing but not very unusual.

GC> But that's just an interesting anomaly--not an actual problem. However,
GC> then this messagebox appears twelve times:

 Let me (smugly) note that this is due to using a custom assert handler in
lmi (see Skeleton::OnAssertFailure()) instead of using the standard wx one
as the latter would have allowed you to skip all the subsequent asserts
instead of having to dismiss a dozen of message boxes. I had written in the
past that I thought it was a convenient feature and I hope that now, after
struggling with this assert, you might be more willing to accept my point
of view.

 I'd also like to mention that the standard assert handler provides stack
trace allowing to see where the assert happened, which can be very useful
and would have helped a lot with this particular assert as it would have
pinpointed the exact location where the invalid data was coming from. Of
course, until now getting the stack trace only worked with MSVC and not
MinGW but I've actually changed this now and we could be getting the stack
traces for the asserts, albeit with some effort (see below).

 So I'd like to propose updating Skeleton::OnAssertFailure() to be more
like the built-in handler, namely:

1. Allow to skip all the subsequent asserts (an intriguing alternative
   would be to allow skipping all the subsequent instances of the same
   assert, i.e. with the same location information and I wonder if it
   might not even make sense to do it by default...).

2. Do mention the function name in the message, contrary to the existing
   comment it's not superfluous in practice because it's much nicer to
   know immediately where did the assert fail instead of having to hunt
   for it in the sources.

3. Include the stack trace, if available, in the message.

 Of course, the trouble with this is that it reproduces 90% of what the
built-in handler does. So maybe a simpler solution would be to just prevent
the built-in handler from proposing to break into the debugger which seems
to be the main (only?) reason lmi is not using it. Would you accept this?


GC> Error
GC> Assertion "(0 < day) && (day <= GetNumberOfDays(month, year))" failed
GC> (Invalid date in wxDateTime::Set()).
GC> file ../src/common/datetime.cpp, line 1221]
GC> 
GC> which is an actual though not insuperable inconvenience.

 To summarize a long story, this is due to a WINE bug and, unfortunately,
can only be really fixed by changing wxWidgets itself which is rather
mortifying considering that I hoped lmi would be able to use 3.1.0
unchanged for a long time and this long time turned out to be less than 2
weeks :-( Moreover, I could have easily fixed it before the release if I
only had found the problem sooner. But it's too late now and, as it is, you
need to either use the latest master or cherry pick just this simple commit

https://github.com/wxWidgets/wxWidgets/commit/7907711e82ddcd770b9688684c0249f3114300f0

to fix it. The commit contains a link to my WINE bug report if you're
curious.


 I'd also like to explain how I debugged this problem because I think it
might be useful to you in the future and to avoid the same problems I ran
into. As you, I also started by trying to use winedbg and also didn't have
much luck with it. By default it doesn't understand DWARF debug info
generated by gcc, so it needed to be converted to Microsoft PDB format.
This is also the case if you want to see the stack traces in wx assert
messages, so I did find a way to do it, thanks to cv2pdb program by Rainer
Schütze (https://github.com/rainers/cv2pdb), but it wasn't very convenient,
especially because cv2pdb itself doesn't run under WINE, so it involved a
lot of copying of (huge, due to debug info) DLLs and PDBs between Linux and
MSW machines.

 So my next attempt was to run "winedbg --gdb" to use it as gdb remote
target, but I just couldn't make it work and apparently gdb server support
is just broken in WINE since quite some time and there doesn't seem to be
many chances to see it fixed.

 Then I tried using gdbserver.exe under WINE but, for whatever reason,
/usr/share/win32/gdbserver.exe (from gdb-mingw-w64-target Debian package
which is only available as version 7.6.2 in Jessie) refused to work for me
under WINE. So I have copied gdbserver.exe 4.8 from MinGW64 4.9.1
installation to ~/.wine/drive_c and using it things finally worked, i.e.
now I can do

        $ wine gdbserver.exe localhost:12345 lmi_wx.exe

and then, from another terminal/screen window

        $ i686-w64-mingw32-gdb lmi_wx.exe
        (gdb) target extended-remote localhost:12345
        (gdb) set solib-search-path ...directories containing lmi and wx DLLs...
        (gdb) run lmi_wx.exe --all-the-usual-options

and debug normally as usual, i.e. with full access to debug information and
working breakpoints and so on. This is actually pretty nice and much less
heavy than running an entire VM just for debugging, so thank you for
forcing me to finally set this up.


GC> The 'skin.xrc' tabbed dialog looks good at 96 DPI.

 Notice that I normally use WINE at 200 DPI, it is just unusable otherwise
for me with my display resolution. But I did try it at 96 DPI as well and,
unfortunately, this doesn't change anything:

GC> The only weird thing I notice is that "State of jurisdiction" and
GC> "Premium tax state" have a very slight height (while other "state"
GC> fields look fine).

 I don't see this problem, these fields look fine to me, please see the
attached screenshot :-(

GC> In order to fix that, I guess I'll need to look at the enclosing
GC> sizers, because sizeritems that are laid out differently are not
GC> materially different:
GC> 
GC>   <flag>wxGROW</flag>
GC>   <object class="wxComboBox" name="PremiumTaxState">
GC>       <help>State to which premium tax is paid--affects premium load if the 
tax is passed through</help>
GC>       <style>wxCB_DROPDOWN|wxCB_READONLY</style>
GC>       <content><item>MM</item><item>WW</item></content>
GC>   </object>
GC> 
GC>   <flag>wxGROW</flag>
GC>   <object class="wxComboBox" name="State">
GC>       <help>Insured state</help>
GC>       <style>wxCB_DROPDOWN|wxCB_READONLY</style>
GC>       <content><item>MM</item><item>WW</item></content>
GC>   </object>

 I don't see absolutely anything wrong with this XRC. Unfortunately, unlike
with the DrawMenuBar error in the beginning of this message, I also don't
see any recent changes to wxWidgets which could have affected this, so I'm
much less optimistic about this problem not existing any more in 3.1.0.
Still, it would be nice if you could please update your wxWidgets to 3.1.0
(or to the latest master if you also want to avoid the asserts above...)
and confirm that you still see it. If you do, it must be coming from the
different ways we build lmi, I'm still not exactly sure how do you do it
under Linux: I'm using autotools-based system and I don't know how to do it
otherwise, could you please let me know?

 Finally, I do see another problem in this dialog however: with the date
picker control in which the year is not visible at all, please see the
attached screenshot. Do you see this one too? And should I try to debug it
(now that everything is set up, it should hopefully go slightly faster...)?

 Please let me know, thanks in advance,
VZ