https://bugs.winehq.org/show_bug.cgi?id=38165
Bug ID: 38165 Summary: F.E.A.R 1 freezing in the menu (network related) Product: Wine Version: 1.7.37 Hardware: x86 URL: http://www.gamershell.com/download_10167.shtml OS: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: winsock Assignee: wine-bugs@winehq.org Reporter: gyebro69@gmail.com Distribution: ---
Created attachment 50913 --> https://bugs.winehq.org/attachment.cgi?id=50913 plain terminal output
This bug is present in the Steam, GOG as well as in the single-player demo versions. As far as I remember there was no such problem with FEAR 1 before May 2014 when the Gamespy servers were shut down. It's not a regression in Wine.
To reproduce the problem install then start the single-player demo. The intro movies should play properly. When you get to the main menu and move the mouse pointer over a menu item, the game hangs up.
If I disable network connections in Linux so only the loopback device is present, then the problem doesn't occur. The problem doesn't exist if I use native ws2_32.dll + ws2help.dll (copied from a Windows Xp running in a VM).
I started wireshark and noticed that 2 DNS queries were made: fearsp.available.gamespy.com and motd.gamespy.com
Maybe the response from these servers (or the lack of response since they were shut down in 2014) doesn't make Wine happy thus it's freezing (?)
Note: the issue often leads to a situation where the player profile gets corrupted and you receive a crash on start, involving gamedatabase.dll in the backtrace. If this occurs remove Profile000.gdb from 'drive_c/users/Public/Documents/Monolith Productions/FEARSPDemo/Profiles' directory.
Fedora 21 x86 wine-1.7.37-143-g3b2cf06
fear_spdemo_en.exe md5sum: 300b1ea76b7c840f05408e92ea896ee1
https://bugs.winehq.org/show_bug.cgi?id=38165
--- Comment #1 from Béla Gyebrószki gyebro69@gmail.com --- Created attachment 50914 --> https://bugs.winehq.org/attachment.cgi?id=50914 +winsock log
https://bugs.winehq.org/show_bug.cgi?id=38165
--- Comment #2 from Bruno Jesus 00cpxxx@gmail.com --- I can see it, the application quits waiting for a response from the server and calls closesocket, then it tries once more to poll the socket using select(). Obviously select returns error because the socket no longer exists. Then the application calls closesocket again, and select again... Forever. The simplest hack possible is to block UDP socket creation (or all socket creation).
https://bugs.winehq.org/show_bug.cgi?id=38165
--- Comment #3 from Bruno Jesus 00cpxxx@gmail.com --- For me this is fixed by http://source.winehq.org/git/wine.git/?a=commit;h=bf36fb02165db67a35ccd3f3c5...
Can you please retest?
https://bugs.winehq.org/show_bug.cgi?id=38165
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |bf36fb02165db67a35ccd3f3c55 | |f5b605a780221 Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #4 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to Bruno Jesus from comment #3)
For me this is fixed by http://source.winehq.org/git/wine.git/?a=commit; h=bf36fb02165db67a35ccd3f3c55f5b605a780221
Can you please retest?
Fixed for me as well, tested with the GOG version. Thanks Bruno for taking the time to fix this.
https://bugs.winehq.org/show_bug.cgi?id=38165
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #5 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.7.38.
-
wine-bugs＠winehq.org