https://bugs.winehq.org/show_bug.cgi?id=48180
Bug ID: 48180 Summary: Divinity: Original Sin 2 - Icons in inventory are invisible Product: Wine Version: 4.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: apmichalopoulos@outlook.com Distribution: ---
Created attachment 65815 --> https://bugs.winehq.org/attachment.cgi?id=65815 Game running inside a clean 4.19 prefix
As per title, after upgrading to Wine 4.20, the game's inventory icons are completely invisible. Everything else, including all other icons (in hotbars, in portraits, while dragging and dropping, in containers or while trading with vendors, etc), works like a charm.
Downgrading to 4.19 fixes the issue. Also, I don't know what the policy about mentioning wine-staging is in this bug tracker, but I tested with it as well and it also works in 4.19 while it breaks in 4.20, so this seems to be a mainstream Wine bug.
https://bugs.winehq.org/show_bug.cgi?id=48180
--- Comment #1 from Nocifer apmichalopoulos@outlook.com --- Created attachment 65816 --> https://bugs.winehq.org/attachment.cgi?id=65816 Game running inside a clean 4.20 prefix
https://bugs.winehq.org/show_bug.cgi?id=48180
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp@gmail.com
--- Comment #2 from Paul Gofman gofmanp@gmail.com --- It is d3d11 game, right?
Could you please attach logs with WINEDEBUG=+d3d11,+d3d,+d3d_shader? Recorded from start and including the moment the inventory with the problem are visible. The log may grow big but logs are compressed very well. Ideally, 2 logs, with 4.20 where the issue is and 4.19 where there is no issue.
Or maybe you could do a bisect and find the commit which caused the regression? That would simplify the things greatly and would increase the chances for this to be fixed quick.
https://bugs.winehq.org/show_bug.cgi?id=48180
--- Comment #3 from Nocifer apmichalopoulos@outlook.com --- Heh, I was already in the process of doing a bisect :)
The result:
0e183cc3c0d3b6f89f79047cdd71c389afc75073 is the first bad commit commit 0e183cc3c0d3b6f89f79047cdd71c389afc75073 Author: Alexandre Julliard julliard@winehq.org Date: Sat Nov 2 14:35:52 2019 +0100
msvcrt: Don't change FPU control word in _control87() on x86-64.
If debug logs are still needed I can provide them as well.
https://bugs.winehq.org/show_bug.cgi?id=48180
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Regression SHA1| |0e183cc3c0d3b6f89f79047cdd7 | |1c389afc75073
https://bugs.winehq.org/show_bug.cgi?id=48180
--- Comment #4 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- (In reply to Nocifer from comment #3)
Heh, I was already in the process of doing a bisect :)
The result:
0e183cc3c0d3b6f89f79047cdd71c389afc75073 is the first bad commit commit 0e183cc3c0d3b6f89f79047cdd71c389afc75073 Author: Alexandre Julliard julliard@winehq.org Date: Sat Nov 2 14:35:52 2019 +0100
msvcrt: Don't change FPU control word in _control87() on x86-64.
Duplicate of https://bugs.winehq.org/show_bug.cgi?id=48160
https://bugs.winehq.org/show_bug.cgi?id=48180
--- Comment #5 from Alexander Milos apmichalopoulos@outlook.com --- This bug has been marked as a duplicate of https://bugs.winehq.org/show_bug.cgi?id=48160, but while that other bug has recently been closed as fixed, this one is still present in the latest master. I will provide some trace logs in the hope of this being investigated and fixed as well.
Due to the trace logs being (much) larger than the 10MB attachment limit, I've uploaded them to a (randomly chosen by googling) third party host. If there is an official policy or even a suggestion about using a different third party host, please advise me so.
1) Trace log of the game running inside a clean prefix using latest master with WINEDEBUG=+msvcrt,+ntdll
2) Trace log of the game running inside a clean prefix using latest master with WINEDEBUG=+d3d,+d3d11,+d3dshader
https://bugs.winehq.org/show_bug.cgi?id=48180
Alexander Milos apmichalopoulos@outlook.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|4.20 |5.0-rc1 Distribution|--- |ArchLinux
https://bugs.winehq.org/show_bug.cgi?id=48180
Alexander Milos apmichalopoulos@outlook.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Divinity: Original Sin 2 - |Divinity: Original Sin 2 - |Icons in inventory are |Icons in inventory are |invisible |invisible - bisecting | |reports that commit | |0e183cc3c0d3b6f89f79047cdd7 | |1c389afc75073 "msvcrt: | |Don't change FPU control | |word in _control87() on | |x86-64." is the first bad | |commit
https://bugs.winehq.org/show_bug.cgi?id=48180
Alexander Milos apmichalopoulos@outlook.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Divinity: Original Sin 2 - |Divinity: Original Sin 2 - |Icons in inventory are |Icons in inventory are |invisible - bisecting |invisible - |reports that commit |0e183cc3c0d3b6f89f79047cdd7 |0e183cc3c0d3b6f89f79047cdd7 |1c389afc75073 "msvcrt: |1c389afc75073 "msvcrt: |Don't change FPU control |Don't change FPU control |word in _control87() on |word in _control87() on |x86-64." is the first bad |x86-64." is the first bad |commit |commit |
https://bugs.winehq.org/show_bug.cgi?id=48180
Erich E. Hoover erich.e.hoover@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |erich.e.hoover@gmail.com
--- Comment #6 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Alexander Milos from comment #5)
... Due to the trace logs being (much) larger than the 10MB attachment limit, I've uploaded them to a (randomly chosen by googling) third party host. If there is an official policy or even a suggestion about using a different third party host, please advise me so.
Not really, people generally use whatever they're most comfortable with.
- Trace log of the game running inside a clean prefix using latest master
with WINEDEBUG=+msvcrt,+ntdll
The only impacted routine I see in this log is MSVCRT_vsnscanf_s_l, but it appears that all the numbers that it is decoding are within the range of values that it would not be a problem. I did miss another possibility, which is that "webservices" has a bunch of WsRead* routines that could be impacted. A log with just "+webservices" would be useful.
- Trace log of the game running inside a clean prefix using latest master
with WINEDEBUG=+d3d,+d3d11,+d3dshader
The obvious d3d routines that touch the x87 FPU are: 1) d3d8_CreateDevice (d3d8) 2) d3d9_CreateDevice[Ex] (d3d9) 3) d3d_device7_*_FPUPreserve (ddraw) Though I have not done an exhaustive search.
I would be surprised if your application uses any of these, but it would be a good idea to check. The easiest way to do that would probably be something like this: WINEDEBUG="+d3d8,+d3d9,+ddraw" app.exe 2>&1 | grep -e '_CreateDevice' -e '_FPUPreserve'
What might be the case is that initializing d3d11 configures the x87 FPU, but that will be harder to figure out...
https://bugs.winehq.org/show_bug.cgi?id=48180
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Divinity: Original Sin 2 - |Divinity: Original Sin 2 - |Icons in inventory are |Icons in inventory are |invisible - |invisible |0e183cc3c0d3b6f89f79047cdd7 | |1c389afc75073 "msvcrt: | |Don't change FPU control | |word in _control87() on | |x86-64." is the first bad | |commit |
https://bugs.winehq.org/show_bug.cgi?id=48180
--- Comment #7 from Alexander Milos apmichalopoulos@outlook.com --- Alright, here is the +webservices log:
Unfortunately WINEDEBUG="+d3d8,+d3d9,+ddraw" app.exe 2>&1 | grep -e '_CreateDevice' -e '_FPUPreserve' produced zero output, so I have no log to provide you with (yes, I did replace "app.exe" with the real app's name :P)
Also, something I noticed is that at a different point of the game (a newer save file) some icons are now showing correctly, while others are still invisible. Maybe there is something to be found in that, so I ran the same three traces (+webservices, +d3d/d3d11/d3dshader, +msvcrt/ntdll) with the new save. I did try to run a diff between the two d3d logs to see if I could perhaps catch any new things in there but I ran out of RAM, so all I can provide is the logs:
By the way, just for the record, I'm still using yesterday's sources and not today's rc2.
https://bugs.winehq.org/show_bug.cgi?id=48180
--- Comment #8 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Alexander Milos from comment #7)
Alright, here is the +webservices log:
There are no webservices calls in this log, so that's not it.
Unfortunately WINEDEBUG="+d3d8,+d3d9,+ddraw" app.exe 2>&1 | grep -e '_CreateDevice' -e '_FPUPreserve' produced zero output, so I have no log to provide you with (yes, I did replace "app.exe" with the real app's name :P)
That is what I expect when those strings do not exist in the output (meaning these routines are not the problem). If you want to double check you can run essentially the same thing with +d3d11: WINEDEBUG="+d3d11" app.exe 2>&1 | grep -e '_create_device' That should show you all lines with 'd3d11_create_device'.
Also, something I noticed is that at a different point of the game (a newer save file) some icons are now showing correctly, while others are still invisible.
Please make sure that you keep the save where the issue is easy to identify. Can you confirm that reverting 0e183cc3c0d3b6f89f79047cdd71c389afc75073 fixes the issue when you load that same save? A possibility is that if you save the game with invisible icons then opening such a save will keep them that way even if the Wine code is fixed.
... I did try to run a diff between the two d3d logs to see if I could perhaps catch any new things in there but I ran out of RAM, ...
That is to be expected, any difference in when operations are executed will result in massive changes between the diffs.
https://bugs.winehq.org/show_bug.cgi?id=48180
--- Comment #9 from Alexander Milos apmichalopoulos@outlook.com --- (In reply to Erich E. Hoover from comment #8)
There are no webservices calls in this log, so that's not it.
I thought it weird that there were no webservices related entries in the log as well, but still, that's what running the app with WINEDEBUG=+webservices gives me.
That is what I expect when those strings do not exist in the output (meaning these routines are not the problem). If you want to double check you can run essentially the same thing with +d3d11: WINEDEBUG="+d3d11" app.exe 2>&1 | grep -e '_create_device' That should show you all lines with 'd3d11_create_device'.
Yup, that's what I meant as well. Running the equivalent grep for d3d11 gives me the proper d3d11_create_device lines, so I guess that leaves d3d8,d3d9 and ddraw out of the question.
Please make sure that you keep the save where the issue is easy to identify. Can you confirm that reverting 0e183cc3c0d3b6f89f79047cdd71c389afc75073 fixes the issue when you load that same save? A possibility is that if you save the game with invisible icons then opening such a save will keep them that way even if the Wine code is fixed.
No need to worry, I'm not about to delete anything until either this gets resolved or we give up trying to resolve it :)
Regarding this possibility you mentioned, I just compiled the latest master with commit 0e183cc3c0d3b6f89f79047cdd71c389afc75073 reverted and loading the exact same save file worked like a charm, with all the icons visible. Also, I've already more or less confirmed that the save file is not to blame since, when I did the initial bisect, I did so using the very same save file each time I tested a new bisect sample. So unfortunately, the changes in the commit itself seem to be our culprit.
https://bugs.winehq.org/show_bug.cgi?id=48180
--- Comment #10 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Alexander Milos from comment #9)
... I thought it weird that there were no webservices related entries in the log as well, but still, that's what running the app with WINEDEBUG=+webservices gives me.
Honestly, it would be stranger if the application used webservices - but I want to cover our bases.
... Yup, that's what I meant as well. Running the equivalent grep for d3d11 gives me the proper d3d11_create_device lines, so I guess that leaves d3d8,d3d9 and ddraw out of the question.
Great, one less thing it can be.
... Also, I've already more or less confirmed that the save file is not to blame since, when I did the initial bisect, I did so using the very same save file each time I tested a new bisect sample. So unfortunately, the changes in the commit itself seem to be our culprit.
Awesome. Unfortunately, while that commit exposed the issue it's not likely the source of the problem. To double check that you can run with +msvcrt, grep for '_control', and redirect that to a file: WINEDEBUG="+msvcrt" app.exe 2>&1 | grep '_control' > control.log
We can then check that log for undocumented flags and see if it's somehow requesting a change to the x87 FPU even though there's no documented way to do that on amd64.
https://bugs.winehq.org/show_bug.cgi?id=48180
--- Comment #11 from Alexander Milos apmichalopoulos@outlook.com --- Alright, at long last I have some good news!
Turns out that between the patch for strtod in commit c22af971c287933a137c9fbecc81823812e12b7a and 5.0rc2, there has been one more commit by you containing changes directly relevant to this issue: commit a6734f549fc6f5d0a93364d159519a5d6d0b5f38, which fixes the equivalent wcstod parts. And it turns out that *that* commit is what actually fixes the issue reported here.
As I mentioned yesterday, in the name of preserving my test environment and trying not to change too many unknown variables at once, I kept using the 5.0rc1.c22af971c287933a137c9fbecc81823812e12b7a sources, i.e. up to your first patch of a couple of days ago, because I didn't realize that you've actually created not one but two patches (or at least, a single one but in two different parts and in two different commits). But when I updated to 5.0rc2 yesterday in the process of confirming that reverting 0e183cc3c0d3b6f89f79047cdd71c389afc75073 fixes the issue while using the same save file, as you asked, I inadvertently also updated to a version that completely fixes the issue, revert or no revert.
So, that's that; this bug can be closed as fixed. Thank you for your work, both for creating the two patches and for spending your time trying to fix this issue as well.
https://bugs.winehq.org/show_bug.cgi?id=48180
Erich E. Hoover erich.e.hoover@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |a6734f549fc6f5d0a93364d1595 | |19a5d6d0b5f38 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED
--- Comment #12 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Alexander Milos from comment #11)
Alright, at long last I have some good news! ... So, that's that; this bug can be closed as fixed. Thank you for your work, both for creating the two patches and for spending your time trying to fix this issue as well.
That's wonderful news! I'm sorry it took so long. Now that you mention it - there are no TRACE statements in this code, so the only way we would have been able to capture it with WINEDEBUG would have been with +relay... It looks like I have a couple more places to fix, but I'm glad this one is out of the way :)
https://bugs.winehq.org/show_bug.cgi?id=48180
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #13 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 5.0-rc3.
-
WineHQ Bugzilla