Closed Bug 927158 Opened 11 years ago Closed 10 years ago

source mapped breakpoints getting hit at the wrong location

Categories

(DevTools :: Debugger, defect, P3)

x86
macOS
defect

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: fitzgen, Unassigned)

References

(Blocks 1 open bug)

Details

STR:

1. Open up http://requirejs.org/bugs/main-sourcemap/
2. Make sure "show original sources" is enabled
3. Set a breakpoint in b.js, line 5 (var name = "b";)
4. Refresh

Expected:

Break on b.js, line 5.

Actual:

Break on a.js, line 4.

---------------------

I looked at the source map in http://sokra.github.io/source-map-visualization/ and it looks pretty good. We should be able to debug this file properly.
Can i dig into this?
(In reply to Hubert B Manilla from comment #1)
> Can i dig into this?

This bug is probably somewhat hairy. Source map bugs tend to kind of suck because of all the layers that it involves. This bug could be in our frontend code, our backend code, the source map library, or spidermonkey and you'll need to trace url/line/column locations through each of those layers. Personally, I suspect that spidermonkey is giving us a weird column number and it is then getting source mapped to the wrong part of the code.

I'm not saying you shouldn't dive into this if you want to, but just making sure you're aware of what is involved in fixing this bug. If you still want it, I'll assign you.
Priority: -- → P3
See Also: → 956466
Thanks for the insight into this. I would still like to look into it, but you can hold off assigning it to me atm (just I case someone want it first), I'll like to spend more time tracking the issue n see if I can get a wip patch first

Also I tested your example above, but my result was slightly different.
I get a break  on b.js, on line 6 instead. Not sure it something has changed???
Ok, cool, just wanted to make sure you knew what you were getting into.

Quite possible something has changed. We should stop on line 5 in b.js.

A good starting place might be to turn the test case into an xpcshell test and then start adding logging throughout the server and just running the new test to see the logs instead of having to fire up a whole browser.

Good luck!
Depends on: 984696
Been digging into this on bug 968086.

The Debugger API only returns offsets that are entry points to the line, however in both the case of this bug and bug 968086, the JS object code is minified. This means there are fewer bytecodes returned from the API than if it were prettified from the start. Result is we set it on the closest available one (see _findClosestOffsetMappings), which tends to be pretty far off in minified code.
Just a note that after bug 968086 landed, debugging and stepping through pretty printed code is much better now.

Unfortunately, the STR in comment 0 now results in no BP getting hit. Leaving this bug open for now to investigate that.
Ok, this is working now. Not sure exactly which revision fixed it, but I suspect it was the patch in bug 1000967.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.