Hi everyone.
I'm trying to track down an occasional crash bug in my game code. The problem is it's quite hard to reproduce and when the game does freeze it's not obvious why?
It seems likely that under certain conditions a pointer is being corrupted but to narrow the search I'm thinking it might be a good idea to use a debugger.
So I'm wondering what debugging options are available and which would people recommend?
My preference is something that'll work with XRoar but I understand MAME has a built-in debugger?
Also, I've never used a debugger before so what kind of things can you do with them to track down bugs? For instance can you trace the PC leading up to a crash?
Any advice gratefully received.
Cheers, Steve.
Debugging Advice
Re: Debugging Advice
The Built in debugger in MAME is very good once you get the hang of it !
You can set breakpoints, examine mem/code - change stuff on the fly etc....
/SImon
You can set breakpoints, examine mem/code - change stuff on the fly etc....
/SImon
Re: Debugging Advice
Hi Simon.
So MAME sounds like a good place to start. I see there's documentation online regarding MAME's debugger commands.
I'm still unsure what strategy to use to build up a picture of what's happening immediately before a crash though?
So MAME sounds like a good place to start. I see there's documentation online regarding MAME's debugger commands.
I'm still unsure what strategy to use to build up a picture of what's happening immediately before a crash though?
Re: Debugging Advice
Try this, my friend: http://docs.mamedev.org/debugger/index.html
I like MAME's debugger a lot, as it works very much like the one in Visual Studio.
Hope this helps!
I like MAME's debugger a lot, as it works very much like the one in Visual Studio.
Hope this helps!
Re: Debugging Advice
Thanks Rob.
So if you were trying to find the code which executed immediately prior to a crash would you use the `trace' command or maybe `tracelog' to track the pc register?
Or is there a better way?
So if you were trying to find the code which executed immediately prior to a crash would you use the `trace' command or maybe `tracelog' to track the pc register?
Or is there a better way?
Re: Debugging Advice
bosco m8y, throw me a PM, i'm sure we can trace yur little buggy..... (had to do it numerous times with demo and timberman)
/Simon
/Simon
Re: Debugging Advice
With XRoar you'd have to figure out how to attach a GDB-compatible debugger. Doable, but I don't even know what tools are available for windows.
And I don't even usually resort to GDB. I tend to pipe the output of trace mode through "less", and then use regex searches to find things - usually spotting when code veers off into illegal instructions (which get flagged with asterisks).
And I don't even usually resort to GDB. I tend to pipe the output of trace mode through "less", and then use regex searches to find things - usually spotting when code veers off into illegal instructions (which get flagged with asterisks).
Re: Debugging Advice
Hi Steve,
I personally wouldn't reach for a debugger straight away, as it kind of requires you to know where to look to begin with. Getting an instruction trace out of xroar sounds like the quickest way of finding which bit of code was running before the crash. The resulting file will be huge but should be manageable with a decent editor.
It's possible a dodgy execution path could re-enter your code at some point before leaving it again so it's worth stepping back through the trace to make sure you are looking at the last valid bit of your code before the program counter ran off giggling into the woods.
I'm a fan of playing with the source code to find bugs. You can do things like disable code and assets to see if you can narrow things down. Maybe bookend your jump lookup tables with addresses that stop execution and paint a tell-tale on the screen. If you're doing things like lsla/jmp [a,x] then you could pad the tables out to 256 bytes to see if you can catch illegal values. I've had crashes caused by sprites moving fast enough to fall off the ends of a horizontal clip jump table.
Might be worth using a bit of conditional assembly to insert assertion checks on code pointers, to make sure they are pointing to somewhere within your code before you jump to them. Again, paint a tell-tale on the screen if an assertion fails.
There are many causes for crashes but could be something like using the wrong addressing mode when updating a code pointer. (e.g. swapped immediate for extended). Using a symbol with a similar name to one you want is an easy mistake to make, especially if you're using code completion. More tricky to find would be something like a write to the wrong address corrupting a bit of code that crashes later. Jumping into a subroutine instead of calling it is another way of quickly losing control.
Any code that stores temporary variables on the stack is an early suspect. I now prefer to use a bank of re-usable variables in the direct page.
I personally wouldn't reach for a debugger straight away, as it kind of requires you to know where to look to begin with. Getting an instruction trace out of xroar sounds like the quickest way of finding which bit of code was running before the crash. The resulting file will be huge but should be manageable with a decent editor.
It's possible a dodgy execution path could re-enter your code at some point before leaving it again so it's worth stepping back through the trace to make sure you are looking at the last valid bit of your code before the program counter ran off giggling into the woods.
I'm a fan of playing with the source code to find bugs. You can do things like disable code and assets to see if you can narrow things down. Maybe bookend your jump lookup tables with addresses that stop execution and paint a tell-tale on the screen. If you're doing things like lsla/jmp [a,x] then you could pad the tables out to 256 bytes to see if you can catch illegal values. I've had crashes caused by sprites moving fast enough to fall off the ends of a horizontal clip jump table.
Might be worth using a bit of conditional assembly to insert assertion checks on code pointers, to make sure they are pointing to somewhere within your code before you jump to them. Again, paint a tell-tale on the screen if an assertion fails.
There are many causes for crashes but could be something like using the wrong addressing mode when updating a code pointer. (e.g. swapped immediate for extended). Using a symbol with a similar name to one you want is an easy mistake to make, especially if you're using code completion. More tricky to find would be something like a write to the wrong address corrupting a bit of code that crashes later. Jumping into a subroutine instead of calling it is another way of quickly losing control.
Any code that stores temporary variables on the stack is an early suspect. I now prefer to use a bank of re-usable variables in the direct page.
Stew
Re: Debugging Advice
I would also add that if you're using self-modifying code, then it's worth ensuring that the addressing mode is forced to the one that's been assumed. For example use the > modifier to force extended addressing to prevent the assembler using DP addressing and breaking the code.
Stew
Re: Debugging Advice
Thanks guys. Some great advice there. 
Spamming registers, addresses etc. to the screen is a technique I do use a lot along with disabling whole sections of code to corner a bug. In fact this is usually enough and on this occasion has enabled me to focus my search on one area of specific interest.
An instruction trace sounds interesting. What are the steps to setting this up?
Cheers, Steve.
Spamming registers, addresses etc. to the screen is a technique I do use a lot along with disabling whole sections of code to corner a bug. In fact this is usually enough and on this occasion has enabled me to focus my search on one area of specific interest.
An instruction trace sounds interesting. What are the steps to setting this up?
Cheers, Steve.