https://bugs.winehq.org/show_bug.cgi?id=42072
Bug ID: 42072 Summary: Dead Space (Steam) crashes on save with "divide by zero" error Product: Wine Version: 1.9.24 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: lmnet89@gmail.com Distribution: ---
Created attachment 56571 --> https://bugs.winehq.org/attachment.cgi?id=56571 Error backtrace for 1.9.24 version
Dead Space (Steam) always crashes on save. I tried 1.9.2, 1.9.20, 1.9.24, 1.7.55 versions: issue is 100% reproducible. Also, I tried to skip first save point and save on second save point, but it also lead game to crash.
Error is: Unhandled exception: divide by zero in 32-bit code (0x00900463).
I'm using Play on linux. Game is in separate clear x86 prefix. After creating prefix I have installed Steam through play on linux, and after that I installed Dead Space from the Steam menu.
I have backtraces for 1.7.55, 1.9.2 and 1.9.24. I attached backtrace file for 1.9.24 version.
https://bugs.winehq.org/show_bug.cgi?id=42072
--- Comment #1 from lmnet89@gmail.com --- Created attachment 56572 --> https://bugs.winehq.org/attachment.cgi?id=56572 Error backtrace for 1.9.2 version
https://bugs.winehq.org/show_bug.cgi?id=42072
--- Comment #2 from lmnet89@gmail.com --- Created attachment 56573 --> https://bugs.winehq.org/attachment.cgi?id=56573 Error backtrace for 1.7.55 version
https://bugs.winehq.org/show_bug.cgi?id=42072
lmnet89@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lmnet89@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=42072
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #3 from winetest@luukku.com --- Console output before the crash?
https://bugs.winehq.org/show_bug.cgi?id=42072
--- Comment #4 from lmnet89@gmail.com --- Created attachment 56575 --> https://bugs.winehq.org/attachment.cgi?id=56575 console output
Also, I checked x64 version with 1.9.24 version, and it crashed too.
https://bugs.winehq.org/show_bug.cgi?id=42072
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gyebro69@gmail.com
--- Comment #5 from Béla Gyebrószki gyebro69@gmail.com --- Created attachment 56576 --> https://bugs.winehq.org/attachment.cgi?id=56576 terminal output (2.0-rc3, Steam version)
I can reproduce this (Steam version), but my console output looks a bit more verbose. The same crash happens in Staging, too.
If you select an empty save slot when saving the game, then the game crashes. If you overwrite an existing save then it saves the game properly.
It could be a regression between 1.7.45 and 1.7.50. I will report back if I found something :)
https://bugs.winehq.org/show_bug.cgi?id=42072
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |erich.e.hoover@wine-staging | |.com
--- Comment #6 from Béla Gyebrószki gyebro69@gmail.com --- lmnet89,
Do you have the game installed on a different drive/partition than your /home (where My Documents is linked to by default in Wine?).
I don't know if it is indeed a regression or rather a bug in the game which was exposed by
commit f6c7e247add306e757c6b75e99dd23eba087f9f8 Author: Erich E. Hoover erich.e.hoover@wine-staging.com Date: Wed Jun 17 19:28:39 2015 -0600
kernel32: Implement GetVolumePathName.
The purpose of this function is to return the most fundamental path without leaving a filesystem. Steam uses this so that it can use inode searches, without this functionality some installations/validations will fail if the Steam Library is not on the same drive as Steam itself (symlink'd to another location).
I have Steam and the game installed on a different drive/partition (crash occurs). If I install the game in my /home partition then the crash doesn't occur.
Here's a forum post which describes a similar problem (see comment #6 in that post). http://www.gamespot.com/forums/pc-mac-linux-society-1000004/deadspace-crashe...
Other than that, there are several posts on Steam as well, interestingly all of them received 0 reply.
(a fresh one): https://steamcommunity.com/app/17470/discussions/0/152392786899542743/
some older posts: https://steamcommunity.com/app/17470/discussions/0/385429254939068923/ https://steamcommunity.com/app/17470/discussions/0/483367798510596867/ https://steamcommunity.com/app/17470/discussions/0/846961716344345274/
Let me know if you need debug logs.
https://bugs.winehq.org/show_bug.cgi?id=42072
--- Comment #7 from Béla Gyebrószki gyebro69@gmail.com --- Dead Space 3 (Origin version) also crashes with an 'Unhandled division by zero' error when starting a new game (after selecting a saved game slot). Existing saves (that were created before that commit) can be loaded and the game autosave feature works from then on. Now it's just Dead Space 2 that needs to be tested...
https://bugs.winehq.org/show_bug.cgi?id=42072
--- Comment #8 from Erich E. Hoover erich.e.hoover@wine-staging.com --- (In reply to Béla Gyebrószki from comment #7)
Dead Space 3 (Origin version) also crashes with an 'Unhandled division by zero' error when starting a new game (after selecting a saved game slot). Existing saves (that were created before that commit) can be loaded and the game autosave feature works from then on. Now it's just Dead Space 2 that needs to be tested...
If I understand you correctly, you are saying that this only happens when the game is on a different drive/partition from Steam and the same problem happens on Windows? If that is the case then this should be resolved as invalid. We could potentially build in a way to workaround the problem for this game, though AJ is not generally a huge fan of that.
https://bugs.winehq.org/show_bug.cgi?id=42072
--- Comment #9 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to Erich E. Hoover from comment #8)
(In reply to Béla Gyebrószki from comment #7)
Dead Space 3 (Origin version) also crashes with an 'Unhandled division by zero' error when starting a new game (after selecting a saved game slot). Existing saves (that were created before that commit) can be loaded and the game autosave feature works from then on. Now it's just Dead Space 2 that needs to be tested...
If I understand you correctly, you are saying that this only happens when the game is on a different drive/partition from Steam and the same problem happens on Windows? If that is the case then this should be resolved as invalid. We could potentially build in a way to workaround the problem for this game, though AJ is not generally a huge fan of that.
No. I meant both Steam and the game are installed in the same prefix, but they're located on a different drive than my /home. I don't have Windows to test the games.
https://bugs.winehq.org/show_bug.cgi?id=42072
--- Comment #10 from LMnet lmnet89@gmail.com --- (In reply to Béla Gyebrószki from comment #6)
lmnet89,
Do you have the game installed on a different drive/partition than your /home (where My Documents is linked to by default in Wine?).
I don't have any symlinks in the game path. Game is installed here: /home/lmnet/.PlayOnLinux/wineprefix/Dead_Space
https://bugs.winehq.org/show_bug.cgi?id=42072
--- Comment #11 from LMnet lmnet89@gmail.com --- I tried 1.7.45 version and all works fine.
https://bugs.winehq.org/show_bug.cgi?id=42072
--- Comment #12 from Erich E. Hoover erich.e.hoover@wine-staging.com --- (In reply to LMnet from comment #11)
I tried 1.7.45 version and all works fine.
Do you have the expertise to compile Wine yourself? If so then we can help you "revert" commit f6c7e247add306e757c6b75e99dd23eba087f9f8 and see if that fixes the problem for you (which can help us develop a solution).
https://bugs.winehq.org/show_bug.cgi?id=42072
--- Comment #13 from LMnet lmnet89@gmail.com --- (In reply to Erich E. Hoover from comment #12)
(In reply to LMnet from comment #11)
I tried 1.7.45 version and all works fine.
Do you have the expertise to compile Wine yourself? If so then we can help you "revert" commit f6c7e247add306e757c6b75e99dd23eba087f9f8 and see if that fixes the problem for you (which can help us develop a solution).
I never compile wine before and I'm not really familiar with linux native development tools. But if this process is relatively easy, I think can try.
https://bugs.winehq.org/show_bug.cgi?id=42072
noein93@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |noein93@gmail.com
--- Comment #14 from noein93@gmail.com --- I can confirm this bug. Wine 2.0-r1 (without staging patches) and GOG version of the game
https://bugs.winehq.org/show_bug.cgi?id=42072
--- Comment #15 from Béla Gyebrószki gyebro69@gmail.com --- Still present in Wine 2.10. Re-tested with the GOG.com version. Erich, is anything we can do to assist you in fixing this bug?
https://bugs.winehq.org/show_bug.cgi?id=42072
--- Comment #16 from Erich E. Hoover erich.e.hoover@wine-staging.com --- Created attachment 58582 --> https://bugs.winehq.org/attachment.cgi?id=58582 Revert GetVolumePathNameW to f6c7e247add306e757c6b75e99dd23eba087f9f8~
(In reply to Béla Gyebrószki from comment #15)
Still present in Wine 2.10. Re-tested with the GOG.com version. Erich, is anything we can do to assist you in fixing this bug?
Hi Béla, sorry I haven't replied to this earlier - my work is going through a big growth spurt and things are kinda crazy. I believe that the first step here is to revert the changes from f6c7e247add306e757c6b75e99dd23eba087f9f8 against latest git and re-compile wine to ensure that this issue is confined exclusively to the changes I made in GetVolumePathName. I've attached a patch to do this, for your convenience.
I assume that this will "fix" the problem both for you and for LMnet, so the next step would be to get a relay log from both the reverted version and non-reverted version to compare the two. Applications that use GetVolumePathName will use different routines depending on what they get out of GetVolumePathName, so we need to figure out what routine is getting called so that we can estabish why it is failing.
https://bugs.winehq.org/show_bug.cgi?id=42072
--- Comment #17 from Béla Gyebrószki gyebro69@gmail.com --- Created attachment 58583 --> https://bugs.winehq.org/attachment.cgi?id=58583 +relay,+seh,tid log with the patch reverted (uncompressed 134 M)
Erich, thank you for taking your precious time to look at this bug again. I tried the revert patch and can confirm that the game doesn't crash.
I used WINEDEBUG=+relay,+seh,+tid when creating a debug log, is that OK? I also added wined3d.* to the RelayExclude registry key which reduced the size of the log considerably.
This is the relay log with the reverted patch.
https://bugs.winehq.org/show_bug.cgi?id=42072
--- Comment #18 from Béla Gyebrószki gyebro69@gmail.com --- Created attachment 58584 --> https://bugs.winehq.org/attachment.cgi?id=58584 +relay,+seh,+tid log vanilla Wine (uncompressed 122 M)
This is the relay log with non-patched wine-2.11-114-g6ec3cd9434 (the game crashes on save).
https://bugs.winehq.org/show_bug.cgi?id=42072
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
https://bugs.winehq.org/show_bug.cgi?id=42072
Shiro Hara white@vx-xv.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |white@vx-xv.com
--- Comment #19 from Shiro Hara white@vx-xv.com --- I met same bug with GOG version and wine 2.20 and playonlinux 4.2.12. And now I have found a workaround for me.
The workaround is following step: 1.Open wine configure(winecfg) window in playonlinux. 2.Choose desktop integration tab. 3.Select My Documents in the Folder box. 4.Uncheck the box before link. And see the value is cleared.(Default value is /home/username/Documents) 5.Push OK button for closing the wincfg. 6.Start the new game and now I can use the first save point. The save files are in the drive_c/users/username/My Documents.
https://bugs.winehq.org/show_bug.cgi?id=42072
Cláudio Sampaio (Patola) patola@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |patola@gmail.com
--- Comment #20 from Cláudio Sampaio (Patola) patola@gmail.com --- Happens with me too. Tried with wine 3.2 and wine-staging 2.21, both 64 bits.
https://bugs.winehq.org/show_bug.cgi?id=42072
Zachary J zakarjor@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zakarjor@yahoo.com
--- Comment #21 from Zachary J zakarjor@yahoo.com --- I've encountered this issue and I always use symlink to My\ Documents (I keep drive_c in a separate partition).
Debug log clearly shows Dead Space only gives 16 bytes for output, which is not enough for normal unix pathnames:
003c:trace:volume:GetVolumePathNameW (L"c:\users\USERNAME\My Documents\Electronic Arts\Dead Space", 0x1346fcd8, 16)
I patched wine-4.21/dlls/kernel32/volume.c GetVolumePathNameW() by changing 2 lines so that in case last_pos+1>buflen, just revert to default drive letter or something rather than failing:
L1808: if (status!=STATUS_SUCCESS || last_pos+1>buflen) L1813: if (status!=STATUS_SUCCESS && filename[0]=='\' && strncmpW(.)!=0)
This should at least retain the original logic for other cases.
https://bugs.winehq.org/show_bug.cgi?id=42072
--- Comment #22 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Zachary J from comment #21)
I've encountered this issue and I always use symlink to My\ Documents (I keep drive_c in a separate partition).
Yeah, when we first looking at this we were only thinking about symlinks within the prefix and forgetting that there are some symlinks that point to directories outside the prefix.
Debug log clearly shows Dead Space only gives 16 bytes for output, which is not enough for normal unix pathnames:
If you put your "My Documents" folder on another drive using an NT symlink then this problem would happen on Windows too, it's just an unusual situation.
... I patched wine-4.21/dlls/kernel32/volume.c GetVolumePathNameW() by changing 2 lines so that in case last_pos+1>buflen, just revert to default drive letter or something rather than failing: ...
Would you mind attaching your patch? Even though it's not ideal it might be possible to get it considered after the code freeze. In fact, I think that we can _technically_ report the drive letter of the destination volume based on the documentation on Junction Points at MSDN ( https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getvol... ).
https://bugs.winehq.org/show_bug.cgi?id=42072
--- Comment #23 from Zachary J zakarjor@yahoo.com --- Sorry for the late reply. My patch was an ugly hack not worth sharing. But I found that in wine 5.5 the issue seems to have been resolved.
I can confirm that saving game does not crash in wine 5.5.
https://bugs.winehq.org/show_bug.cgi?id=42072
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |9b80443a8ff67523f0c2d8ba117 | |79523a5fa3cec Component|-unknown |kernel32 Status|UNCONFIRMED |RESOLVED
--- Comment #24 from Béla Gyebrószki gyebro69@gmail.com --- Fixed by https://source.winehq.org/git/wine.git/commit/9b80443a8ff67523f0c2d8ba117795...
https://bugs.winehq.org/show_bug.cgi?id=42072
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #25 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 5.6.