Re: [lmi] lmi + wine-3.0 (Debian 3.0-1) = purple fungus

[Greg Chicares]

On 2018-03-06 22:53, Greg Chicares wrote:
> On 2018-03-06 14:54, Vadim Zeitlin wrote:
>> On Fri, 2 Mar 2018 18:32:16 +0000 Greg Chicares <address@hidden> wrote:
[...]
>> GC> For now, I'll just copy and paste the console messages:
>> GC> 
>> GC> $wine ./lmi_wx_shared.exe --ash_nazg --data_path=/opt/lmi/data
>> GC> In file ../src/msw/mdi.cpp at line 1491: 'SendMessage(WM_MDISETMENU)' 
>> failed with error 0x00000578 (Invalid window handle.).
>> GC> 0009:err:datetime:DATETIME_WindowProc unknown msg 100f wp=00000000 
>> lp=006b7fcc
>> GC> 0009:err:datetime:DATETIME_WindowProc unknown msg 100f wp=00000000 
>> lp=006b874c
>> 
>>  Interestingly enough, I did see the first message with an old (gcc 6.3)
>> build of lmi I had, but now that I rebuilt everything using the latest
>> sources, I don't see it any more. I do still see the 2 other ones however.
> 
> Here, with stretch + gcc-6.3, I never saw such console messages.
> But with buster + gcc-7.2 I see the DATETIME_WindowProc only with
> msw-10, not with msw-xp; yet the MDI error 578 occurs no matter
> which msw emulation I choose.
> 
> I've copied an old gcc-6.3 release from last Halloween into my
> "buster" chroot now, just to see what happens. It behaves exactly
> the same way as buster + gcc-7.2 + msw-xp above: MDI error 578,
> but no other console message. So that MDI-578 thing is a buster
> regression.

It can't be merely a wine or gcc regression, because that message
has reappeared since I upgraded wx for PDF pagination:

/opt/lmi/bin[0]$wine ./lmi_wx_shared --ash_nazg --data_path=/opt/lmi/data 
--pyx=only_new_pdf
In file /cache_for_lmi/vcs/wxWidgets/src/msw/mdi.cpp at line 1488: 
'SendMessage(WM_MDISETMENU)'\
 failed with error 0x00000578 (Invalid window handle.).

As before:
  it always appears once per invocation of lmi;
  it appears even if I quit lmi immediately after loading;
  it's shown only on the console, so no end user would see it; and
  it doesn't seem to be associated with any discernible ill effect;
so it doesn't seem to call for urgent investigation, especially if
it's observed only with 'wine'.

The interesting news is that it is does not appear with the code in
production (without the wx upgrade), which I archived yesterday:

/opt/lmi/bin[0]$pushd ../lmi-20180717T1419Z 
/opt/lmi/lmi-20180717T1419Z /opt/lmi/bin
/opt/lmi/lmi-20180717T1419Z[0]$wine ./lmi_wx_shared --ash_nazg 
--data_path=/opt/lmi/data --pyx=only_new_pdf
/opt/lmi/lmi-20180717T1419Z[0]$popd
/opt/lmi/bin

I haven't upgraded wine or gcc since then, and I certainly didn't
upgrade wine between 'pushd' and 'popd' above.

[Speed-read through this wild-goose chase to the git question below.]
The source line referred to is marked below:

  void MDISetMenu(wxWindow *win, HMENU hmenuFrame, HMENU hmenuWindow)
...
        ::SetLastError(ERROR_SUCCESS);

        if ( !::SendMessage(GetWinHwnd(win),
                            WM_MDISETMENU,
                            (WPARAM)hmenuFrame,
                            (LPARAM)hmenuWindow) )
        {
            const DWORD err = ::GetLastError();
            if ( err != ERROR_SUCCESS )
            {
                wxLogApiError(wxT("SendMessage(WM_MDISETMENU)"), err); <--THIS 
IS LINE 1488
            }

However, AFAICT, the last time that function was modified was
  commit 9650c5b55bb2cf2a6a57a120b56cb9c8206b2aff
  2014-10-24T13:45:41+00:00
and we've certainly updated wx more than once in the last four years,
so whatever made this message reappear now must be upstream of that
function. At least that's the way it appears if I do
  git log --patch src/msw/mdi.cpp
and search for "MDISetMenu". I thought I'd be able to see that file
as of the wx SHA1 we're using in production thus:

/opt/lmi/vcs/wxWidgets[0]$git show 
2a5aafb27419efb36999e24dbcc091eacea56286:src/msw/mdi.cpp
fatal: Path 'src/msw/mdi.cpp' exists on disk, but not in 
'2a5aafb27419efb36999e24dbcc091eacea56286'.

but that SHA1 doesn't even seem to exist:

/opt/lmi/vcs/wxWidgets[128]$git show 2a5aafb27419efb36999e24dbcc091eacea56286   
             
fatal: bad object 2a5aafb27419efb36999e24dbcc091eacea56286

How is that so? I thought 'git show SHA1' should always work. My HEAD
is detatched three commits into PR 86, but that shouldn't matter, right?