Unbound Breakpoint - setBreakpoints: RangeError: Start offset -2097234512 is outside ...
marvin-enthus opened this issue · 11 comments
Hi Team,
after upgrading our development environment we also started suffering on the "Unbound Breakpoint" issue.
Setting debug.javascript.usePreview: false
brings them back to life.
So we started searching and analyzing (learned from the other tickets that there might be name / path discrepancies) so we created the debug trace and dropped it in the analyzer - but we discovered something we are not able to find anything on.
The message we found is:
Error processing setBreakpoints: RangeError: Start offset -2097234512 is outside the bounds of the buffer at new Uint8Array (<anonymous>) at l._parseMappings (/Users/home/Applications/Development/Visual Studio Code.app/Contents/Resources/app/extensions/ms-vscode.js-debug/src/extension.js:36:20720) at l._getMappingsPtr (/Users/home/Applications/Development/Visual Studio Code.app/Contents/Resources/app/extensions/ms-vscode.js-debug/src/extension.js:36:20590) at /Users/home/Applications/Development/Visual Studio Code.app/Contents/Resources/app/extensions/ms-vscode.js-debug/src/extension.js:36:24379 at Object.withMappingCallback (/Users/home/Applications/Development/Visual Studio Code.app/Contents/Resources/app/extensions/ms-vscode.js-debug/src/extension.js:36:30500) at l.generatedPositionFor (/Users/home/Applications/Development/Visual Studio Code.app/Contents/Resources/app/extensions/ms-vscode.js-debug/src/extension.js:36:24300) at a.generatedPositionFor (/Users/home/Applications/Development/Visual Studio Code.app/Contents/Resources/app/extensions/ms-vscode.js-debug/src/extension.js:15:2633633) at Object.t.getOptimalCompiledPosition (/Users/home/Applications/Development/Visual Studio Code.app/Contents/Resources/app/extensions/ms-vscode.js-debug/src/extension.js:1:54161) at b.predictBreakpoints (/Users/home/Applications/Development/Visual Studio Code.app/Contents/Resources/app/extensions/ms-vscode.js-debug/src/extension.js:15:2555663)
Any hints what we hit here and how to get it working without disabling the preview debugger?
The logfile:
vscode-debugadapter-0.json.gz
VS Code Version: 1.50.1
Thanks & Bye,
Chris
This is coming from the source-map library and means you probably have invalid sourcemaps in your project. If that's not the case / to report the issue upstream, are you able to share the any sourcemap files you have in your project?
Hi. Thank you for pointing this out. We started doing some initial investigation on it (by trying to open / visualize the files by source-map reader like http://evanw.github.io/source-map-visualization/ ) but we didn't see any obvious problem. But we're no map file experts. We could provide the source map for further analyzing, but we would prefer sending it to you by PM instead of posting it publicly. Would this be okay with you?
As some side notes (for others finding this ticket):
It's an electron app written in typescript. Everything is build & packed with webpack.
Some related versions from our package.json:
"typescript": "3.9.7",
"webpack": "4.44.1",
"webpack-cli": "3.3.12",
"webpack-dev-server": "3.11.0",
"webpack-node-externals": "2.5.2",
In the package-lock we have a wide vary source-map versions listed. I assume webpack uses the version from @types/webpack-sources 0.1.8
mapping tosource-map 0.6.1
Sure, you can sent it to connor@xbox.com
The files have been sent to you, thank you for your help.
On Friday I did some further investigations without any success getting the breakpoints working:
- Tried to upgrade webpack - didn't work as we also use Angular 10 which is tied to webpack 4.4x.x. But it seems angular's
@angular-devkit/build-angular
pulls insource-map 0.7.3
which is also the current version innode_modules/source-map
- As this is a 'debug / development mode' build there is no minimizing / uglifying enabked. I tried to enable minify / uglify bit it seems to make no difference (expect different negative pointer ID's)...
So I'm currently running out of ideas...
I didn't get anything from you. If you sent the sourcemaps as an attachment, can you try uploading them somewhere and sending a link instead? Sometimes out mail filter can be aggressiive.
I just sent a mail with a download link in it - hopefully this gets through ;)
Thanks for the logs. Those maps look okay.... in the linked commit I've added some additional missing error handling for the thing you're running into. What I think is probably happening is that it's picking up and trying to parse a different sourcemap from somewhere that's breaking things.
In the next nightly build which will have the fix, the location of the sourcemap and corresponding error should be written to the Debug Console view, and the presence of a broken sourcemap should no longer prevent you from being able to set breakpoints.
Hi,
thank you for the update. I've tried it and breakpoints are working again! Great ;)
But when I tried to step through the code the debugger was not stepping through the lines as expected / usual - it was jumping around in an unpredictable manner. The "instruction pointer" even showed up in comments. So there might be an additional offset issue when doing stepping.
A side node: In the launch.json
i've configured an outFiles
as suggested by other tickets to my compile output path:
"outFiles": [
"${workspaceFolder}/dist/**/*.js"
]
So I would expect the debugger only searches source maps at this point. And when I understand the logs right it also only loaded main_bundle.js.map from this place...
Do you have any idea why stepping with the debugger resulted in this 'unpredictable jumping around'? How can we do further investigations on this?
Attached is the tace log from the debugging session.
Thanks & Bye,
Chris
Thanks for the update Christian -- this is generally a result of the sourcemaps not matching up correctly with your source files.
Just glancing at some of the files in the logs you previously emailed to me, it smells like whatever TypeScript loader you have set up in webpack isn't creating sourcemaps -- so webpack itself is making sourcemaps, but they're for the generated code rather than the TS source code. E.g. this is what webpack sees as the "source" file in one case:
Generally for this you need to set "sourceMap": true
in your tsconfig -- though depending on how you have it set up in webpack this may be different.
I was having a similar problem with webpack + ts-loader giving me unbound breakpoints in vscode. Turns out the webpack generated sourcemap was using my aliased paths. This fixed the issue for me:
devtool: 'source-map',
output: {
devtoolModuleFilenameTemplate: '[absolute-resource-path]'
},
Might be relevant for future people arriving here from Google
Thanks for pointing out the issues with the source map's. I haven't had the time to dig into it but it sounds plausible so I'm closing this issue right now. Thanks for the fix!