Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 315135 - Existing breakpoints are added and removed for no reason with new debug targets
Summary: Existing breakpoints are added and removed for no reason with new debug targets
Status: RESOLVED FIXED
Alias: None
Product: JSDT
Classification: WebTools
Component: Debug (show other bugs)
Version: 3.2   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Michael Rennie CLA
QA Contact: Simon Kaegi CLA
URL:
Whiteboard:
Keywords: performance
Depends on:
Blocks: 327019
  Show dependency tree
 
Reported: 2010-05-31 16:01 EDT by Michael Rennie CLA
Modified: 2010-10-05 16:13 EDT (History)
1 user (show)

See Also:


Attachments
proposed fix (2.06 KB, patch)
2010-10-05 16:13 EDT, Michael Rennie CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Rennie CLA 2010-05-31 16:01:27 EDT
code from HEAD

Steps:

1. set a breakpoint in a script that is loaded in the Rhino VM
2. connect the debugger to the VM
3. trace the socket communication 

Expected:

when the target connects I would expect to see a setbreakpoint request sent for the existing breakpoint, and the VMs' response

Happens:

we do send out the request, and we do get the VMs' response, but immediately following we send out a clearbreakpoint request for the bp we just requested to be set. We then get the VMs' response confirming the bp is cleared, and we then send another setbreakpoint request for the same bp we just set/removed.

Not only is this 2x the work, but we are also artificially inflating the breakpoint ids
Comment 1 Michael Rennie CLA 2010-10-05 16:13:07 EDT
Created attachment 180282 [details]
proposed fix

I found that is the breakpoint is touched in any way we hit a call-back in our debug target the kills + recreates the bp. The patch removes this behavior.
Comment 2 Michael Rennie CLA 2010-10-05 16:13:35 EDT
applied patch to HEAD