[Bug 35229] Macromedia Freehand 9 demo hangs at intro window (ShowWindow operations should avoid potentially blocking inter-thread SendMessage if show command is no-op)

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=35229

Anastasius Focht <focht at gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |download
             Status|UNCONFIRMED                 |NEW
                URL|                            |http://macromedia-freehand.
                   |                            |software.informer.com/downl
                   |                            |oad/
                 CC|                            |focht at gmx.net
          Component|-unknown                    |user32
            Summary|Demo version of Freehand 9  |Macromedia Freehand 9 demo
                   |hangs at Intro window       |hangs at intro window
                   |                            |(ShowWindow operations
                   |                            |should avoid potentially
                   |                            |blocking inter-thread
                   |                            |SendMessage if show command
                   |                            |is no-op)
     Ever confirmed|0                           |1

--- Comment #2 from Anastasius Focht <focht at gmx.net> ---
Hello folks,

confirming.
Brain damaged app code ... as expected from Adobe/Macromedia :|

Relevant part of trace log:

--- snip ---
$ pwd
/home/focht/.wine/drive_c/Program Files/Macromedia/FreeHand 9

$ WINEDEBUG=+tid,+seh,+relay,+win,+msg wine ./FreeHand\ 9.exe >>log.txt 2>&1
...
0024:trace:win:WIN_CreateWindowEx "ReleaseNow.com Turnkey Technology"
L"Turnkexe951237FreeHand 9.exe" ex=00000080 style=02cf0000 860,535 200x20
parent=(nil) menu=(nil) inst=0x400000 params=(nil)
0024:trace:win:dump_window_styles style: WS_CLIPCHILDREN WS_CAPTION WS_SYSMENU
WS_THICKFRAME WS_MINIMIZEBOX WS_MAXIMIZEBOX
0024:trace:win:dump_window_styles exstyle: WS_EX_TOOLWINDOW 
...
0024:Ret  user32.CreateWindowExA() retval=00010064 ret=004067db
...
0024:Call
KERNEL32.CreateThread(00000000,00000000,004018f0,00000000,00000000,0033bd78)
ret=00401e71
0024:Ret  KERNEL32.CreateThread() retval=0000007c ret=00401e71
0024:Call KERNEL32.Sleep(00001388) ret=00401e81
...
0026:Starting thread proc 0x4018f0 (arg=(nil))
0026:Call user32.ShowWindow(00010064,00000000) ret=00401944
0026:trace:msg:send_inter_thread_message hwnd 0x10064 msg 80000002
(WM_WINE_SHOWWINDOW) wp 0 lp 0
0026:Call
winex11.drv.MsgWaitForMultipleObjectsEx(00000001,00b8c1f0,ffffffff,00000040,00000000)
ret=7ebcac4b
0024:Ret  KERNEL32.Sleep() retval=00000000 ret=00401e81 
<hangs here>
--- snip ---

The main thread creates several windows (toolwindow -> hidden!, dialog, ...)
and a secondary thread.
One of the first actions of this secondary thread is calling ShowWindow(
toolWindow, SW_HIDE) which gets synchronized via SendMessage() to the main
thread because it owns the window.

Unfortunately after spawning the secondary thread, the main thread immediately
calls Sleep(5000) and live-loops a register, blocking the secondary thread
indefinitely (which still hangs in SendMessage because the main thread doesn't
pump messages).

The actual code of main thread (disassembly after attaching to hanging
process):

--- snip ---
...
00401E4F  52            PUSH EDX              ; pThreadId
00401E50  890D DC0B4500 MOV DWORD PTR DS:[450BDC],ECX
00401E56  890D E00B4500 MOV DWORD PTR DS:[450BE0],ECX
00401E5C  51            PUSH ECX              ; CreationFlags => 0
00401E5D  51            PUSH ECX              ; Parameter => NULL
00401E5E  68 F0184000   PUSH 004018F0         ; StartAddress = 0x4018F0
00401E63  51            PUSH ECX              ; StackSize => 0
00401E64  51            PUSH ECX              ; pSecurity => NULL
00401E65  890D E40B4500 MOV DWORD PTR DS:[450BE4],ECX
00401E6B  FF15 38D14200 CALL DWORD PTR DS:[<&KERNEL32.CreateThread
00401E71  68 88130000   PUSH 1388             ; Time = 5000 ms
00401E76  A3 38B14300   MOV DWORD PTR DS:[43B138],EAX
00401E7B  FF15 7CD04200 CALL DWORD PTR DS:[<&KERNEL32.Sleep>]
00401E81  A1 D80B4500   MOV EAX,DWORD PTR DS:[450BD8]
00401E86  85C0          TEST EAX,EAX
00401E88  74 FC         JZ SHORT 00401E86
00401E8A  68 88130000   PUSH 1388             ; Timeout = 5000 ms
00401E8F  50            PUSH EAX              ; hProcess => [450BD8] = NULL
00401E90  FF15 8CD24200 CALL DWORD PTR DS:[<&USER32.WaitForInputId
00401E96  E8 A5040000   CALL 00402340
00401E9B  59            POP ECX
00401E9C  C3            RETN
--- snip ---

Notice the 'live' loop on register value at 00401E88..00401E88.
The compiler is not at fault here.
Whoever wrote that code probably never heard of 'volatile' (the value of
0x450BD8 is set some time later from secondary thread).

Anyway, Wine needs to check first if the 'show' command turns out a no-op, not
involving any message handling to avoid the potentially blocking SendMessage()
to the thread owning the window.

Source:
http://source.winehq.org/git/wine.git/blob/b423532f94efe9842d4c7e30166a4a2f2121fbbb:/dlls/user32/winpos.c#l1207

--- snip ---
/***********************************************************************
 *        ShowWindow (USER32.@)
 */
BOOL WINAPI ShowWindow( HWND hwnd, INT cmd )
{
    HWND full_handle;

    if (is_broadcast(hwnd))
    {
        SetLastError( ERROR_INVALID_PARAMETER );
        return FALSE;
    }
    if ((full_handle = WIN_IsCurrentThread( hwnd )))
        return show_window( full_handle, cmd );

    return SendMessageW( hwnd, WM_WINE_SHOWWINDOW, cmd, 0 );
}
--- snip ---

$ sha1sum freehand9-trial.exe 
a502e0d2e4590e118ea0215e947f16913a57b938  freehand9-trial.exe

$ du -sh freehand9-trial.exe 
14M    freehand9-trial.exe

$ wine --version
wine-1.7.9-158-g33fa552

Regards

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.