Note that Wipeout can (if you are lucky) only tell you which memory was overwritten, but not necessarily which piece of code caused it to be overwritten.
In a certain other AOs clone where it's easy to modify OS source on demand for debugging purposes you can use some tricks:
- allow triggering of memory wall checks of all allocations at any time when app calls some easily reachable function (like hack this into AvailMEM(MEMF_CLEAR)). Whenever anyone calls AvailMem(MEMF_CLEAR) all memory walls of all allocations are checked for mem trashes.
- use this all over the place in the code to debug.
- for tricky cases modify exec mem alloc functions to be be disable/enable protected instead of forbid/permit, and then in the Exec task switching routines trigger the mem trash check. To find out under which task mem trashes happen.
- for other tricky cases use gdb (the OS as a whole runs under gdb, not single tasks or apps) hardware watch points (no slowdown) if you know what is trashed, but not when and by whom. With gdb it is possible to install/uninstall watch points dynamically. For example have a normal breakpoint somewhere at the start of a function and one at the end of a function. Then when hitting first breakpoint have gdb automatically install a hardware watch point on a certain local address and immediately continue running again. When hitting the second breakpoint, have gdb automatically remove hardware watch point, and immediately continue running again. So the thing keeps running and running and only when the hardware watch point triggers the debugger stops.
For AOS itself some of this stuff may be possible to do more easily with an emulator (maybe after enhancing debugging features of emulator some more).
