On Mon Mar 16 14:12:15 2026 +0000, Matteo Bruni wrote:
I think before committing to any particular fix we need to figure out what the game is depending on, exactly i.e. it's very possible that with this fix the game is writing out of the allocated heap and only working "by chance". Which is what Nikolay was getting at, I assume. How does the game manage to overwrite a child object by messing with a parent object data, on current Wine? In theory that shouldn't happen, since the size returned by `GetData()` doesn't include any children. Assuming the sizes are correct, and the game isn't just stomping out of the allocated area, maybe it's a matter of alignment? I'll mention a possibly helpful tool in the toolbox. Running the game with WINEDEBUG=warn+heap will enable some heap checking and validation code. Sometimes it will simply spew useful warnings about bad heap accesses, but often it will change the behavior if the application is doing something fishy. The game writes into the heap header at returned_ptr - 4 after calling GetData() on the mesh (increases it by 1) and reduces it by 1 after its done with the rest of the file. So during the load the heap header is corrupted. warn+heap doesn't flag it though and through random chance this doesn't seem to have any adverse effect with the way things are implemented right now in wine. We could allocate more and return an offsetted pointer to protect against this, or add padding in the internal buffer between elements and not do individual allocs for each element.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/10278#note_133057