OpenMSX debugger's Code View showing unexpected content

By DamnedAngel

Expert (85)

DamnedAngel's picture

02-11-2018, 14:26

Hi all,

I am using OpenMSX debugger to breakpoint and step-by-step debugging, but Code View panel sometimes shows unexpected content. It seems to be showing another slot/subslot.

If I inspect Main Memory panel, the contents are the ones I was expecting (my machine code). SImultaneously, Code view shows different data:

Please note the difference in address 9a9h: Code view panel shows a7 (and a) while Main memory panel show the same address containing dd e5 (push ix), exactly what I expected.

I may be doing something wrong, though. I tried to find where to set slot/subslot specifically for the code view panel, but found nothing.

Is there something I can do to get to visualize the desired slot/subslot?

Note: sometimes the code view gets the proper data, but I did not recognize any behavior pattern - or usage pattern - that led to such state.

Login or register to post comments

By Grauw

Enlighted (7462)

Grauw's picture

02-11-2018, 15:44

The disassembly is cached and doesn't always update correctly. Try scrolling all the way up and down and then back (I tend to press step forward / back to bring the current position back in view). That usually fixes it for me.

By DamnedAngel

Expert (85)

DamnedAngel's picture

02-11-2018, 15:44

It seems to be a refresh issue. I tried messing around in the interface and it suddenly updated with the correct data...

By DamnedAngel

Expert (85)

DamnedAngel's picture

02-11-2018, 15:45

Exactly. Thanks Grauw!!!!

How does one report a bug in OpenMSX Debugger?

By Grauw

Enlighted (7462)

Grauw's picture

02-11-2018, 16:40

By sd_snatcher

Prophet (2865)

sd_snatcher's picture

02-11-2018, 19:07

You can probably add your comments and upvote on this bug report.

By Grauw

Enlighted (7462)

Grauw's picture

02-11-2018, 19:21

I think the problem with that bug report is that it describes a solution rather than the problem.

And I don’t agree with the suggested solution; I think it would be much better to solve the problem in a way which doesn’t require explicit user intervention, otherwise I’ll be pressing the refresh button continuously because I don’t trust the debugger’s output… definitely a bad thing (the distrust), and also unnecessary manual labour the computer can do rather than me. Other fields on screen are also updated when I hit a breakpoint and step through the code, so why shouldn’t the code view be able to as well.

Additionally, the case where I most often encounter this issue is when I recompile and relaunch openMSX, and then reconnect the debugger. If the breakpoint I hit is close to where I previously disconnected the debugger is still using the cached data disassembly. Definitely when the debugger is reconnected it could flush the cache.

So although it is related, I think it deserves a new report, or an amendment of the existing one (but I don’t think the latter’s possible since it’s an old issue imported from sourceforge so not associated with your github username).

By sd_snatcher

Prophet (2865)

sd_snatcher's picture

02-11-2018, 19:48

No problem. That report was done nearly a decade ago. Nowadays I would probably report it differently, but as you can see in the history log, I mentioned back then that I wasn't sure if it should be reported as a bug or a feature request.

I have nothing against it being modified or closed if a new one reports this problem. What I really wish that this bug was solved, regardless of the solution. It would save a lot of time when developing.

My MSX profile