Node.js appears to give incorrect column numbers in it's stack traces. The problem is magnified when running uglified/minified code (because all the code tends to be on a single line). Here's a trivial example that show's the problem:
code:
(function() { var functions = { test: function() { throw new Error('testing'); } }; functions.test(); })();
stacktrace:
/Users/mbrocato/WebstormProjects/StackTest/test.js:1
dirname) { (function() { var functions = { test: function() { throw new Error(
^
Error: testing
at Object.functions.test (/Users/mbrocato/WebstormProjects/StackTest/test.js:1:120)
at /Users/mbrocato/WebstormProjects/StackTest/test.js:1:157
at Object.<anonymous> (/Users/mbrocato/WebstormProjects/StackTest/test.js:1:167)
at Module._compile (module.js:460:26)
at Object.Module._extensions..js (module.js:478:10)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Function.Module.runMain (module.js:501:10)
at startup (node.js:129:16)
at node.js:814:3
The correct column number is 58. Column 120 is actually past the end of the file (the last column is 108).
I've tested this using 4.0.0 and 0.12.7. Both yield the same results.
If you look at the error, you'll see that (function() is not the actual start to the code being executed on that line.
Your module/code gets wrapped before being executed. Does this happen when it's on its' own line?
Node wraps everything inside a function. This PR may be relevant - https://github.com/nodejs/node-v0.x-archive/pull/25342
Removing the iife produces the same problem.
Code:
var functions = { test: function() { throw new Error('testing'); } }; functions.test();
trace:
/Users/mbrocato/WebstormProjects/StackTest/test.js:1
__filename, __dirname) { var functions = { test: function() { throw new Error(
^
Error: testing
at Object.functions.test (/Users/mbrocato/WebstormProjects/StackTest/test.js:1:106)
at Object.<anonymous> (/Users/mbrocato/WebstormProjects/StackTest/test.js:1:143)
at Module._compile (module.js:460:26)
at Object.Module._extensions..js (module.js:478:10)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Function.Module.runMain (module.js:501:10)
at startup (node.js:129:16)
at node.js:814:3
Again, column 106 is past the end of the file (now 88)
In fact, it's as simple as:
throw new Error('test');
trace:
(function (exports, require, module, __filename, __dirname) { throw new Error(
^
Error: test
at Object.<anonymous> (/Users/mbrocato/WebstormProjects/StackTest/test.js:1:69)
at Module._compile (module.js:460:26)
at Object.Module._extensions..js (module.js:478:10)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Function.Module.runMain (module.js:501:10)
at startup (node.js:129:16)
at node.js:814:3
You're not understanding what's happening.
Your code gets wrapped by (function (exports, require, module, __filename, __dirname) { /* code */ }) which offsets your first line.
The error is correct.
If that's the case then it's a pretty leaky abstraction that makes stacktraces totally unreliable. Is there any way for node to translate traces so they are accurate to the actual source?
C:\Users\Administrator\AppData\Roaming\npm\node_modules\nvmw\node_modules\adm-zip\zipFil
e.js:66
throw Utils.Errors.INVALID_FORMAT;
^
Invalid or unsupported zip format. No END header found
how can i solve the problem
Seems the issue can be reproduced in node 6.6.0 using the simple example:
throw Error("Hello, I'm back");
/home/segrey/issues/untitled50/test.js:1
(function (exports, require, module, __filename, __dirname) { throw Error("Hello, I'm back");
^
Error: Hello, I'm back
at Error (native)
at Object.<anonymous> (/home/segrey/issues/untitled50/test.js:1:69)
at Module._compile (module.js:556:32)
...
The fix was reverted in https://github.com/nodejs/node/pull/4298 because it introduced a regression. I'll reopen this issue.
this is a very old defect, so checking some basic sanity first:
Still an issue but implementing #17396 would fix it. We're at a new enough V8 now that we could.
does anyone who is familiar with #4298 know the reason for the revert and what is the gap?
At the time, it was a V8 issue - https://bugs.chromium.org/p/v8/issues/detail?id=4620. While the issue is still open, I'm not sure what the actual status of the bug is.
I think this issue has been already fixed?
Yes, I believe so; we're using v8::ScriptCompiler::CompileFunctionInContext() now. Closing!