Hi,
On Thu, Aug 19, 2004 at 06:43:14PM +1200, Simon Kitching wrote:
Backtrace: =>1 0x004191fb (0x406bfe94) 2 0x005af5b2 (0x406bff20)
All in app space, most likely. Not very useful, I'm afraid.
And then is there a way to step through at the source rather than assembly level?
--> only if you have the game source ;-)
It's apparent here that %ecx is null when not expected to be, resulting in a bad access to memory address 0x00000006.
Yup, most likely.
I also tried the "WINEDEBUG=+relay" option as recommended in the wine docs. However after leaving the program running overnight, and having generated 3 gigabytes of log output, the point where the bug occurs hadn't been reached. I think that what's happening is that there is a thread (0011) which is driven by timer ticks [probably doing GUI or sound stuff], and that because HoI is running much more slowly under +relay, that the thread doing the load-game work (0009) isn't actually getting any CPU time at all. NB: the log was only 3GB because I used grep to discard output about RtlEnterCriticalSection and RtlLeaveCriticalSection. Without that, the log would be closer to 30GB!
You should at least have used pipes as described in the User Guide... (not sure whether that ultimately helps then, though...)
Any suggestions on how to make progress on this issue are welcome.
If a relay trace doesn't help, then the next thing would be to disas surrounding code at 0x004191fb and walk back the code flow to find out where the NULL %ecx was coming from.
PS: Congrats to the Wine team. I was most impressed how well HoI ran on wine.
Thanks!
Andreas Mohr