strange behavior when debugging

[Real-MJoe]

After the last updates, debugging of larger projects is modest. As soon as you access Dos libs and start the debugger in VSC, the following error occurs:

and

I was able to “skip” this further with F5. But after I created more code, I couldn't get any further. Starting with Shift+F5 works without any problems. I can also run the code in the emulator or on real hardware without errors.

It's no problem to jump into the code with the debugger as long as you don't use DOS libs.

Can I activate more logs for the extension to better isolate the error?

Thank you very much

PS. Unfortunately I can't share my sources.

[prb28]

I've the same issue with fs-uae on windows. As workaround you can remove the "all exceptions' in break points :

@grahambates Do you have time to make a new release of your library with a fix ?

[grahambates]

Sure, I'll have a look at it this weekend.

[prb28]

@grahambates Some news about the fix ?

[grahambates]

Hey, really sorry for the lack of activity on this. I've had some personal stuff going on, but I'm back on it now. I just need to get my head back into the code and I'll have a fix soon.

[grahambates]

Ok, I figured out the issue. At some point the default value for the exception mask changed and included bit 8: Privilege violation. Most of the time you don't want this as it will get triggered by normal behaviour in the ROM.

I can definitely just fix the default value, but before I push this, I was also looking at using the expection filter options to give user control of this. Where currently we just have 'all exceptions' and the actual exception types are managed by the exceptionMask launch config option, we can expose the indivual types. I think this is much more user friendly, but it does take up a fair bit of space in the breakpoints list. I'd be interested to hear your thoughts.

[prb28]

Much more user friendly, but yes I agree with you it takes a lot of breakpoints screen space. Maybe only taking 2 or 3 most common uses besides the "all exceptions"?

[grahambates]

Ok, I'll just change the default for now and have a think about this.

I suppose only the first four, which should be on by default, are really exceptions in the modern sense, even though that's what Motorola called them. The other types of traps are not necessarily errors, and setting breakpoints on these is quite a niche use case.

[grahambates]

I'm still not too clear on why the behaviour changed here, as the default exception mask hs been the same for a long time. My guess is that it's due to a change in WinUAE where it has only now started triggering that exception type, and perhaps it wasn't implemented in older versions. Another possibility is that we weren't setting the mask correctly before. I'll look into this to verify, but either way it is now doing exactly what we ask, and changing the default mask is the right thing to do.

This does also mean that where people have existing debug configs with the old default 8188 set will continue to see this problem, but there's not much we can do other than document it and mention it in release notes.

[prb28]

@Real-MJoe does the last pre-release fix this issue ? I would like to do a standard release.

[Real-MJoe]

In the latest pre-release "v1.8.9 (pre-release)" the bug is still present.

[grahambates]

@Real-MJoe the latest build changes the default value for exception mask, but if you have an existing config where it's explicitly set, you'll need to change or remove it.

The new default is:

"exceptionMask": 60,

[Real-MJoe]

With the new value for the "exceptionMask" it works now. Thanks for that.

[prb28]

I'll make a stable release Monday. Thanks @grahambates and @Real-MJoe .