Confusing stack trace when using --abort-on-uncaught-exception

[mmarchini]

• Version: master
• Platform: OS X
• Subsystem: errors

When using --abort-on-uncaught-exception, all lines in the stack trace appear as 1:1 instead of the actual line and column numbers.

function main() {
  throw new Error();
}

main();

If we run the above script, we'll get:

$ node e.js
/Users/mmarchini/workspace/nodejs/node/e.js:2
  throw new Error();
  ^

Error
    at main (/Users/mmarchini/workspace/nodejs/node/e.js:2:9)
    at Object.<anonymous> (/Users/mmarchini/workspace/nodejs/node/e.js:5:1)
    at Module._compile (module.js:652:30)
    at Object.Module._extensions..js (module.js:663:10)
    at Module.load (module.js:565:32)
    at tryModuleLoad (module.js:505:12)
    at Function.Module._load (module.js:497:3)
    at Function.Module.runMain (module.js:693:10)
    at startup (bootstrap_node.js:191:16)
    at bootstrap_node.js:612:3

But if we run it with --abort-on-uncaught-exception, the result is quite different (for example, main (./e.js:1:1) instead of main (./e.js:2:9)):

Uncaught Error

FROM
main (/Users/mmarchini/workspace/nodejs/node/e.js:1:1)
Object.<anonymous> (/Users/mmarchini/workspace/nodejs/node/e.js:1:1)
Module._compile (module.js:1:1)
Object.Module._extensions..js (module.js:1:1)
Module.load (module.js:1:1)
tryModuleLoad (module.js:1:1)
Function.Module._load (module.js:1:1)
Function.Module.runMain (module.js:1:1)
startup (bootstrap_node.js:1:1)
bootstrap_node.js:1:1
[1]    94600 illegal hardware instruction  node --abort-on-uncaught-exception e.js

At first I thought it was a V8 bug, but running the same script with d8 gives the expected result:

Uncaught Error

FROM
main (e.js:2:3)
e.js:5:1

Maybe it's something related to our modules system? cc @nodejs/modules

[addaleax]

This is a regression, introduced somewhere in v8.2.1...v8.3.0 – most likely #14574 (V8 5.8 → V8 6.0).

/cc @nodejs/v8

[benjamingr]

Does that mean that since V8 6 (about a year) stack traces were broken with --abort-on-uncaught-exception? Would be interesting to see how many people actually use the flag and how.

[misterdjules]

@benjamingr

Would be interesting to see how many people actually use the flag and how.

When aborting on uncaught errors, I usually don't look only at the stack trace that is outputted by V8. Instead I usually rely on getting the call stack from the resulting core dump. It is still confusing if they're inconsistent with each other.

I've also not used node > 6.x in production yet.

[targos]

Note that Windows is not affected.

[mmarchini]

Bisecting v8.2.1...v8.3.0 I got 44ad55d (#14574) as the first bad commit.

[mmarchini]

Interesting, with ./node --always-opt --abort-on-uncaught-exception -e "throw new Error()" I got the correct output:

$ ./node --always-opt --abort-on-uncaught-exception -e "throw new Error()"
Uncaught Error

FROM
[eval]:1:1
Script.runInThisContext (vm.js:88:20)
Object.runInThisContext (vm.js:285:38)
Object.<anonymous> ([eval]-wrapper:6:22)
Module._compile (internal/modules/cjs/loader.js:689:30)
evalScript (internal/bootstrap/node.js:563:27)
startup (internal/bootstrap/node.js:1:1)
bootstrapNodeJSCore (internal/bootstrap/node.js:596:3)
[1]    53989 illegal hardware instruction  ./node --always-opt --abort-on-uncaught-exception -e "throw new Error()"

Seems to be a problem with interpreted functions and AbstractCode::SourcePosition, because the ByteArray passed to SourcePositionTableIterator in this function has length() = 0. @nodejs/v8 any thoughts on this? Seems to be a V8 bug.