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)
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.
Comment 1•11 years ago
|
||
Can i dig into this?
Reporter | ||
Comment 2•11 years ago
|
||
(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.
Reporter | ||
Updated•11 years ago
|
Priority: -- → P3
Reporter | ||
Updated•11 years ago
|
Comment 3•11 years ago
|
||
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???
Reporter | ||
Comment 4•11 years ago
|
||
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!
Reporter | ||
Comment 6•11 years ago
|
||
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.
Reporter | ||
Comment 8•10 years ago
|
||
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.
Reporter | ||
Comment 9•10 years ago
|
||
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
Updated•6 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•