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

[mdouglass]

• Version: v10.0.0
• Platform: Darwin bigbird.local 17.5.0 Darwin Kernel Version 17.5.0: Mon Mar 5 22:24:32 PST 2018; root:xnu-4570.51.1~1/RELEASE_X86_64 x86_64

Attached sample project (which is a single ts file with just throw new Error()) when run via npm start fails with:

mdouglass$ npm start

> temp@1.0.0 start /Users/mdouglass/kixeye/km/server/temp
> ts-node index.ts

internal/util.js:360
    const filename = frame.getFileName();
                           ^

TypeError: frame.getFileName is not a function
    at isInsideNodeModules (internal/util.js:360:28)
    at showFlaggedDeprecation (buffer.js:149:8)
    at new Buffer (buffer.js:174:3)
    at Array.<anonymous> (/Users/mdouglass/kixeye/km/server/temp/node_modules/source-map-support/source-map-support.js:163:21)
    at /Users/mdouglass/kixeye/km/server/temp/node_modules/source-map-support/source-map-support.js:53:24
    at mapSourcePosition (/Users/mdouglass/kixeye/km/server/temp/node_modules/source-map-support/source-map-support.js:185:21)
    at wrapCallSite (/Users/mdouglass/kixeye/km/server/temp/node_modules/source-map-support/source-map-support.js:357:20)
    at /Users/mdouglass/kixeye/km/server/temp/node_modules/source-map-support/source-map-support.js:392:26
    at Array.map (<anonymous>)
    at Function.prepareStackTrace (/Users/mdouglass/kixeye/km/server/temp/node_modules/source-map-support/source-map-support.js:391:24)

repro-nodejs-10-throw.zip

[jasnell]

Ping @addaleax ... any ideas?

[jasnell]

This is possibly a bad interaction with make-error but I need to verify
I take that back... https://github.com/evanw/node-source-map-support/blob/master/source-map-support.js looks like a better candidate...

(heh... it would help if I actually read the entire stack track ... lol...)

[apapirovski]

I'm looking into this but anyone else is also welcome to dig in.

[tirthamazumdar]

I do have the same issue. Just now upgraded to 10.0.0 from version 8, and all my tests are failing.

internal/util.js:360
const filename = frame.getFileName();
^
TypeError: frame.getFileName is not a function
at isInsideNodeModules (internal/util.js:360:28)
at showFlaggedDeprecation (buffer.js:149:8)
at new Buffer (buffer.js:174:3)

[jasnell]

@tirthamazumdar ... are you also using source-map-support?

[apapirovski]

@jasnell It just comes with ts-node. source-map-support is definitely what's causing it but still not sure how to resolve.

[tirthamazumdar]

@jasnell yes I am also using source-map-support.. Just now compiled typescript into javascript and the running directly the javascript tests the problem goes away.
Looks like issue is with source-map-support

[jasnell]

Ok, @apapirovski @addaleax ... looks like the transpiler here is mucking around with the generation of the stack frames in a way the check in core did not anticipate. I think we should likely do in this case is have isInsideNodeModules() return false if it cannot reliably process the stack. That would cause the Buffer deprecation warning to emit in this case, but that's not really a bad thing.

[jasnell]

Attempting to put together a standalone repo test case now but not having much luck yet.

[apapirovski]

@jasnell Here's the simplest possible reproduction:

Error.prepareStackTrace = (err, trace) => new Buffer();

new Error().stack;

The error happens because V8 won't call prepareStackTrace if it's already preparing a stack trace (recursive call). I don't think we can fix so, as you said, we'll just have to skip the check and emit the warning in those cases.

PR coming up.

[addaleax]

Ouch. Yes, that makes sense – thanks for figuring this out so quick. I am surprised though, it might be nice if V8 supported this – after all, the other Error object does come from a difference VM Context, so one wouldn’t expect that kind of interaction … @nodejs/v8?

[jasnell]

I had seen the Buffer use there but hadn't realized it was a recursive check. Good catch.

[bnoordhuis]

the other Error object does come from a difference VM Context

Not sure I follow. If it's about @apapirovski's test case, what other Error object and VM context?

[apapirovski]

Not sure I follow. If it's about @apapirovski's test case, what other Error object and VM context?

isInsideNodeModules generates a stack-trace yielding function in a VM to get the proper stack trace. See lib/internal/util.js around line ~340. It also uses prepareStackTrace which in V8 is guarded against being called recursively