Repository navigation
Confusing stack trace when using --abort-on-uncaught-exception #21988
Description
- 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
Activity
addaleax commentedon Jul 26, 2018
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 commentedon Jul 27, 2018
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 commentedon Jul 27, 2018
@benjamingr
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 commentedon Jul 29, 2018
Note that Windows is not affected.
mmarchini commentedon Aug 3, 2018
Bisecting v8.2.1...v8.3.0 I got 44ad55d (#14574) as the first bad commit.
mmarchini commentedon Aug 9, 2018
Interesting, with
./node --always-opt --abort-on-uncaught-exception -e "throw new Error()"I got the correct output:Seems to be a problem with interpreted functions and
AbstractCode::SourcePosition, because theByteArraypassed toSourcePositionTableIteratorin this function haslength()= 0. @nodejs/v8 any thoughts on this? Seems to be a V8 bug.deps: cherry-pick 9a23bdd from upstream V8
deps: backport 9a23bdd from upstream V8
4 remaining items
Drieger commentedon Sep 17, 2018
@misterdjules @mmarchini I opened #22910 to backport to v10.x
deps: backport 9a23bdd from upstream V8
Trott commentedon Nov 13, 2018
Should this be closed?
mmarchini commentedon Nov 13, 2018
IIRC, yes (we can reopen otherwise).