https://bugs.winehq.org/show_bug.cgi?id=48788
Bug ID: 48788 Summary: null pointer in wined3d_palette_set_entries with Diablo GOG Product: Wine Version: 5.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs@winehq.org Reporter: perchrh-wine@pvv.org Distribution: ---
Created attachment 66691 --> https://bugs.winehq.org/attachment.cgi?id=66691 WINEDEBUG=+d3d wine Diablo.exe
The game "Diablo", appdb-link: [1] crashes on startup due to a wine_d3d error.
Steps to reproduce: 1 Set the wine configuration to Windows 10, virtual desktop 800x600, to make the installer work. 2 Run the GOG Diablo installer, 'wine setup_diablo_1.09_hellfire_v2_(30038).exe' 3 Then in the game directory, run 'wine Diablo.exe', to launch the game.
After launching the game, the Blizzard logo successfully shows on screen. Immediately after the logo animation, wine crashes.
The crash looks like a null pointer, excerpt below: Backtrace: =>0 0x7c52d82e wined3d_palette_set_entries+0x3e() in wined3d (0x0032fc38) 0x7c52d82e wined3d_palette_set_entries+0x3e in wined3d: movl 0x0(%eax),%ecx
The attached log with WINEDEBUG=+d3d show wined3d_palette_set_entries is first successfully called multiple times before the null pointer crash. The logs are from a clean wine prefix. The crash is reproducible 100% of the time. I had to run wineserver -k after the crash to launch the game again.
This crash differs from the other startup bug registered for the same game [2], which crashes in storm.dll as opposed to wine_d3d.
[1] https://appdb.winehq.org/objectManager.php?sClass=version&iId=37759 [2] https://bugs.winehq.org/show_bug.cgi?id=46803
https://bugs.winehq.org/show_bug.cgi?id=48788
Per Christian Henden perchrh-wine@pvv.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Ubuntu
https://bugs.winehq.org/show_bug.cgi?id=48788
--- Comment #1 from Per Christian Henden perchrh-wine@pvv.org --- Likely this bug is a recent regression, as I appears that another error occurs first on 2020-01-12/wine 5.0.4-staging, according to the latest comment on issue 46803.
https://bugs.winehq.org/show_bug.cgi?id=48788
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp@gmail.com
--- Comment #2 from Paul Gofman gofmanp@gmail.com --- Created attachment 66705 --> https://bugs.winehq.org/attachment.cgi?id=66705 Hacks for builtin ddraw mode
I've tested the GOG version of the game.
This is not a recent regression.
First of all, GOG ships its own ddraw.dll for this game which probably fixes the game for the newer Windows versions. This ddraw.dll translates the ddraw API to d3d9. For that to work under Wine one needs to use 'native' ddraw override, that is, WINEDLLOVERRIDES="ddraw=n" or set such an override through winecfg for this Wine prefix. When the provided DLL is used the game does not crash, but the menu is drawn somewhat partially. This looks like something between the lines of bugs like Bug #2082, Bug #47036
The game not working with builtin ddraw.dll looks like an issue by itself though. The reason is not in _palette_set_entries like crash log could suggest. The application locks primary surface to update it, and eventually writes past end of the surface data occasionally overwriting wined3d palette structure which happens to go next (sometimes is crashes in the other place though). This part looks exactly like Bug #46803, even if it crashes in a different place (I was getting either crashes randomly). The attached hack ultimately increases the size of memory buffer allocated for texture and fixes the crash. It likely works on Windows by chance, though I did not exactly prove that it is not something caused by some sizes or positions returned slightly different under Wine.
With the crash worked around, the game displays black screen and again looks like something between the lines of Bug #2082, Bug #47036. The attached hack works around that partially, now the menu is partially displayed nearly the same way as with ddraw.dll provided by GOG.com.
https://bugs.winehq.org/show_bug.cgi?id=48788
--- Comment #3 from Per Christian Henden perchrh-wine@pvv.org --- Thank you Paul for the detailed investigation, summary and patch!
I'm pondering how Windows handles this. Perhaps it's just luck that the application doesn't crash even though it writes outside of the surface data area. Maybe Windows keeps two surface data areas next to each other in memory for double buffering or so? It wasn't just one byte/element size outside? If it's just one or two, I thought maybe it's an alignment issue or off-by-one bug in Wine. This topic isn't my forte, but I thought I'd try to contribute with some thoughts :)
A partially displayed menu is a step forward :) Did selecting the menu items work? I read that in another case/version the menu was a bit off, but the game could still be played.
https://bugs.winehq.org/show_bug.cgi?id=48788
--- Comment #4 from Paul Gofman gofmanp@gmail.com --- Created attachment 66713 --> https://bugs.winehq.org/attachment.cgi?id=66713 Test
(In reply to Per Christian Henden from comment #3)
I'm pondering how Windows handles this.
I was probably wrong saying that it works by chance on Windows, maybe not.
It is important to note that the (only) surface game locks is primary surface, 640x480 8 bit paletted.
This is a ddraw1 game released in 1997. Besides the grass been greener those days, ddraw primary surfaces were providing direct access to video memory mapped directly to the CPU address space and immediately visible on screen. 640x480x8 bit takes 300k in size, while video cards of that era should have normally had at least 1mb. So it was very unlikely that accessing the surface data a few scanlines off would cause an immediate crash, and not possible that it would touch some data other than the other video memory surface data. Since long ago ddraw primary surfaces are not mapped that way anymore and this behaviour is sort of emulated in Windows, but I can guess they can provide an extra space for the surfaces for compatibility with such program naughtiness. I attached the unit test which accesses more data past the end of primary surface and this works fine for me on Windows 7, while crashes under Wine. It is not a full proof of course but still.
Not sure but maybe it is something that can be done in Wine.
A partially displayed menu is a step forward :) Did selecting the menu items work?
Yes, the menu works, just a bit glitchy. If to use a supposed way of running GOG compatibility ddraw (setting native override for ddraw) the most of the menu is visible if you set somewhat higher resolution for virtual desktop.
I read that in another case/version the menu was a bit off, but the game could still be played.
The game itself past the menu seems to be fine.
https://bugs.winehq.org/show_bug.cgi?id=48788
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |d0ff5e66a7611511426a8ff902a | |95ab22c545f78 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
--- Comment #5 from Matteo Bruni matteo.mystral@gmail.com --- It should be fixed by https://source.winehq.org/git/wine.git/commitdiff/d0ff5e66a7611511426a8ff902a95ab22c545f78, thanks Paul.
https://bugs.winehq.org/show_bug.cgi?id=48788
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #6 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 5.6.
https://bugs.winehq.org/show_bug.cgi?id=48788
Alex Henrie alexhenrie24@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=49391
-
WineHQ Bugzilla