[3.2.14] Hard coded breakpoint

[LisaAlmarode]

In v3.2.15 on alsea (win7), and in 3.2.14 on wallowa (win10), I get this when I attempt to reproduce issue #884. I cannot completely iterate the block before this occurs; this is a breaking problem.

In v3.2.13 on alsea, I get a much more pleasant "we're done!" message.

[ericwinger]

While gp faults, according to Dolphin code comments, can theoretically happen in most any external library call, we are seeing them when trying to update the method source view of the debugger. I couldn't reproduce it but it's possible that the gui has gone away when an update for the debugger comes back to the client. There is one service update method that does an update of the view which was seen in the issue report. To fix the bug, we check to see of the view is open first, exiting if it's not. Then we guard against a gp fault in the udpate. Since we are likely reading corrupted memory, not writing, resuming should be ok.

[LisaAlmarode]

Still occurs in 3.2.16. I note that it mostly happens when I'm clicking quickly on the arrow/continue button. If I pause and count to 5 before clicking on the arrow/continue button, I can complete the iterations. But it's pretty slow to refresh and enable the arrow button already, so I hate to see it slowed down still further...

[ericwinger]

My understanding is that no Jadeite.errors file is produced. Similar to what was given in this issue report, can you @LisaAlmarode add a screen shot of the dialog box shown in 3.2.16?

[ericwinger]

Found a glaring problem with the BrowserUpdate semaphore that likely accounts for some of the problems. Closing for retest.