On Thu, 2004-08-19 at 19:31, Andreas Mohr wrote:
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.
Yes, I had leapt to the assumption that the exception was occurring within Wine code. I shouldn't have assumed that.
And then is there a way to step through at the source rather than assembly level?
--> only if you have the game source ;-)
If the address 0x004191fb is within wine, then presumably there will be some way to determine the source line within wine?
And if it's in the game code, do people use c decompilers? Or is knowing x86 assembly code a requirement for debugging code that uses wine?
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.
I have some good news anyway. I still can't load the games I saved earlier. But I tried starting a new game, and can load/save happily. So the possibilities are: (a) that the problem was caused by a corrupt save-file being *created* when running with the debian wine release (Version: 0.0.20040615-1), and that now I am running with wine CVS HEAD, games are being saved properly. (b) that there is a bug in HoI, and that the saved game wouldn't have loaded on Windows anyway. I will test this theory soon by taking the save-game to a friend with a Windows copy and see what happens. It would be truly bad luck to strike an HoI bug the first time I try to run it under Wine, but stranger things have happened. (c) that the bug is wine-related, but only pops up sometimes. I can test this by playing a lot more games, and seeing if it happens again.
So for now, I'm going to suspend the wine debugging, and do some more playing instead :-)
Thanks for your help.
Cheers,
Simon