915434 - [jsdbg2] Can't set breakpoints on valid lines

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P3)

Description

[Till Schneidereit [:till]]

Instead, the breakpoint is set several lines down.

STR:

1. visit http://www.areweflashyet.com/shumway/examples/inspector/inspector.html?rfile=../Box2DFlashAS3/demo.swf
2. open the debugger
3. in the debugger, navigate to embed.js:117
4. try setting breakpoints in any of the lines from 125 to 140

124 and before are ok, but from 125 onward, the breakpoint is set on 141, instead.

Comment 1

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Attachment: adds logging

This is a bug with the Debugger api, where both 
|D.S.p.getAllColumnOffsets| and |D.S.p.getLineOffsets| are failing to find any offsets for the given line, even though we know that there should be offsets there.

This patch adds logging that shows the above problem. See the logging in |TA__findClosestOffsetMappings|.

Eddy, Jim: any idea why we might not be finding offsets for lines that definitely have code?

Comment 2

[Jim Blandy :jimb]

I wonder if this isn't the same as bug 911065?

Comment 3

[Thibault Nélis]

FWIW, I see this on another codebase.

Oddly, setting the breakpoint the first time *sometimes* appears to work; it is displayed correctly and breaks at the right instruction.  Resuming execution works fine.

After reloading once* however, the interpreter is paused on the very last line ("});", the end of an AMD module).  The blue breakpoint dot is still correctly displayed.  What's interesting is that the script crashes for reasons that seem completely unrelated after resuming execution: undefined variable in our codebase *and* "too much recursion" in a third-party codebase that I would trust not to cause that kind of issue in such a use-case (requirejs-2.1.9:129)**.  I can't rule out a race condition in our codebase, but if I may I'd like to suggest that the bug might also cause the flow to be modified (like a jump).  Indeed I can't reproduce the application crash in other browsers, even by setting the breakpoint at the exact same places (intended line and last line).

* It worked after exactly one reload once (then changed behavior as described after the second reload), though I can't reproduce this.  Often times, it doesn't work at all, not even once.  Again, looks racy.

** There is at least one try where I didn't see the second error, only the first.

After that, if I remove and re-add the breakpoint at the same line, I see the behavior described here where the breakpoint is set a few lines below (in my case, a variable assignation four lines below -- not the last line).  Note that I can see the blue dot appear a few milliseconds at the intended line before being instantly moved below.  At this point, after reloading the program breaks at the line where the breakpoint is displayed (the wrong line, but again, not the end) and resuming execution does *not* crash.  Clicking on the intended line again doesn't remove the breakpoint.  Clicking on the wrong line where the breakpoint is displayed does remove it.

The only way to reproduce the first behavior again (breakpoint at the right line, actual break at the end, script crash) is to restart the browser.

Another interesting bit:  The browser process doesn't exit cleanly if execution is paused -- although there is no error message.  It sits there consuming a very stable 12-13% of CPU until I explicitly kill it.  (Might be an unrelated bug.)


I know that's a lot of uninterpreted facts, but hopefully one or two might be useful.

Comment 4

[Jim Blandy :jimb]

Nick, you're pretty confident this is a Debugger API bug? Would you happen to have a JS shell-only way to reproduce this? If I had that, it would make it much easier for me to begin work on it.

Comment 5

[Jim Blandy :jimb]

Oh, bug 911065 does have JS-only steps to reproduce. Let's get that fixed and then see if this falls with it.

Comment 6

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

(In reply to Jim Blandy :jimb from comment #4)
> Nick, you're pretty confident this is a Debugger API bug? Would you happen
> to have a JS shell-only way to reproduce this? If I had that, it would make
> it much easier for me to begin work on it.

Well it might be a different part of spidermonkey, but my findings in comment 1 are pretty damning.

Comment 8

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 9

[Logan Smyth [:loganfsmyth]]

I'm gonna mark this closed due to the work in https://bugzilla.mozilla.org/show_bug.cgi?id=1518661. If we come across more examples, we can always reopen or file new issues.