8000 fix unsupported breakpoint at method entry/exit or class by andxu · Pull Request #129 · microsoft/java-debug · GitHub
[go: up one dir, main page]

Skip to content

fix unsupported breakpoint at method entry/exit or class#129

Merged
andxu merged 27 commits intomasterfrom
andxu-patch-bp
Mar 6, 2018
Merged

fix unsupported breakpoint at method entry/exit or class#129
andxu merged 27 commits intomasterfrom
andxu-patch-bp

Conversation

@andxu
Copy link
Contributor
@andxu andxu commented Dec 11, 2017

Add location type check to avoid breakpoint on method/field which will never be hit in current implementation.

Add location type check to avoid breakpoint on method/field which will never be hit in current implementation.
@andxu
Copy link
Contributor Author
andxu commented Dec 11, 2017

testforstephen
testforstephen previously approved these changes Dec 11, 2017
update lines to the next line which is valid for breakpoint
IBreakpoint[] added = manager.setBreakpoints(AdapterUtils.decodeURIComponent(sourcePath), toAdds, bpArguments.sourceModified);
for (int i = 0; i < bpArguments.breakpoints.length; i++) {
// check whether the breakpoint has already been processed, otherwise the same breakpoint might be installed more than once.
// if class name is null, then this breakpoint is not valid, we doesn't need to install it or update hit count for it.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we doesn't -> we don't

10BC0
if (lines[i] == locator.getLineLocation()) {
// Add location type check to avoid breakpoint on method/field which will never be hit in current implementation.
if (locator.getLocationType() == ValidBreakpointLocationLocator.LOCATION_LINE) {
if (lines[i] != locator.getLineLocation()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just assign anyway to simplify the logic

@akaroml
Copy link
Member
akaroml commented Dec 12, 2017

I'm not sure about the purpose of this pull request. Let's sync more tomorrow.

testforstephen
testforstephen previously approved these changes Dec 21, 2017
// When the final valid line location is same as the original line, that represents it's a valid breakpoint.
if (lines[i] == locator.getLineLocation()) {
// Add location type check to avoid breakpoint on method/field which will never be hit in current implementation.
if (locator.getLocationType() == ValidBreakpointLocationLocator.LOCATION_LINE) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update the javadoc for getFullyQualifiedName() because the behavior is changed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In line 143, we have a todo item that indicates future support of moving breakpoint location to a valid one. Please remove the comments if you just implemented this.

@andxu andxu requested a review from akaroml March 5, 2018 03:17
yaohaizh
yaohaizh previously approved these changes Mar 5, 2018

// Compute the breakpoints that are newly added.
List<IBreakpoint> toAdd = new ArrayList<>();
Set<IBreakpoint> toAdd = new HashSet<>();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to replace list with set?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in previous code, the breakpoint line will never be changed, invalid breakpoint will be marked with null class name, thus the breakpoint in toAdd will never be the same, while in new design, the line number may be changed, eg:

  1. // a
  2. // b
  3. c++;

if we use ArrayList, addBreakpointsInternally in the following code will add three same breakpints to this.breakpoints, which will bring duplicate ones in this.breakpoints

for (int i = 0; i < bpArguments.breakpoints.length; i++) {
// check whether the breakpoint has already been processed, otherwise the same breakpoint might be installed more than once.
// if class name is null, then this breakpoint is not valid, we don't need to install it or update hit count for it.
if (processedBreakpoints.contains(toAdds[i]) || added[i].className() == null) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BreakpointManager checks for duplicate breakpoints. Why do we need to check again?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

eg: the following code
1. // a
2. // b
3. c++;

if we set all breakpoints for the 3 lines, manager.setBreakpoints will return an 3-element array all with the same breakpoint line # 3, when process the first breakpoint on line 1, actually we are installing breakpoint on line 3, so the line 2, and line 3 breakpoints will not be processed again.

@andxu andxu changed the title Add location type check on breakpoint move breakpoint to the next valid line if current line is not Mar 6, 2018
// When the final valid line location is same as the original line, that represents it's a valid breakpoint.
if (lines[i] == locator.getLineLocation()) {
// Add location type check to avoid breakpoint on method/field which will never be hit in current implementation.
if (locator.getLocationType() == ValidBreakpointLocationLocator.LOCATION_LINE) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In line 143, we have a todo item that indicates future support of moving breakpoint location to a valid one. Please remove the comments if you just implemented this.

// Add location type check to avoid breakpoint on method/field which will never be hit in current implementation.
if (locator.getLocationType() == ValidBreakpointLocationLocator.LOCATION_LINE) {
// update lines to the next line which is valid for breakpoint
lines[i] = locator.getLineLocation();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Modifying what's passed in is not recommended. Please add an override to accept an extra parameter for the modified line numbers.

// Add location type check to avoid breakpoint on method/field which will never be hit in current implementation.
if (locator.getLocationType() == ValidBreakpointLocationLocator.LOCATION_LINE) {
// update lines to the next line which is valid for breakpoint
lines[i] = locator.getLineLocation();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed, we only support line breakpoint for now.

@andxu andxu changed the title move breakpoint to the next valid line if current line is not fix unsupported breakpoint at method entry/exit or class Mar 6, 2018
andxu added 2 commits March 6, 2018 13:03
…to set breakpoint will not report to our lang server immediately
Copy link
Member
@akaroml akaroml left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perfect! Thank you.

@andxu andxu merged commit 700637c into master Mar 6, 2018
@andxu andxu deleted the andxu-patch-bp branch March 6, 2018 06:36
@andxu andxu mentioned this pull request Mar 12, 2018
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants

0