breakpoints should be removed on module update

[carllocos]

Essentially the question is should we remove previously set breakpoints after updating a module?

A. To me it feels natural to remove the breakpoint since conceptually updating a module means also starting from a fresh run in the VM and in that sense, I would expect that the VM does some cleanup before starting executing the new module. Part of the cleanup would be for instance, unsubscribing previous callback handlers of the previous module, removing breakpoints, and so on. If this is the direction we want to take, then updating the module should then also remove the breakpoints.

B. On the other hand, we could agree that breakpoints are only used when debugging. Consequently, if a user updates a module that probably means that a bug got fixed but the user may still want to continue debugging and thus the previously set breakpoints should still remain active.

If we go with A. then this is a bug easily fixable If we go with B then this is not a bug and we can close this issue.

@tolauwae what do you think?

[tolauwae]

@carllocos Hi, going through the old issue backlog 👋

It seems this issue was fixed on the frontend side at some point: https://github.com/TOPLLab/WARDuino-VSCode/issues/86 However, I think ideally it would work the other way around.

The module update invalidates all breakpoints, since they can point to completely new locations. I agree with you, this is the most natural. After an update, the fronted should set all necessary breakpoints again (the vm can't keep track of this).

This is not high priority, since a fix is in place. But I'm adding option A as subissue for now.

[carllocos]

Hi @tolauwae

Indeed option A makes the most sense due to the breakpoints pointing to invalid addresses.

Thanks for adding as a subissue this will have to be fixed at some point