[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] lmi + wine-3.0 (Debian 3.0-1) = purple fungus
From: |
Greg Chicares |
Subject: |
Re: [lmi] lmi + wine-3.0 (Debian 3.0-1) = purple fungus |
Date: |
Fri, 20 Jul 2018 14:47:36 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 |
On 2018-07-20 12:29, Vadim Zeitlin wrote:
> On Wed, 18 Jul 2018 21:12:37 +0000 Greg Chicares <address@hidden> wrote:
>
> GC> /opt/lmi/bin[0]$wine ./lmi_wx_shared --ash_nazg --data_path=/opt/lmi/data
> --pyx=only_new_pdf
> GC> In file /cache_for_lmi/vcs/wxWidgets/src/msw/mdi.cpp at line 1488:
> 'SendMessage(WM_MDISETMENU)'\
> GC> failed with error 0x00000578 (Invalid window handle.).
[...]
> Yes, I'm quite sure it is harmless. You could confirm it by setting
> WINEDEBUG=mdi and verifying that you get 2 trace messages from
> SetMenuBar(), the first one of the form
>
> "%p, frame menu %p, window menu %p\n"
>
> and the second one, only given if the parameter validity checks succeed, of
> the form
>
> "old frame menu %p, old window menu %p\n"
/opt/lmi/bin[0]$WINEDEBUG=mdi wine ./lmi_wx_shared --ash_nazg
--data_path=/opt/lmi/data --pyx=only_new_pdf 2>&1 |less -S
0194:trace:mdi:MDISetMenu 0xea10518, frame menu 0x2a40766, window menu (nil)
0194:trace:mdi:MDISetMenu old frame menu (nil), old window menu (nil)
Maybe "(nil)" indicates a null pointer and 'wine' dislikes that for some
reason; but the msw documentation for WM_MDISETMENU says that wParam and
lParam can be NULL, with well-defined consequences.
> So it is really not that important
Agreed.
> GC> git log --patch src/msw/mdi.cpp
> GC> and search for "MDISetMenu".
>
> FWIW a potentially faster way to see this is to use "git blame".
Thanks, I didn't think of that.
> GC> I thought I'd be able to see that file
> GC> as of the wx SHA1 we're using in production thus:
> GC>
> GC> /opt/lmi/vcs/wxWidgets[0]$git show
> 2a5aafb27419efb36999e24dbcc091eacea56286:src/msw/mdi.cpp
> GC> fatal: Path 'src/msw/mdi.cpp' exists on disk, but not in
> '2a5aafb27419efb36999e24dbcc091eacea56286'.
> GC>
> GC> but that SHA1 doesn't even seem to exist:
> GC>
> GC> /opt/lmi/vcs/wxWidgets[128]$git show
> 2a5aafb27419efb36999e24dbcc091eacea56286
> GC> fatal: bad object 2a5aafb27419efb36999e24dbcc091eacea56286
> GC>
> GC> How is that so?
>
> The only explanation I have is that you somehow hadn't fetched it yet, but
> if you had run the updated install_wx.sh from the PR 86, you should have
> it.
Simple explanation: that was an old directory that I hadn't removed.
This is the proxy created with 'git clone' and updated with 'git fetch',
where the command works as expected:
/opt/lmi/src/lmi[0]$pushd /cache_for_lmi/vcs/wxWidgets
/cache_for_lmi/vcs/wxWidgets[0]$git show
2a5aafb27419efb36999e24dbcc091eacea56286 |head -1
commit 2a5aafb27419efb36999e24dbcc091eacea56286
This was a working copy created 2018-04-11 and untouched since then
even though I upgraded wx just the other day; apparently it's a
leftover artifact of some earlier version of 'install_wx.sh':
/opt/lmi/src/lmi[0]$pushd /opt/lmi/vcs/wxWidgets
/opt/lmi/vcs/wxWidgets[0]$git show 2a5aafb27419efb36999e24dbcc091eacea56286
|head -1
fatal: bad object 2a5aafb27419efb36999e24dbcc091eacea56286
...and it probably predates that SHA1. Therefore, I've now done this:
rm -rf /opt/lmi/vcs/
and the problem is presumably now fixed.