http://bugs.winehq.org/show_bug.cgi?id=11582
Summary: Flash 5 Trial hangs when you click "Try" Product: Wine Version: CVS/GIT Platform: Other URL: http://download.macromedia.com/pub/flash/esd/flash5- trial.exe OS/Version: other Status: NEW Keywords: download Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: dank@kegel.com
Can't try this trial out very well. It installs, but when you start it, the "Try" button just locks the app.
http://bugs.winehq.org/show_bug.cgi?id=11582
Will aliask@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aliask@gmail.com URL|http://download.macromedia.c%7Chttp://download.macromedia.c |om/pub/flash/esd/flash5- |om/pub/flash/esd/flash5- |trial.exe |trial.exe
--- Comment #1 from Will aliask@gmail.com 2008-11-23 22:04:50 --- Just confirming that this bug is still there in Wine 1.1.9. I'd like to take a stab at working out the issue if someone would be willing to lend a hand pointing me in the right direction. Wine doesn't put any output into stderr, but setting WINEDEBUG=+all and grepping shows that KERNEL32.GetLastError is returning 0x57 (ERROR_INVALID_PARAMETER) but as far as I can see SetLastError is never called with 0x57, so tracking it down is proving troublesome. Am I missing something basic?
http://bugs.winehq.org/show_bug.cgi?id=11582
--- Comment #2 from Dan Kegel dank@kegel.com 2008-11-23 23:32:57 --- Mmm, maybe +all doesn't really show everything.
I usually avoid +all because it's too verbose for anything but apps that die before the UI starts. Try +relay,+seh instead, maybe. And maybe +message. Good luck...
http://bugs.winehq.org/show_bug.cgi?id=11582
--- Comment #3 from Will aliask@gmail.com 2008-11-24 00:30:55 --- Created an attachment (id=17427) --> (http://bugs.winehq.org/attachment.cgi?id=17427) Formatted +all log
Actually, I seem to have screwed something up on the first test, because now when I run it with +all, it just switches between two threads forever, waiting for something or another. One thread is doing stuff in the registry, then sleeps for 60s, and the other calls GetMessageW and DispatchMessageW over and over until interrupted by the other thread. Attaching a formatted and trimmed log from +all
http://bugs.winehq.org/show_bug.cgi?id=11582
--- Comment #4 from Dan Kegel dank@kegel.com 2008-11-24 00:33:28 --- No, don't post +all logs, they make our eyes hurt :-)
Since the problem involves message loops, you should probably try +message rather than +all. And maybe compare the +message output to the output of Spy++ or something like that on Windows...
http://bugs.winehq.org/show_bug.cgi?id=11582
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|CVS/GIT |unspecified
--- Comment #5 from Austin English austinenglish@gmail.com 2009-01-18 03:47:54 --- Removing deprecated CVS/GIT version tag. Please retest in current git. If the bug is still present in today's wine, but was not present in some earlier version of wine, please update version field to earliest known version of wine that had the bug. Thanks!
http://bugs.winehq.org/show_bug.cgi?id=11582
Niko Sandschneider nsandschn@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nsandschn@gmx.de
--- Comment #6 from Niko Sandschneider nsandschn@gmx.de 2009-08-02 05:43:27 --- Still present in wine 1.1.26.
http://bugs.winehq.org/show_bug.cgi?id=11582
--- Comment #7 from Austin English austinenglish@gmail.com 2010-06-12 01:28:56 --- f5d8c33b07023f418b8c7a8836df94090668318a flash5-trial.exe
Still present in 1.2-rc3. There is no terminal output.
http://bugs.winehq.org/show_bug.cgi?id=11582
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #8 from Anastasius Focht focht@gmx.net 2010-06-13 06:30:49 --- Hello,
looks like combination of Wine bug and incredibly stupid app code in some pathetic software protection scheme.
tid 24 = main thread tid 26 = debugger thread
--- snip --- 0024:Call user32.CreateWindowExA(00000080,00439f0c "Turnkexe951396Flash.exe",0045176c "ReleaseNow.com Turnkey Technology",02cf0000,000002e4,00000208,000000c8,00000014,00000000,00000000,00400000,00000000) ret=00406f7f ... 0024:Ret user32.CreateWindowExA() retval=000501a0 ret=00406f7f. ... 0024:Call KERNEL32.CreateThread(00000000,00000000,004018f0,00000000,00000000,0032aae0) ret=00401e81 0024:Ret KERNEL32.CreateThread() retval=00000054 ret=00401e81 0024:Call KERNEL32.Sleep(00001388) ret=00401e91 ... 0026:Starting thread proc 0x4018f0 (arg=(nil)) 0026:Call user32.ShowWindow(000501a0,00000000) ret=00401944 0024:Ret KERNEL32.Sleep() retval=00000000 ret=00401e91 <thread 0024 live locks here, eating 100% CPU> --- snip ---
To understand the problem, I present relevant pseudo code snippets of both threads, made up from disassembly.
Comments are courtesy of http://stackoverflow.com/questions/184618/what-is-the-best-comment-in-source... - I picked some to spice this stupid code up ;-)
--- snip main app thread ---
... /* reset global variable */ process_info.handle = 0; ... /* please work */ thread = CreateThread(0, 0, debugger_thread_proc, 0, 0, &tid); /* these magic numbers are fscking stupid. */ Sleep( 0x1388); /* please god, when will the hurting stop? */ while ( !process_info.handle) ; WaitForInputIdle( process_info.handle, 0x1388); ... --- snip main app thread ---
--- snip debugger thread --- ... ShowWindow( main_wnd, 0); ... if ( !CreateProcess( ..., (LPPROCESS_INFORMATION) &process_info.handle)) { /* I failed miserably */ return 0; }
/* debugger loop, process events */ for( ;;) { WaitForDebugEvent( ...) ... ContinueDebugEvent( ...) } ... --- snip debugger thread ---
After creation, the debugger thread immediately tries to hide the main window - owned by different thread - before launching the child process -> ShowWindow( SW_HIDE). Wine synchronously handles this using SendMessage().
The problem is that the main thread isn't able to process messages at this time because it's stuck in that incredibly stupid Sleep( some_magic_delay_that_ought_to_be_enough_to_bring_up_child_debugger_loop).
After the main thread delay expires - while debugger thread is still stuck in ShowWindow() call - the main thread immediately goes into a busy loop, checking the child process handle. Because the child process handle is initialized by code run after ShowWindow(), it will live-lock here.
I'm not sure how Windows handles this - I was too under impression that ShowWindow() should act synchronously if the window is owned by a different thread. If the app doesn't live lock in Windows, ShowWindow() behaviour is most likely different in Windows kernel.
Regards
http://bugs.winehq.org/show_bug.cgi?id=11582
--- Comment #9 from Anastasius Focht focht@gmx.net 2011-05-10 15:14:19 CDT --- Hello,
still present.
$ sha1sum flash5-trial.exe f5d8c33b07023f418b8c7a8836df94090668318a flash5-trial.exe
$ wine --version wine-1.3.19-248-g6a3255b
Regards
http://bugs.winehq.org/show_bug.cgi?id=11582
Adam Bolte boltronics@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |boltronics@gmail.com
--- Comment #10 from Adam Bolte boltronics@gmail.com 2012-09-01 05:51:02 CDT --- Still present.
$ sha1sum flash5-trial.exe f5d8c33b07023f418b8c7a8836df94090668318a flash5-trial.exe
$ wine --version wine-1.5.12
http://bugs.winehq.org/show_bug.cgi?id=11582
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |user32 Hardware|Other |x86 Version|unspecified |0.9.55. Summary|Flash 5 Trial hangs when |Macromedia Flash 5 Trial |you click "Try" |hangs when you click "Try" | |(ShowWindow operations | |should avoid potentially | |blocking inter-thread | |SendMessage if show command | |is no-op) OS|other |Linux
--- Comment #11 from Anastasius Focht focht@gmx.net --- Hello folks,
still present.
Actually bug 35229 has the same manifestation, merging both bugs together.
Same thing here: the tool window is already hidden hence ShowWindow( toolWindow, SW_HIDE) should be essentially a no-op.
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/b423532f94efe9842d4c7e30166a4a2f2...
--- 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 ---
Regards
http://bugs.winehq.org/show_bug.cgi?id=11582
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bugs.drew@yahoo.com
--- Comment #12 from Anastasius Focht focht@gmx.net --- *** Bug 35229 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=11582
--- Comment #13 from Drew Bugs bugs.drew@yahoo.com --- Created attachment 47211 --> http://bugs.winehq.org/attachment.cgi?id=47211 Return immediately from ShowWindow if hiding a previously hidden Window
I believe the attachment address AF's analysis. The program goes a bit farther, but the second thread gets caught in a Debug loop.
Should the patch be submitted to wine-patches?
http://bugs.winehq.org/show_bug.cgi?id=11582
--- Comment #14 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to comment #13)
Created attachment 47211 [details] Return immediately from ShowWindow if hiding a previously hidden Window
I believe the attachment address AF's analysis. The program goes a bit farther, but the second thread gets caught in a Debug loop.
Should the patch be submitted to wine-patches?
Looks reasonable, show_window() implementation does the same check. Just a nitpick: remove extraneous braces around WS_VISIBLE :)
https://bugs.winehq.org/show_bug.cgi?id=11582
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
https://bugs.winehq.org/show_bug.cgi?id=11582
--- Comment #15 from Bruno Jesus 00cpxxx@gmail.com --- Patch commited: http://source.winehq.org/git/wine.git/?a=commit;h=f271634296a952a7e0efdf8a7f...
https://bugs.winehq.org/show_bug.cgi?id=11582
--- Comment #16 from Drew Bugs bugs.drew@yahoo.com --- This bug can be resolved as fixed by someone who has the necessary permissions.
https://bugs.winehq.org/show_bug.cgi?id=11582
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |f271634296a952a7e0efdf8a7fe | |474e67367c7e5 Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #17 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Drew Bugs from comment #16)
This bug can be resolved as fixed by someone who has the necessary permissions.
Fixed.
https://bugs.winehq.org/show_bug.cgi?id=11582
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #18 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.7.32.