http://bugs.winehq.org/show_bug.cgi?id=22291
Summary: Multiple apps: hanged after quitting Product: Wine Version: 1.1.42 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: grip2die@yahoo.com
After closing DC++ v0.761 the app executable remains memory rsident toghether with: services.exe explorer.exe wineserver etc
Not only the DC++ doesn't terminate normally and remains in memory, but also the zombie process (or the processes associated with it) use 10-20% CPU.
Similar behav for other apps (they don't terminate after closing them).
http://bugs.winehq.org/show_bug.cgi?id=22291
--- Comment #1 from Austin English austinenglish@gmail.com 2010-04-06 13:30:03 --- Do you have any other applications running in that WINEPREFIX? That behavior is normal, as long as a single application is running.
http://bugs.winehq.org/show_bug.cgi?id=22291
Andrei grip2die@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Multiple apps: hanged after |Trying to normally close an |quitting |app makes it freez and | |therefore must be killed | |because it consumes CPU and | |mem Alias| |closingAppsFails
http://bugs.winehq.org/show_bug.cgi?id=22291
--- Comment #2 from Andrei grip2die@yahoo.com 2010-04-06 17:03:05 --- Created an attachment (id=27249) --> (http://bugs.winehq.org/attachment.cgi?id=27249) After closing DC++ it freezes like this
This is a screenshot of the zombie processes left behind after closing DC++
http://bugs.winehq.org/show_bug.cgi?id=22291
--- Comment #3 from Andrei grip2die@yahoo.com 2010-04-06 17:08:35 --- (In reply to comment #1)
Do you have any other applications running in that WINEPREFIX? That behavior is normal, as long as a single application is running.
Please let me give you more details:
After installing OpenSUSE 11.2 (64 bit), I upgraded wine to 1.1.42.
I installed DC++ (through a NullSoft Installer) and the installation went ok. There were no zombies after the installer has closed.
After that, I launched the DC++ through the newly created link provided in my KDE Start Menu (Wine folder).
The problem is that when I closed the DC++ in the normal fashion, it became unresponsive. The DC++ system tray icon remained visible but the whole app was frozen.
I don't think that this is a normal behaviour and it appears solved in some releases of Wine 1.1.x just to reappear in other releases. As this is an old problem I decided to submit this bug.
http://bugs.winehq.org/show_bug.cgi?id=22291
--- Comment #4 from Andrei grip2die@yahoo.com 2010-04-06 17:17:20 --- Created an attachment (id=27250) --> (http://bugs.winehq.org/attachment.cgi?id=27250) Same problem for StrongDC
I've managed to reproduce this bug on another app (StrongDC)
http://bugs.winehq.org/show_bug.cgi?id=22291
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Trying to normally close an |DC++ hangs on exit |app makes it freez and | |therefore must be killed | |because it consumes CPU and | |mem | Alias|closingAppsFails |
--- Comment #5 from Juan Lang juan_lang@yahoo.com 2010-04-06 18:19:54 --- (In reply to comment #4)
I've managed to reproduce this bug on another app (StrongDC)
No you haven't, DC++ is also in this list, so this is just another instance of DC++ hanging.
Is this the app? http://dcplusplus.sourceforge.net/download.html
Which version of it are you running?
http://bugs.winehq.org/show_bug.cgi?id=22291
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |minor
--- Comment #6 from Vitaliy Margolen vitaliy@kievinfo.com 2010-04-07 08:28:02 --- http://bugs.winehq.org/page.cgi?id=fields.html#bug_severity
http://bugs.winehq.org/show_bug.cgi?id=22291
--- Comment #7 from Andrei grip2die@yahoo.com 2010-04-07 08:34:03 --- (In reply to comment #5)
(In reply to comment #4)
I've managed to reproduce this bug on another app (StrongDC)
No you haven't, DC++ is also in this list, so this is just another instance of DC++ hanging.
Is this the app? http://dcplusplus.sourceforge.net/download.html
Which version of it are you running?
1. As a matter of fact this bug affects at least two apps: DC++ StrongDC
2. Yes, the first app that hanged is DC++ v0.761 (downloaded from http://dcplusplus.sourceforge.net/download.html)
http://bugs.winehq.org/show_bug.cgi?id=22291
--- Comment #8 from Juan Lang juan_lang@yahoo.com 2010-04-07 10:14:37 --- (In reply to comment #7)
- As a matter of fact this bug affects at least two apps: DC++ StrongDC
Look at your screenshot again. DC++ is running. As long as DC++ is running, wineserver, services, explorer will never quit.
Anyway, what about console output?
http://bugs.winehq.org/show_bug.cgi?id=22291
--- Comment #9 from Andrei grip2die@yahoo.com 2010-04-07 16:45:06 --- (In reply to comment #8)
(In reply to comment #7)
- As a matter of fact this bug affects at least two apps: DC++ StrongDC
Look at your screenshot again. DC++ is running. As long as DC++ is running, wineserver, services, explorer will never quit.
Anyway, what about console output?
Exactly that's the problem: DC++ wasn't supposed to be running anymore (I quit it but it froze) same thing with StrongDC
I'll try to reproduce this bug with some other app and will run it from a console to paste here the output.
http://bugs.winehq.org/show_bug.cgi?id=22291
--- Comment #10 from Andrei grip2die@yahoo.com 2010-04-07 17:15:51 --- Created an attachment (id=27268) --> (http://bugs.winehq.org/attachment.cgi?id=27268) DC++ hanging after closing
http://bugs.winehq.org/show_bug.cgi?id=22291
--- Comment #11 from Andrei grip2die@yahoo.com 2010-04-07 17:16:35 --- Created an attachment (id=27269) --> (http://bugs.winehq.org/attachment.cgi?id=27269) wine error output (console)
http://bugs.winehq.org/show_bug.cgi?id=22291
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #27269|application/octet-stream |text/plain mime type| |
http://bugs.winehq.org/show_bug.cgi?id=22291
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wylda@volny.cz
--- Comment #12 from Wylda wylda@volny.cz 2010-04-09 10:54:18 ---
Testing is pretty simple. Download is small (tiny) and when you run StrongDC++, it asks you for some connection parameters. Press ESC (skip it for now), than menu "File" -> "Exit". Hangs forever.
1. Confirming, please consider UNCONFIRMED->NEW and KEYWORDS: +REGRESSION, +DOWNLOAD, +SOURCE
2. I did a regression test between 1.1.26 and 1.1.27:
commit d8f962e69cb92e4a6cc438394cff42779621af16 Author: Rein Klazes wijn@online.nl Date: Fri Jul 24 10:29:17 2009 +0200
ws2_32: Do not make the unix file descriptor blocking. Too many places in the socket code assume it is not.
:040000 040000 ce44652e53db8610923cde1c38d458a1de32efad 1d186f8f7298f60a632ed5000bb3229c56f413c3 M dlls
3. No other bug report suffers from this commit.
4. Revert of this patch on top of wine-1.1.42-146-g1c02a90 makes that problem go away.
5. Adding author of this patch to CC.
--private keyword: bisected
PS: Andrei, if you want, you can take a look how to fill in a bug report for next time;) Anyway thank you for your submission.
http://bugs.winehq.org/show_bug.cgi?id=22291
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wijn@online.nl
http://bugs.winehq.org/show_bug.cgi?id=22291
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, regression, | |source Status|UNCONFIRMED |NEW URL| |http://strongdc.sourceforge | |.net/index.php?lang=eng Ever Confirmed|0 |1
--- Comment #13 from Austin English austinenglish@gmail.com 2010-04-09 11:59:16 --- Confirming.
http://bugs.winehq.org/show_bug.cgi?id=22291
--- Comment #14 from Wylda wylda@volny.cz 2010-04-17 17:10:57 ---
This regression (bisected) is still present in wine-1.1.43.
http://bugs.winehq.org/show_bug.cgi?id=22291
Mike Kaplinskiy mike.kaplinskiy@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mike.kaplinskiy@gmail.com
--- Comment #15 from Mike Kaplinskiy mike.kaplinskiy@gmail.com 2010-05-22 16:36:06 --- Could someone post a +winsock debug log? That commit shouldn't break anything unless the app depends on errors.
http://bugs.winehq.org/show_bug.cgi?id=22291
--- Comment #16 from Wylda wylda@volny.cz 2010-05-28 14:28:44 --- Created an attachment (id=28360) --> (http://bugs.winehq.org/attachment.cgi?id=28360) console log from wine-1.2-rc2 +winsock
(In reply to comment #15)
Could someone post a +winsock debug log? That commit shouldn't break anything unless the app depends on errors.
Hi Mike, here you are.
http://bugs.winehq.org/show_bug.cgi?id=22291
--- Comment #17 from Mike Kaplinskiy mike.kaplinskiy@gmail.com 2010-05-28 18:16:24 --- Looks like a blocked WSARecvFrom is not woken up by the socket's shutdown/close:
trace:winsock:WS_socket af=2 type=2 protocol=17 trace:winsock:WSASocketA af=2 type=2 protocol=17 protocol_info=(nil) group=0 flags=0x1 trace:winsock:WSASocketW af=2 type=2 protocol=17 protocol_info=(nil) group=0 flags=0x1 trace:winsock:WS_select read 0xfde8a0, write (nil), excp (nil) timeout 0xfde660 trace:winsock:WSASocketW created 0080 trace:winsock:WS_ioctlsocket socket 0080, cmd 8004667e, ptr 0x33e664 trace:winsock:WS_ioctlsocket socket 0080, cmd 8004667e, ptr 0x33e678 trace:winsock:WS_setsockopt socket: 0080, level 0xffff, name 0x1002, ptr 0x33e664, len 4 trace:winsock:WS_bind socket 0080, ptr 0x33e638 { family AF_INET, address 0.0.0.0, port 0 }, length 16 trace:winsock:WS_getsockname socket: 0080, ptr 0x33e638, len 10 trace:winsock:DllMain 0x7ee40000 0x2 (nil) trace:winsock:WSARecvFrom socket 0080, wsabuf 0x10de954, nbufs 1, flags 0, from 0x10de998, fromlen 16, ovl (nil), func (nil) trace:winsock:WSARecvFrom fd=47, options=0
....
trace:winsock:WS_shutdown socket 0080, how 2 0 trace:winsock:WS2_register_async_shutdown s 128 type 1 trace:winsock:WS2_register_async_shutdown s 128 type 2 trace:winsock:DllMain 0x7ee40000 0x3 (nil) trace:winsock:WSAAsyncSelect 80, hWnd (nil), uMsg 00000000, event 00000000 trace:winsock:WS_closesocket socket 0080
I have absolutely no idea how making the actual socket blocking affects shutdown behavior. This is a UDP socket though, so it might. Something like the below might help:
diff --git a/server/sock.c b/server/sock.c index b75c5a6..9aa927d 100644 --- a/server/sock.c +++ b/server/sock.c @@ -621,6 +621,7 @@ static void sock_destroy( struct object *obj ) if (sock->fd) { /* shut the socket down to force pending poll() calls in the client to return */ + fcntl(get_unix_fd(sock->fd), F_SETFL, fcntl(get_unix_fd(sock->fd), F_GETFL, 0) & ~O_NONBLOCK); shutdown( get_unix_fd(sock->fd), SHUT_RDWR ); release_object( sock->fd ); }
http://bugs.winehq.org/show_bug.cgi?id=22291
--- Comment #18 from Wylda wylda@volny.cz 2010-05-29 00:02:45 --- Created an attachment (id=28365) --> (http://bugs.winehq.org/attachment.cgi?id=28365) Patch for wine-1.2-rc2
I have absolutely no idea how making the actual socket blocking affects shutdown behavior. This is a UDP socket though, so it might. Something like the below might help:
Yes it works and now wine doesn't hang on exit, but cleanly exits. The patch was mangled, so adding as attachment + adjusting for 1.2-rc2.
BTW: StrongDC++ is available under GPLv2, so if you want to have a look what's inside.
http://bugs.winehq.org/show_bug.cgi?id=22291
--- Comment #19 from Mike Kaplinskiy mike.kaplinskiy@gmail.com 2010-06-04 22:06:12 --- Created an attachment (id=28568) --> (http://bugs.winehq.org/attachment.cgi?id=28568) Proper patch for git
Here's a proper patch that should fix all shutdown-cancels-blocking-call bugs introduced by the commit.
I think this should wait for post-1.2, since the fix is racy and can cause some really bad things to happen (hanging wineserver, hanging apps for no apparent reason). The proper fix would be to move polling to the wineserver, which may not be soon.
Any app that depends on close behavior like this needs to be rewritten if possible, ala https://bugzilla.kernel.org/show_bug.cgi?id=546
http://bugs.winehq.org/show_bug.cgi?id=22291
--- Comment #20 from Wylda wylda@volny.cz 2010-06-20 11:12:25 ---
This regression (bisected) is still present in wine-1.2-rc4.
http://bugs.winehq.org/show_bug.cgi?id=22291
--- Comment #21 from Andrei grip2die@yahoo.com 2010-11-17 03:56:58 CST --- (In reply to comment #20)
This regression (bisected) is still present in wine-1.2-rc4.
This bug was reported 7 months ago.
Unfortunately DC++, StronDC, ODC still won't exit normally. They remain hanged, draining the CPU. They must be killed.
http://bugs.winehq.org/show_bug.cgi?id=22291
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de Regression SHA1| |d8f962e69cb92e4a6cc438394cf | |f42779621af16
http://bugs.winehq.org/show_bug.cgi?id=22291
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
--- Comment #22 from Bruno Jesus 00cpxxx@gmail.com 2011-09-14 21:36:58 CDT --- I've tested in latest git and it seems to be working, the application is closed and the console is released.
Can anyone else retest?
http://bugs.winehq.org/show_bug.cgi?id=22291
--- Comment #23 from Austin English austinenglish@gmail.com 2011-11-02 20:52:17 CDT --- (In reply to comment #22)
I've tested in latest git and it seems to be working, the application is closed and the console is released.
Can anyone else retest?
I still get this behavior in wine-1.3.31-293-gb4987d0.
http://bugs.winehq.org/show_bug.cgi?id=22291
--- Comment #24 from Wylda wylda@volny.cz 2011-12-03 00:38:43 CST ---
This regression (bisected) is still present in wine-1.3.34.
use 10-20% CPU.
In my case, after choosing exit "StrongDC.exe + wineserver" use 100% CPU.
http://bugs.winehq.org/show_bug.cgi?id=22291
--- Comment #25 from Wylda wylda@volny.cz 2012-05-13 09:09:33 CDT ---
This regression (bisected) is still present in wine-1.5.4.
Under wine-1.5.4, cleanly applied Mike Kaplinskiy's patch from: * Comment 18 works * Comment 19 does not work
http://bugs.winehq.org/show_bug.cgi?id=22291
Marcus Blumhagen marcus.blumhagen@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |marcus.blumhagen@web.de
--- Comment #26 from Marcus Blumhagen marcus.blumhagen@web.de 2012-06-28 05:25:54 CDT --- Hi,
I found this after bisecting to find the exact same commit to be responsible for what I consider a major loss of funconality in the Rise of Flight dedicated server:
http://appdb.winehq.org/objectManager.php?sClass=application&iId=10553 http://en.wiki.riseofflight.com/index.php?title=Dedicated_server
So first I would like to ask that it gets added to the list of affected applications.
And I think the severity should be raised to normal, because Rise of Flight´s DServer.exe crashes not only on shutdown but also on mission skip or closing a server instance via the menu or opening another server description file (while the server is running, that is another server desc. is already opened and will be closed) to run a different mission set. So there is a great deal of functionality lost, because we could only run one single mission and as soon as it is finished the server would automatically skip to the next one and hang itself in the process.
I can also confirm that the patch from comment 18 works, applied to wine-1.4.1 from the stable branch of the git repository, whereas the one from comment 19 applies fine but the problem persists. The same is true for the latest HEAD (as of now 4a367c57197b93a01c66d167db20420134e1f52c) of the master branch.
As for rewriting the affected application, I will try my best to convince the developers to do so. But I don´t think it is the proper solution either, because DServer.exe of Rise of Flight runs just fine in MS Windows and so should it under WINE, at least I thought that´s how it is supposed to be:
http://wiki.winehq.org/ImportanceOfWine
Anyway, thanks for your time and consideration and for WINE, without I would need to run Windows on our server, yikes. ;)
Kind regards Marcus
http://bugs.winehq.org/show_bug.cgi?id=22291
--- Comment #27 from André H. nerv@dawncrow.de 2012-06-28 12:15:21 CDT --- (In reply to comment #26)
Hi,
I found this after bisecting to find the exact same commit to be responsible for what I consider a major loss of funconality in the Rise of Flight dedicated server:
http://appdb.winehq.org/objectManager.php?sClass=application&iId=10553 http://en.wiki.riseofflight.com/index.php?title=Dedicated_server
So first I would like to ask that it gets added to the list of affected applications.
done, pending
As for rewriting the affected application, I will try my best to convince the developers to do so. But I don´t think it is the proper solution either, because DServer.exe of Rise of Flight runs just fine in MS Windows and so should it under WINE, at least I thought that´s how it is supposed to be:
Don't ask the developer to rewrite it, you are right, wine should simply run it and this bug needs to be fixed, further we need the actual version for testing to see if it works when the bug is fixed.
http://bugs.winehq.org/show_bug.cgi?id=22291
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|minor |normal
http://bugs.winehq.org/show_bug.cgi?id=22291
--- Comment #28 from Marcus Blumhagen marcus.blumhagen@web.de 2012-06-29 12:54:56 CDT --- (In reply to comment #27)
(In reply to comment #26)
So first I would like to ask that it gets added to the list of affected applications.
done, pending
Thanks!
Don't ask the developer to rewrite it, you are right, wine should simply run it and this bug needs to be fixed, further we need the actual version for testing to see if it works when the bug is fixed.
Alright, here is how you get it (but to actually reproduce the bug one needs to create an account, I´m afraid, but it´s free and a throw away email address can be used for that, should you have inhibitions about providing personal data):
1. Download http://www.riseofflightdemo.com/ROF_Demo/ROF_ICE_Unlimited_Demo_1021b.exe
Don´t (!) download the ROF_Free2Play_Client_1025b.zip as is actually recommended, since at least I couldn´t unzip it properly (seems to be a corrupted archive), and because that download is a massive 4.4 GB, that can be quite frustrating. So I used the 1021b version and ran the updater, see below.
2. Create an account
http://riseofflight.com/en/profile/registration
3. Upon arrival of the confirmation email, follow the included activation link and enter the key for the free version:
77777-77777-77777-77777-77771
4. Run ROF_ICE_Unlimited_Demo_1021b.exe once, which will 1st unpack its contents to $PWD/temp_RoF (which will not be automatically removed (!) but can come in quite handy for reinstallation) and run the setup.exe in there. When aksed what else to install after the actual installation is done uncheck everything except "Install MS VC++ 2005 Reditributable".
5. Run rof_updater.exe, which by default is located in $WINEPREFIX/drive_c/Program\ Files/777/Rise\ of\ Flight/bin_game/release, and let it do its thing. After the update is done it will automatically run the DirectX setup, abort that and ignore the warning/error message of rof_updater.exe about an unsuccessful update (the actual game content will have been updated properly).
6. Take one of the template dedicated*.sds files inside Path/to/Program\ Files/777/Rise of Flight/data and edit it, you only need to change the "login" and "password" variables to reflect the email address and password used in step 2.
7. cd to /Path/to/Program\ Files/777/Rise of Flight/bin_game/release and run DServer.exe, optionally you can provide the path to the .sds file as an argument or just open it from the DServer.exe window.
Look for "... Mission loaded successfully" and check the player list in the top right corner to see a spectator with a ping. The server is running now and you can reproduce the bug by either opening or closing a .sds file from the menu or by just exiting or closing the window. The last output on the console will show :
[...] Client #0: Send disconnect Client #0: Send disconnect Server: Client 0 is disconnected
Note: unless you have actually run the game client (ROF.exe) and activated your account from within the game itself you will see an error message just after "... Mission loaded successfully" saying something like "... MIST_SERVERREGISTERONPROXY" and "Unable to check client profile ban". You can ignore that. The bug will be observeable nontheless.
Now running the patched version of wine-1.4.1 (the patch from comment 18) the console output will look like this after clicking close:
[...] Client #0: Send disconnect Server: Client 0 is disconnected [server] stop [acceptor] failed to accept connection url: https://fokker.neoqb.com:443/HttpFrontend/AsyncFrontendHandler.ashx <some more output seemingly from libcurl> [...]
and the program will stay responsive and one can open another .sds file or whatever you like.
http://bugs.winehq.org/show_bug.cgi?id=22291
--- Comment #29 from Marcus Blumhagen marcus.blumhagen@web.de 2012-06-29 15:34:15 CDT --- One addition, since I just noticed it. With wine-1.1.26 the exit code of
$ wine DServer.exe
is 0, when one clicks the X (close window) button whereas with the patched version of 1.4.1 it is 96. When one closes by clicking File->Exit it is 5 with both versions.
I don´t know whether it is the exit code of wine or passed on by the application though. Thought I mention it, in case it is of relevance.
http://bugs.winehq.org/show_bug.cgi?id=22291
--- Comment #30 from Bruno Jesus 00cpxxx@gmail.com 2013-03-25 14:48:03 CDT --- This bug may have been fixed by http://source.winehq.org/git/wine.git/?a=commit;h=c09c82b25a3c95e79f23f22571...
http://bugs.winehq.org/show_bug.cgi?id=22291
Frédéric Delanoy frederic.delanoy@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |frederic.delanoy@gmail.com Resolution| |FIXED
--- Comment #31 from Frédéric Delanoy frederic.delanoy@gmail.com 2013-06-22 05:31:43 CDT --- Works with wine-1.6-rc3
Feel free to reopen if the problem persists for you.
http://bugs.winehq.org/show_bug.cgi?id=22291
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #32 from Alexandre Julliard julliard@winehq.org 2013-06-28 15:03:58 CDT --- Closing bugs fixed in 1.6-rc4.