http://bugs.winehq.org/show_bug.cgi?id=10543
Summary: worms armageddon crashes when clicking the menu Product: Wine Version: 0.9.49. Platform: PC URL: http://appdb.winehq.org/objectManager.php?sClass=version &iId=1744 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-user AssignedTo: wine-bugs@winehq.org ReportedBy: madewokherd@gmail.com CC: julliard@winehq.org
Since wine 0.9.49, clicking on the menu causes worms armageddon to crash (it appears to be attempting to minimize itself because it has lost the focus). This makes it impossible to play the game. No hacks are necessary to reproduce this bug.
Git bisect shows that the problem started after this patch:
c183a9e6e7809ef39874d1c01778af31173d0e82 is first bad commit commit c183a9e6e7809ef39874d1c01778af31173d0e82 Author: Alexandre Julliard julliard@winehq.org Date: Wed Oct 31 18:12:56 2007 +0100
server: Added support for HWND_TOPMOST and HWND_NOTOPMOST.
:040000 040000 1a21522356184dddd69c4a9847b23dc6bb69b82d 2088b5cd80a6db2754f6126eb9b219d7f590144f M dlls :040000 040000 bf605e24933452c319db5d462b1d1cb53735bd76 ab771fd193a719dc077861e14b5a0c77b559c141 M server
http://bugs.winehq.org/show_bug.cgi?id=10543
--- Comment #1 from Vincent Povirk madewokherd@gmail.com 2007-11-22 15:22:48 --- I believe this is significant:
The game only crashes when I click on a button. If I click on the background (which is a useless and silly thing to do), the game continues to run.
Worms Armageddon creates two top-level windows: one titled Worms Armageddon and one titled T17. Each screen in the menu is actually a dialog that it paints over with directdraw.
I've made a +win,+dialog log with 0.9.48 and 0.9.49 of me clicking on a button in the WA menu. After the click (which I located by searching for SendInput mouse), the logs begin to diverge at WINPOS_ActivateOtherWindow (apparently this function is called as a result of EndDialog). I do not understand the purpose of that function or how it works, but in 0.9.48 it chooses T17. In 0.9.49, it chooses (nil). I believe this is causing WA to attempt to minimize itself at a critical time and causing the crash.
Since WINPOS_ActivateOtherWindow was not modified in the patch identified by git bisect, I believe that the difference is because of other ways that the windows were treated differently before that function was called.
I think that if I understood why WINPOS_ActivateOtherWindow used to choose T17, I would know much more about this problem. It seems to me it should only choose a root window or a sibling of the hwnd passed to it as an argument (which in this case should be the dialog, a child of Worms Armageddon). Can anyone explain or point me to documentation about any of this?
I will attached the gzipped logs.
http://bugs.winehq.org/show_bug.cgi?id=10543
--- Comment #2 from Vincent Povirk madewokherd@gmail.com 2007-11-22 15:25:33 --- Created an attachment (id=9291) --> (http://bugs.winehq.org/attachment.cgi?id=9291) +win,+dialog logs, gzip compressed
http://bugs.winehq.org/show_bug.cgi?id=10543
--- Comment #3 from Lei Zhang thestig@google.com 2007-11-24 11:21:59 --- does the demo have the same problem?
http://downloads.gamezone.com/demos/d1083.htm
http://bugs.winehq.org/show_bug.cgi?id=10543
--- Comment #4 from Vincent Povirk madewokherd@gmail.com 2007-11-24 13:10:03 --- The demo has a different problem that started at the same wine release. It does not respond to mouse clicks at all.
The demo was never actually playable, but the menu used to work.
http://bugs.winehq.org/show_bug.cgi?id=10543
--- Comment #5 from Ben Pickhardt ben.pickhardt@gmail.com 2007-12-04 04:21:03 --- I have this same issue on Fedora Core 8. I was running 0.9.48 and updated to 0.9.49 and my works is broken with 2 problems.
I have to now use the /NOINTRO flag to get to the menu screen, if I don't the game crashes while loading the main menu after the intro screens.
Once I get to the main menu clicking on any of the options on the screen crashes the program.
On a side note, I don't know when it happened but I can only get my mouse to let me select options while running in windowed mode. Full screen used to work for me but I don't remember what version of wine I had at the time or if anything else changed.
Some things I've tried: Compile 0.9.50 from source and run the program, same problems. Reinstall clean 0.9.48 and run the program, Works in windowed mode only. Updated back to 0.9.49, with yum from fedora update repository, same problems. Run without window manager handling the window, same problems.
Note that the ddraw.dll in the Worms Armageddon directory has been replaced with the correct one for each version of wine, from the AppDB howto article.
I don't know if it helps but this is the output on the terminal I get when it dies.
fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb41-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb46-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb41-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb46-f175-11d1-a392-00e0291f3959} not found err:ole:CoGetClassObject class {e30629d1-27e5-11ce-875d-00608cb78066} not registered err:ole:CoGetClassObject no class object {e30629d1-27e5-11ce-875d-00608cb78066} could be created for context 0x1 err:quartz:GraphBuilder_Render Unable to create filter (80040154), trying next one fixme:win:LockWindowUpdate ((nil)), partial stub! fixme:winmm:MMDRV_Exit Closing while ll-driver open
http://bugs.winehq.org/show_bug.cgi?id=10543
--- Comment #6 from Vincent Povirk madewokherd@gmail.com 2007-12-06 14:51:14 --- I used an autohotkey script to log the series of activated windows on wine 0.9.48 and on a friend's windows machine. We each went to the hotseat game screen and the options subscreen and then quit by clicking the quit buttons. It showed that T17 was activated 4 times on wine 0.9.48 and not at all on windows.
Unfortunately, the script has a race condition: if the focus changes twice fast enough, it will only see the second change. To confirm my results, we used another script that waited specifically for T17 to activate (this does not have a race condition unless AHK's implementation of WinWaitActive does) and logged the same things. It logged 5 lines on wine 0.9.48 (the last one was 0x20034 - - activated, the others did show T17's title) and 1 on windows (0xe0616 - - #32770 activated). So I know T17 was activated at least once on windows, but I don't know when. I believe it happened only once, but I can't prove it.
This (and bug 8101 and the fact that a WA developer expected the focus to go to a parent of a dialog when the dialog was ended) leads me to believe that the WA frontend only worked in the past by coincidence and that WINPOS_ActivateOtherWindow was never correct in situations WA creates. I will need to research WINPOS_ActivateOtherWindow--find out why it exists, what it's supposed to do, why we expect the functions using it to work the same way--and create some tests of how dialog windows that are also child windows (which is the situation I believe WA creates that causes problems for wine) work.
I will attach my first script and the logs it generated.
http://bugs.winehq.org/show_bug.cgi?id=10543
--- Comment #7 from Vincent Povirk madewokherd@gmail.com 2007-12-06 14:53:28 --- Created an attachment (id=9525) --> (http://bugs.winehq.org/attachment.cgi?id=9525) autohotkey script to log a series of active windows
http://bugs.winehq.org/show_bug.cgi?id=10543
--- Comment #8 from Vincent Povirk madewokherd@gmail.com 2007-12-06 14:54:08 --- Created an attachment (id=9526) --> (http://bugs.winehq.org/attachment.cgi?id=9526) result of ahk script on wine 0.9.48
http://bugs.winehq.org/show_bug.cgi?id=10543
--- Comment #9 from Vincent Povirk madewokherd@gmail.com 2007-12-06 14:54:30 --- Created an attachment (id=9527) --> (http://bugs.winehq.org/attachment.cgi?id=9527) result of ahk script on windows
http://bugs.winehq.org/show_bug.cgi?id=10543
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |DUPLICATE
--- Comment #10 from Vincent Povirk madewokherd@gmail.com 2007-12-06 15:19:06 --- The hack described in http://bugs.winehq.org/show_bug.cgi?id=3023#c3 fixes this problem. Marking as duplicate.
*** This bug has been marked as a duplicate of bug 3023 ***
http://bugs.winehq.org/show_bug.cgi?id=10543
--- Comment #11 from Ben Pickhardt ben.pickhardt@gmail.com 2007-12-07 15:57:27 --- I tried the change from bug 3023 and I could indeed click on stuff on the menu. However once I played 1 game and exited back to the menu I was unable to select anything on the menu much like the bug that prevents full screen play. Is that related to this bug?
http://bugs.winehq.org/show_bug.cgi?id=10543
--- Comment #12 from Vincent Povirk madewokherd@gmail.com 2007-12-08 02:49:18 --- You're right. I neglected to test that.
It probably is related, but I won't have time to look into what's happening for a while.
http://bugs.winehq.org/show_bug.cgi?id=10543
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #13 from Austin English austinenglish@gmail.com 2008-10-29 14:18:11 --- Closing abandoned.
-
wine-bugs＠winehq.org