[Bug 60253] New: Incoming (1998) crashes after the intro animation
http://bugs.winehq.org/show_bug.cgi?id=60253 Bug ID: 60253 Summary: Incoming (1998) crashes after the intro animation Product: Wine Version: 11.3 Hardware: x86-64 URL: https://archive.org/download/incoming_201401/incoming. exe OS: Linux Status: NEW Keywords: download, regression Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs@list.winehq.org Reporter: gyebro69@gmail.com CC: rbernon@codeweavers.com Target Milestone: --- Regression SHA1: 7df175a66faef1804ee84e278feecbd69a30cf37 Distribution: --- Created attachment 81966 --> http://bugs.winehq.org/attachment.cgi?id=81966 terminal output (Incoming demo version) The regression was introduced by commit: 7df175a66faef1804ee84e278feecbd69a30cf37 ddraw: Pass the active device to material_activate. Reverting this commit on current Wine 11.16 fixes the crash completely. The issue is reproducible with the original demo version and the Steam and GOG.versions as well. wine-11.16-156-g2ecc2f84b45 NVIDIA GeForce GTX 1660 SUPER NVIDIA 610.57.04 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60253 Evan Morse <e.morse8686@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |e.morse8686@gmail.com --- Comment #1 from Evan Morse <e.morse8686@gmail.com> --- Thanks for the bisect. It pointed me in the right direction, though reverting to the commit you suggested only coincidentally solved the problem. The crash is a null write in wined3d; that is a symptom. The real problem is in ddraw. d3d_execute_buffer_SetExecuteData() sizes its vertex buffers from D3DEXECUTEDATA.dwVertexCount, and in the failing case the game passes 31,952,168. Multiplied by sizeof(D3DVERTEX) that is a ~975 MiB allocation, which fails in a 32-bit address space. The failure return is not checked, so the null propagates until something writes through it. The game is not really at fault. The execute buffer in question contains only D3DOP_STATELIGHT, D3DOP_STATERENDER and D3DOP_EXIT, with no D3DOP_PROCESSVERTICES at all, so no vertices are processed and the game never initialises dwVertexCount. The field, in this case, just holds stack residue. Garbage. I measured what Windows does with that field on Windows 8.1, 10 and 11: - An absurd dwVertexCount causes no allocation, whether or not the buffer processes vertices. Wine allocates ~975 MiB in both cases. - A dwVertexCount of 0 or 1 still draws when PROCESSVERTICES asks for 4. Wine draws nothing. - dwVertexOffset appears to be ignored; vertices are addressed from the start of the buffer. Wine honors the offset. 7df175a66fa did not introduce this; it changes memory layout, which changes what stack residue the field picks up. Reverting it makes the value smaller, not correct: unreverted 0x1e78d28 / 0x1e78d70 / 0x1e7f6a0 ~975 MiB crash reverted 0x117038 ~35 MiB allocates, runs Two runs of the same unreverted binary disagree by 72 bytes, which no real vertex count would. The reverted build is reading the same uninitialized field and simply getting a survivable garbage value. 64-bit WoW does not crash at all because the allocation fits. I have a small patch written that bounds dwVertexCount by the execute buffer's own dwBufferSize, which is a limit the application declares at creation. With it, ddraw:ddraw1 and ddraw:d3d are unchanged from master, the crash is gone, and the game reaches level loading and is playable. In one run the bound applied 898 times and every single one was the same garbage value; no legitimate count was affected. I will submit that merge request shortly. First I need to play this demo some more. Its pretty fun. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60253 --- Comment #2 from Béla Gyebrószki <gyebro69@gmail.com> --- I tested the proposed patch and can confirm that it fixes the Incoming crash. https://gitlab.winehq.org/wine/wine/-/merge_requests/11863 I have also been using Wine 11.17 with this patch applied for the past three days while testing a large number of games, mostly older titles from my GOG library. So far I have not encountered any regression or other issue that appears to be caused by this patch. Thanks for the fix. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla