Home Page Forums MAME MAME Debugger Help - Tips, Tricks and Annoyances

Had to back out the change. It caused the debugger to seize control of KDE's virtual desktops and not allow me to switch over to, for instance, my Win7 VMWare instance. And that's unfortunately a much worse violation of my workflow than 'source' being broken.

Maybe Andrew can come up with a real fix given these hints though

qmc2: you ever seen that kind of weird behavior from Qt?

On Windows it wouldn't allow any other debugger windows to get focus while stopped. Putting,

at line 281 fixes it.

Ok, that fixes my Linux problems too. Nicely spotted

Has anyone else ever experienced having running behavior of a driver change just as a result of having a watchpoint set, even if the watchpoint is never triggered?

Yes, this usually happens with read handlers that have side effects like clearing IRQs. Then the debugger is actually the one triggering the side effect instead of the emulated system.

I have some write watchpoints set up to try and catch when a pointer in the driver's ram gets corrupted. None of the watchpoints get triggered, because before execution reaches them a different pointer gets corrupted, but only when the watchpoints are set. If I never set the watchpoints, this other pointer never gets corrupted.

You may need to find the real address of that RAM and use an external-to-MAME memory breakpoint (MSVC, GDB, and LLDB all have facilities for this).

Bugger, not looking forward to sorting this out. In the program in question, the issue comes from a garbage value of a pointer being dereferenced. This value happens to be unaligned which causes a memory exception fault in the emulated CPU (MIPS). However, it is very difficult to predict where this pointer is stored, as in the emulated program, it exists within a dynamically allocated object on the heap. Furthermore, the program periodically moves things around on the heap to compact/defrag the dynamic memory pool. I suspect the issue may come from an incomplete copy of a dynamic object leaving garbage values in the new location, but I have not been able to trace this, as the issue only seems to occur once for every few hundred operations. The bug seems to be mostly deterministic however, as I can get the same garbage value in the same memory location triggering the memory exception sometimes. If anyone has any suggestions on how to simplify this task, I would appreciate the help.

Happy,

If you actually know the location of the code you are trying to check, don't use the watch points. Just change the code so that it goes into a loop.
With the program trapped in a loop, you can start the debugger and check the contents of any registers or memory.

I don't know what cpu is in your system, but a simple trap in MC6809 code could be:
loop bra loop

For MIPS you'll get more repeatable behavior using the interpreter, but you probably already knew that.