https://bugs.winehq.org/show_bug.cgi?id=48482
--- Comment #14 from Federico Dossena info@fdossena.com --- (In reply to Stefan Dösinger from comment #13)
WINEDEBUG=warn+heap doesn't write anything unless it detects corruption. It enables some extra code that will fill freed Heap memory with 0xfeeefeee and newly allocated ones with 0xfeedfeed (or similar. not sure). It also verifies some extra canary values when operating on heap allocations.
That making it large address aware doesn't help suggests that the heap use is not the issue here. Is the virtual memory size still in the 3+ GB range at the time of the crash? Heap corruption is pretty unlikely too. warn+heap is not guaranteed to catch it, but very likely.
So next guess would be a race condition. Did you try to force it to one CPU core with taskset? (e.g. taskset -c 1 wine kotor.exe)
Yes, I tried running the game with a single core and it doesn't fix it.
Since the game is statically linked, I made a very simple hack that doubles the requested memory when malloc is called (I can provide a file diff if you want). The game runs normally but obviously uses a bit more memory, however, it still crashes after a few load screens, at the same exact point, with an access violation instead of a null pointer.
So my initial findings might have been wrong (after all, reverse engineering really isn't my thing), and I think that this might be a use after free thing. I tried using valgrind to prove this, but it won't start for some reason. Is there any other way to debug this?