Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

util: fix isInsideNodeModules inside error #20266

Closed
wants to merge 1 commit into from

Conversation

apapirovski
Copy link
Member

@apapirovski apapirovski commented Apr 24, 2018

When isInsideNodeModules gets called while already processing
another stack trace, V8 will not call prepareStackTrace again.
This used to cause Node.js to just crash — fix it by checking
for expected return type of the stack (Array).

Fixes: #20258

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines

When isInsideNodeModules gets called while already processing
another stack trace, V8 will not call prepareStackTrace again.
This used to cause Node.js to just crash — fix it by checking
for expected return type of the stack (Array).
@apapirovski apapirovski added the buffer Issues and PRs related to the buffer subsystem. label Apr 24, 2018
@apapirovski apapirovski requested review from jasnell and addaleax April 24, 2018 23:04
@nodejs-github-bot nodejs-github-bot added the util Issues and PRs related to the built-in util module. label Apr 24, 2018
@apapirovski
Copy link
Member Author

Copy link
Member

@addaleax addaleax left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

if (!/^\/|\\/.test(filename))
continue;
return kNodeModulesRE.test(filename);
if (Array.isArray(stack)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe just invert the conditional to make here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I just wanted to keep the semantics exactly the same as before so return false; after everything, even if it's strictly-speaking unreachable from the for loop.

if (!/^\/|\\/.test(filename))
continue;
return kNodeModulesRE.test(filename);
if (Array.isArray(stack)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this sufficient to fix the original bug with ts-node? That was triggering at original line 360 with frame existing but getFileName being undefined, which is inside the for loop. That seems to imply to me that it would not be fixed by an Array.isArray check. I'm not sure how to grab this to confirm that though.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it's because if stack is not an array then it's a string so it iterates on individual characters which obviously don't have getFileName.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be good to throw in an extra check for the existence of getFileName as a function, just to be extra safe.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm... but we do want to minimize how much work we do here. There are two possibilities here:

  1. We call our own prepareStackTrace which returns an Array with the correct data.

  2. We are already in an error handling mode and just get the default stack trace which is a string, not an array.

There's no real alternative here. We can't end up calling a user-provided prepareStackTrace or something similar. I did think about it before making this check.

@Trott
Copy link
Member

Trott commented Apr 24, 2018

node-test-commit-smartos re-run: https://ci.nodejs.org/job/node-test-commit-smartos/17152/

@Trott Trott added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Apr 24, 2018
@Trott
Copy link
Member

Trott commented Apr 25, 2018

node-test-commit-aix re-run: https://ci.nodejs.org/job/node-test-commit-aix/14493/

@apapirovski
Copy link
Member Author

Thanks everyone. Landed in 16aee38

@apapirovski apapirovski deleted the fix-20258 branch April 28, 2018 06:21
apapirovski added a commit that referenced this pull request Apr 28, 2018
When isInsideNodeModules gets called while already processing
another stack trace, V8 will not call prepareStackTrace again.
This used to cause Node.js to just crash — fix it by checking
for expected return type of the stack (Array).

PR-URL: #20266
Fixes: #20258
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
MylesBorins pushed a commit that referenced this pull request May 4, 2018
When isInsideNodeModules gets called while already processing
another stack trace, V8 will not call prepareStackTrace again.
This used to cause Node.js to just crash — fix it by checking
for expected return type of the stack (Array).

PR-URL: #20266
Fixes: #20258
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
@MylesBorins MylesBorins mentioned this pull request May 8, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. buffer Issues and PRs related to the buffer subsystem. util Issues and PRs related to the built-in util module.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

node 10.0.0 with ts-node throws a TypeError in isInsideNodeModules when an error is thrown by user code
7 participants