Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 339468

Summary: [Crossfire] after one step the into/over/out buttons are disabled
Product: [WebTools] JSDT Reporter: Grant Gayed <grant_gayed>
Component: DebugAssignee: Michael Rennie <Michael_Rennie>
Status: RESOLVED FIXED QA Contact: Michael Rennie <Michael_Rennie>
Severity: normal    
Priority: P3 CC: thatnitind
Version: unspecified   
Target Milestone: 3.3 M7   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
fix none

Description Grant Gayed CLA 2011-03-10 02:09:41 EST 
- connect to a remote Crossfire server
- set a breakpoint, hit it
- step into or over once
  -> the current line and variables update accordingly, but the into/over/out buttons at the top of the Debug view are left disabled, so a second step cannot be done
Comment 1 Michael Rennie CLA 2011-03-25 17:41:57 EDT 
I dug into this one a bit and found that when connected to FF / FB after we send the continue request with into / next / out we get a success response immediately followed by an onResume event, which causes the debugger to resume (disabling the buttons because the debugger is resumed).

I think the crossfire server should not be sending an onResume event in this case, since we get the success response from our request. I can't think of a case where the actual resume would be delayed (like the suspend request can be). I will open a bug against crossfire for more discussion about this.
Comment 2 Grant Gayed CLA 2011-03-25 17:51:04 EDT 
Agreed, onResume should not happen in this case.

The problem also happens with the IE server, and it's not sending this event, so there's a different cause in this case.  FF/FB would probably also hit this if the inappropriate onResume event was not being sent.
Comment 3 Michael Rennie CLA 2011-03-25 17:58:10 EDT 
I opened http://code.google.com/p/fbug/issues/detail?id=4288 to track what
crossfire is doing while stepping.
Comment 4 Michael Rennie CLA 2011-04-21 17:48:10 EDT 
Created attachment 193890 [details]
fix

I found a few issues that contributed to this problem:

1. the onResume / onBreak were not properly processed in the order crossfire sent them, which would get our model in a bad state
2. an onResume event had the bad habit of then sending a continue request from our client

The patch maintains the proper ordering for received events and does not send a continue request following an onResume event
Comment 5 Michael Rennie CLA 2011-04-21 17:48:52 EDT 
applied patch to HEAD