Debugging a guru

[deimos]

I've got a bit of assembly code that appears to work, until the program is about to exit, at which point I get get a:

Software Failure. Press left mouse button to continue.
Error: 8100 0005 Task: 00258D50

I assume I stepped on a bit of memory I shouldn't have. But how on earth do I find the instruction that caused it so that I can start to figure out exactly where my code is bad?

[PeterK]

Very often there is something wrong in restoring the registers and/or setting the stack pointer back to exactly the same level where it was at the start of your program.

You can also install some tools like AlertPatch, Enforcer, MungWall, WipeOut, SegTracker or SmartCrash which could give you more details for a Guru, like the contents of all registers, the stack and even references to the location in your code where the crash occured.

If you have a FreeMem()/FreeVec() in your exit code, comment it out to see if the Guru disappears (although it's a memleak then). And if it works without a guru check your code for possible writing past the end of buffers.

[meynaf]

It appears some memory not belonging to the program has been altered and the system's memory lists got corrupt.
These are tricky to catch. My method is to cut the code in parts, either by exiting prematurely (and moving the exit further and further until the problem occurs), or by setting breakpoints everywhere and then i know between which two parts it happens.
In short, execute only part of the code and see if it does something wrong or not.
Of course this only works if the problem is easy to reproduce ; sometimes it's random and a real PITA to debug...

[deimos]

Originally Posted by meynaf

In short, execute only part of the code and see if it does something wrong or not.

Ok, you've told me what I needed to hear, and it seems by following that approach I've already isolated it to one routine.

Thanks.

Edit:

Yup, I just needed to increase the space I'd reserved for the data structures I build.