[node] fs.existsSync throws when path is not present

[marvinhagemeister]

Was playing around with vite to see what's missing to get it working. Ran into an issue where fs.existsSync unexpectedly throws when the passed path does not exist. This is particularly odd because our implementation contains a try/catch statement.

I'm unable to reproduce that in a smaller test case, so something must be different when more node modules are loaded.

Steps to reproduce:

1. Clone https://github.com/marvinhagemeister/deno-exists-sync-bug
2. Run deno task dev

Error output:

error: Uncaught NotFound: No such file or directory (os error 2): lstat '/project/node_modules/.vite'
    at Object.lstatSync (ext:deno_fs/30_fs.js:339:7)
    at Object.existsSync (ext:deno_node/_fs/_fs_exists.ts:28:14)
    at cleanupDepsCacheStaleDirs (file:///project/node_modules/.deno/vite@4.3.4/node_modules/vite/dist/node/chunks/dep-f7d05e3f.js:44801:18)
    at Timeout._onTimeout (file:///project/node_modules/.deno/vite@4.3.4/node_modules/vite/dist/node/chunks/dep-f7d05e3f.js:44103:26)
    at cb (ext:deno_node/internal/timers.mjs:37:46)
    at Object.action (ext:deno_web/02_timers.js:149:11)
    at handleTimerMacrotask (ext:deno_web/02_timers.js:66:10)
    at eventLoopTick (ext:core/01_core.js:187:21)

The error originates here https://github.com/vitejs/vite/blob/c63ba3fa08a64d75bfffa6885dc4c44875b9c5ba/packages/vite/src/node/optimizer/index.ts#L1335 .

[bartlomieju]

I hit this problem earlier this week and I'm flabbergasted as to what is happening since that error is caught. I will try to fix it.

[aapoalas]

I wonder if this isn't about the uncatchable fast errors again?

[bartlomieju]

I wonder if this isn't about the uncatchable fast errors again?

@aapoalas that's a good pointer - changed lstatSync to get rid of fast op but it appears the problem still persist. It makes no sense to me what's going on here.

[aapoalas]

I tried turning #[op] into #[op(fast)] for existsSync's op and the build still went off without a hitch. I'm not sure if that's the fast-attribute not correctly asserting that fast optimisation happened or if the op is successfully being optimised.

If it is, then likely the ops macro is doing it automatically even when not asked to: The macro is after all set to always create fast ops if possible.

[bartlomieju]

@aapoalas I just changed return type of op_lstat_sync to be Result<(i32, SerializableStat), AnyError> - this should definitely kick us off the fast op because this return type is not fast call compatible.

That said, your observation is valid and I already raised it to @littledivy.

[bartlomieju]

I've been debugging this thing for the past 3 days.

I can reliably reproduce the problem and managed to trace it. The problem is that I cannot reproduce it with either deno release, I cannot reproduce it with a local release build, I can only reproduce it with local debug build.

@marvinhagemeister could you give more info how you reproduced it? Did you use official deno release or did you build it yourself? What OS and arch did this happen?

[bartlomieju]

The root cause appears to be that the synchronous op_lstat_sync is called during responding from an async op to JavaScript in JsRuntime::do_single_realm_js_event_loop_tick.

op_lstat_sync throws an error which calls scope.throw_exception. The exception is caught in JavaScript, but somehow a TryCatchScope we have in do_single_realm_js_event_loop_tick reports that it has caught an error. This in turn causes to create a Rust error which bubbles up all the way to the main function and thus erroring the whole process.

I don't yet understand why TryCatchScope would do that and why is it only manifesting in debug builds for me.

[marvinhagemeister]

@bartlomieju Can confirm that it only happens with debug builds for me. Release builds compiled from git as well as the official 1.33.2 are fine. I'm on macOS Ventura with an M1 chip. I can reproduce the error in debug builds on both M1 and M1 Pro chips.

[bartlomieju]

Ooof, that's good to hear though not ideal! I'll try to chase down this problem, but happy to hear that's it's not the highest priority.

[bartlomieju]

Unfortunately the above rusty_v8 upgrade didn't fix the problem, however I identified the problem and will cut another rusty_v8 release that will fix it later tonight.