Hi Ken,
On Sun, Jul 21, 2013 at 2:39 PM, Ken Thomases ken@codeweavers.com wrote:
Instead of enabling the trace, try replacing it with something like:
char dummy[256]; memset(dummy, 0x55, sizeof(dummy));I bet the crash will change from a read access to 0x00000001 to 0x55555555.
Thanks for the advice, it sounds cool and I learned new things, thank you. However, it doesn't help in this case, I didn't found any change after the dummy hack.
The question is: is it a bug in the game or a bug in Wine where Wine is returning a garbage pointer to the game and the game is innocently dereferencing it? For that, you'd have to trace the execution from the call to d3d9_AddRef() to the crashing point to see what else is called and whether it uses an uninitialized value.
Of course, another approach would be to run under Valgrind, if you can get it to work.
I've run it under Valgrind, there are many outputs, I'm not sure which part of valgrind output is important and which part could be ignore, the output is attached to bug 34125 as well.
Quite a lot of output are related to native msvcr80 installed by the app, I tried force using buitlin msvcr80, unfortunately the game doesn't start at all with buitlin msvcr80. I've send one test case (Patch 97446), but there is still other msvcrt bugs after that issue.
By the way, the game ship with many native d3dx9_??, and with buitin d3dx9_?? it doesn't start as well.