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.