There was a suspicious TODO in the code, which was the main reason this was broken: We were unconditionally "continuing" all threads when doing StepOver. This is obviously wrong, and it's correct for StepIn, StepOut etc. -> Wait for the step response and only continue the thread that you stepped within.
Meanwhile I also noticed that the 'stopped' event handling was incorrect if we get a flood of stopped events for different threads. If we got 3 stopped events in quick succession, we'd end up dropping the middle one. This was because we only stored the latest-most pending request. Not sure why i thought that was a good idea, as the handler for the stoppped event includes the thread ID that was actully stopped.
This particularly affects the java debugger which is afaict the only one that doesn't set allThreadsStopped=true.
puremourning
commented
4 months ago 
There was a suspicious TODO in the code, which was the main reason this was broken: We were unconditionally "continuing" all threads when doing StepOver. This is obviously wrong, and it's correct for StepIn, StepOut etc. -> Wait for the step response and only continue the thread that you stepped within.
Meanwhile I also noticed that the 'stopped' event handling was incorrect if we get a flood of stopped events for different threads. If we got 3 stopped events in quick succession, we'd end up dropping the middle one. This was because we only stored the latest-most pending request. Not sure why i thought that was a good idea, as the handler for the stoppped event includes the thread ID that was actully stopped.
This particularly affects the java debugger which is afaict the only one that doesn't set allThreadsStopped=true.
Fixes #865