Crash during debugging session if change in breakpoints

[leouk]

Every time in a debug session, if you change breakpoint locations or enable/disable them, even if through the "BreakPoints" view, Overture crashes.

[ldcouto]

Hey Leo.

This doesn't happen for me. Gonna need a bit more info to try to reproduce. How are you launching the debugger (console or entry point)? Does this happen for all models (maybe you can do a quick test with one of the standard examples)?

[leouk]

Hi,

It’s the console. So the scenario is this:

1. have my model correctly type checked etc. if running in the console, all works fine
2. I now want to debug a feature and I set a BP before debugging; start console again.
3. type in some print statement that will trigger the BP. I do step in/over/out etc.
4. while the focus is on the editor window where the BP was at first, I add/remove a BP elsewhere in the same file
5. overture crashes.

It did happen on this model (on the semantics of a security language), but also on the models I use for students (on games).

Best, Leo

On 6 Dec 2015, at 14:19, Luis Diogo Couto [email protected] wrote:

Hey Leo.

This doesn't happen for me. Gonna need a bit more info to try to reproduce. How are you launching the debugger (console or entry point)? Does this happen for all models (maybe you can do a quick test with one of the standard examples)?

— Reply to this email directly or view it on GitHub https://github.com/overturetool/overture/issues/485#issuecomment-162320615.

[ldcouto]

Ok, so I have confirmed this on the Alarm example. We've started looking into this but it may take a bit since it involves communication between processes.

The rest of this comment is technical stuff for tracking down the bug:

It seems like a an issue with the communication between the interpreter and the IDE. When the breakpoint is set, the IDE sends a packet to the interpreter to register the breakpoint. It then waits for a response packet (DbgpPacketReceiver:L64). It then goes into a wait() from which it never wakes.

So one of two things has happened:

• the interpreter never responds to the packet
• the response is corrupted and when the Receiver checks for it, it cannot be found.

The problem is that this waiting is done in the UI thread and that's what causes the tool to hang. We're going to run this with the remote debugger and try to find out exactly what's happening.

[peterwvj]

We should probably change the sending/receiving of the breakpoint to use a job (another thread) so that it does not block the UI.