1343060 - Setting breakpoint at line X slides to wrong location if a previous breakpoint was slided to that line X

Status: RESOLVED INVALID

(DevTools :: Debugger, defect, P5)

Description

[Daniel Lehmann]

Attachment: test file

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20170201174907

Steps to reproduce:

NOTE: Cannot reproduce in GUI (debugger.html or "old debugger") because clicking at the margin for the second breakpoint will remove the first, not add another one. I can reproduce it via Remote Debugging Protocol. :yury helped me on IRC, he could also reproduce it in https://pastebin.mozilla.org/8980507

Reproduce via WebSocket RDP
1. Open test file in FF with enabled remote debugging
2. Connect to FF with wscat (or other WebSocket terminal)
$ wscat -c localhost:6080
< {"from":"root", ...} // receiving debugging server hello
3. follow the RDP ceremony, not relevant for bug
> {"to":"root","type":"listTabs"} // get list of tabs
< ... // omitted
> {"to":"server1.conn0.child1/tab1","type":"attach"} // attach to first tab
< ... // omitted
> {"to":"server1.conn0.child1/28","type":"attach"} // attach to thread
< ... // omitted
> {"to":"server1.conn0.child1/28","type":"sources"} // get list of sources
< ... // omitted
4. request a breakpoint at the comment line
> {"to":"server1.conn0.child1/30","type":"setBreakpoint","location":{"line":3},"noSliding":false} // set breakpoint at comment line, allow sliding
< {"actor":"server1.conn0.child1/32","isPending":false,"actualLocation":{"source":{"actor":"server1.conn0.child1/30","generatedUrl":null,"url":"file:///home/daniel/Documents/masterthesis/test/bugreports/ff-setBreakpoint-empty-lines/example.html","isBlackBoxed":false,"isPrettyPrinted":false,"isSourceMapped":false,"sourceMapURL":null,"introductionUrl":null,"introductionType":null},"line":4},"from":"server1.conn0.child1/30"} // correct and expected, actualLocation.line == 4
5. now request a breakpoint at the console.log() line
> {"to":"server1.conn0.child1/30","type":"setBreakpoint","location":{"line":4},"noSliding":false} // set breakpoint at console.log() call
< {"actor":"server1.conn0.child1/32","isPending":false,"actualLocation":{"source":{"actor":"server1.conn0.child1/30","generatedUrl":null,"url":"file:///home/daniel/Documents/masterthesis/test/bugreports/ff-setBreakpoint-empty-lines/example.html","isBlackBoxed":false,"isPrettyPrinted":false,"isSourceMapped":false,"sourceMapURL":null,"introductionUrl":null,"introductionType":null},"line":6},"from":"server1.conn0.child1/30"} // bug? actualLocation.line == 6, i.e. past end of script!


Actual results:

The first breakpoint request's reply
- returns a breakpoint with a new actor (which is fine)
- with actualLocation.line == 4 (which is also fine, it is the next non-empty Javascript line in the source)

The second breakpoint request's reply
- has the same actor as the first one (which is fine)
- but now has an actualLocation.line == 6, which is past the end of the script


Expected results:

The second breakpoint request's reply should have the same actualLocation as the first one, i.e. 4.

Comment 1

[Tom Tromey :tromey]

I'm giving this a low priority because it can't be seen from the GUI.

Comment 2

[Daniel Lehmann]

Attachment: Screencapture of bug appearing in GUI

Actually, I found out that the bug can be reproduced in the GUI (see video), although because of a race condition it is more probable when debugging a remote instance.

If the breakpoint in line 3 is already slided to line 4 when clicking in line 4 to set a breakpoint there, it will remove the one in 4, instead of setting a new one (which would expose the buggy behavior). For debugging a local tab, sliding will probably always be fast enough to hide the bug.

Not so when debugging a remote instance: I set up a second Firefox instance with enabled remote debugging (listen 6080 mozilla-rdp in GCLI) and connected to it via WebIDE in the first one (WebIDE -> Remote Runtime -> localhost:6080). I also artifically delayed TCP packages to force the race condition with 

$ sudo tc qdisc add dev lo root netem delay 200ms

Then, the bug is reproducible, as can be seen in the attached screencapture.

Comment 3

[Jason Laster [:jlast]]

closing as we no longer support sliding