Skip to content

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

Closed
Closed
Confusing stack trace when using --abort-on-uncaught-exception#21988
Labels
post-mortemIssues and PRs related to Node.js postmortem diagnostics.v8 engineIssues and PRs related to the V8 dependency.

Description

@mmarchini
mmarchini
opened on Jul 26, 2018
  • 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

  1. addaleax
    added
    v8 engineIssues and PRs related to the V8 dependency.
    post-mortemIssues and PRs related to Node.js postmortem diagnostics.
    on Jul 26, 2018

  2. addaleax commented on Jul 26, 2018

    @addaleax
    addaleax
    on Jul 26, 2018
    Member

    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

  3. benjamingr commented on Jul 27, 2018

    @benjamingr
    benjamingr
    on Jul 27, 2018
    Member

    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.

  4. misterdjules commented on Jul 27, 2018

    @misterdjules
    misterdjules
    on Jul 27, 2018

    @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.

  5. targos commented on Jul 29, 2018

    @targos
    targos
    on Jul 29, 2018
    Member

    Note that Windows is not affected.

  6. mmarchini commented on Aug 3, 2018

    @mmarchini
    mmarchini
    on Aug 3, 2018
    ContributorAuthor

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

  7. mmarchini commented on Aug 9, 2018

    @mmarchini
    mmarchini
    on Aug 9, 2018
    ContributorAuthor

    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.

  8. Drieger
    added 2 commits that reference this issue on Sep 10, 2018

    deps: cherry-pick 9a23bdd from upstream V8

    8b7def0

    deps: backport 9a23bdd from upstream V8

    94402b0

  9. 4 remaining items

  10. Drieger commented on Sep 17, 2018

    @Drieger
    Drieger
    on Sep 17, 2018
    Contributor

    @misterdjules @mmarchini I opened #22910 to backport to v10.x

  11. BethGriggs
    added a commit that references this issue on Oct 2, 2018

    deps: backport 9a23bdd from upstream V8

    9e2077a

  12. Trott commented on Nov 13, 2018

    @Trott
    Trott
    on Nov 13, 2018
    Member

    Should this be closed?

  13. mmarchini commented on Nov 13, 2018

    @mmarchini
    mmarchini
    on Nov 13, 2018
    ContributorAuthor

    IIRC, yes (we can reopen otherwise).

  14. mmarchini
    closed this as completedon Nov 13, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    post-mortemIssues and PRs related to Node.js postmortem diagnostics.v8 engineIssues and PRs related to the V8 dependency.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions