EFAULT, EPIPE errors on Big Sur on Apple Silicon (M1)

[andreialecu]

• Version: 15.5.0
• Platform: Darwin Kernel Version 20.2.0: Wed Dec 2 20:40:21 PST 2020; root:xnu-7195.60.75~1/RELEASE_ARM64_T8101 arm64
• Subsystem: streams(?)

What steps will reproduce the bug?

Using node 15.5.0 compiled for arm64.

➜ node -p process.arch
arm64

I'm baffled that I couldn't find anything related to this yet, and I'm not sure whether it's a nodejs bug or something else.

While running nodejs apps that use network or file streams it seems that they very frequently break with errors like EPIPE or EFAULT.

For example, a recent crash:

Error: read EFAULT
    at Pipe.onStreamRead (node:internal/stream_base_commons:213:20)
    at Pipe.callbackTrampoline (node:internal/async_hooks:131:14)
Emitted 'error' event on Socket instance at:
    at emitErrorNT (node:internal/streams/destroy:188:8)
    at emitErrorCloseNT (node:internal/streams/destroy:153:3)
    at processTicksAndRejections (node:internal/process/task_queues:80:21) {
  errno: -14,
  code: 'EFAULT',
  syscall: 'read'
}

This also happens quite a lot in the nodejs subsystem used in VSCode: microsoft/vscode#113410 (see various screenshots attached there)

I haven't verified if it happens in Rosetta emulation.

How often does it reproduce? Is there a required condition?

Very often, at least once every 10-60 minutes.

I don't have a specific reproduction, but I've seen it happen when something like tsc --watch reinitiates a compilation based on file system changes. It also happens randomly in simple expressjs servers that don't watch the file system, but just keep a connection to a mongodb server.

What is the expected behavior?

More stability.

What do you see instead?

Frequent errors.

Additional information

If I can run with some sort of flag that produces an useful crash dump, let me know of the instructions and I'll do it asap.

[andreialecu]

Only other mention of this I could find is here: desktop/desktop#11258 which is also from an Electron app.

Electron uses node ~12 though. I don't believe it to be isolated to 15.

[andreialecu]

Similar error when a file change event restarts tsc compilation (using tsc-watch):

(using yarn v2 here, hence the unusual stack trace)

TypeError: Cannot read property 'map' of undefined
    at Stream.<anonymous> (/Users/andreialecu/Work/x/x-monorepo/.yarn/$$virtual/tsc-watch-virtual-c03da97c37/0/cache/tsc-watch-npm-4.2.9-f898a4f291-b1c2a2d295.zip/node_modules/tsc-watch/lib/killer.js:24:69)
    at Stream.emit (node:events:376:20)
    at Socket.reemit (/Users/andreialecu/Work/x/x-monorepo/.yarn/cache/duplexer-npm-0.1.2-952c810235-5c2ccea7c8.zip/node_modules/duplexer/index.js:85:16)
    at Socket.emit (node:events:376:20)
    at emitErrorNT (node:internal/streams/destroy:188:8)
    at emitErrorCloseNT (node:internal/streams/destroy:153:3)
    at processTicksAndRejections (node:internal/process/task_queues:80:21)
The terminal process "/bin/zsh '-c', 'yarn run apigql:dev'" terminated with exit code: 1.

Seems to be the same underlying problem.

[andreialecu]

Possibly also related, via the official eslint extension in vscode (I'm not sure if this runs via Electron and its node 12.18.3 or the locally installed node 15.5):

ERR Request textDocument/codeAction failed with message: Cannot read .eslintignore file: /Users/andreialecu/.../.eslintignore
Error: EFAULT: bad address in system call argument, read: Error: Request textDocument/codeAction failed with message: Cannot read .eslintignore file: /Users/andreialecu/.../.eslintignore
Error: EFAULT: bad address in system call argument, read
	at /Users/andreialecu/.vscode-insiders/extensions/dbaeumer.vscode-eslint-2.1.14/client/out/extension.js:1:52031
	at /Users/andreialecu/.vscode-insiders/extensions/dbaeumer.vscode-eslint-2.1.14/client/out/extension.js:1:52325
	at Immediate.<anonymous> (/Users/andreialecu/.vscode-insiders/extensions/dbaeumer.vscode-eslint-2.1.14/client/out/extension.js:1:52690)
	at processImmediate (internal/timers.js:456:21)

[andreialecu]

(friendly ping @aduh95, noticed some relevant nodejs macOS arm64 commits)

[aduh95]

Sorry I can't really help you there, I haven't experience any of the problems described above 🤷‍♂️

[JvManuel]

I also experienced this error. I am using M1 macbook pro right now and I haven't experience this kind of error before when I am using Macbook pro 2015 and Linux. I still don't know how to fix this issue tho. When my program stopped, I just rerun my program.

[ashveen]

Had to switch to pm2 for automatic restart on my development M1 Mac mini because the EFAULT happens so often.
It is still very annoying to have these micro outage during development.

Might even go with cluster mode to ensure there's always and instance up.

[andreialecu]

In my initial post I mentioned:

If I can run with some sort of flag that produces an useful crash dump, let me know of the instructions and I'll do it asap.

Perhaps we could help figure it out because it's fairly reproducible. It's possible it's a libuv issue though.

[andreialecu]

One other possibly relevant piece of information. I've seen relatively frequent crashes of various other executables with SIGILL. Especially VSCode arm64's extension host process crashes frequently with that code. More about that here: microsoft/vscode#113410

It seems that the crashes occur more frequently while memory pressure is high and swapping is occuring.

I'm not sure if SIGILL is related to these EFAULT based crashes, but there's a report that describes SIGILL occuring during page faults here:

https://openradar.appspot.com/FB8922558

Also potentially relevant is this issue on the Go issue tracker: golang/go#42774

They were able to find a solution for it in golang/go@7f688d1

[andreialecu]

Update: I replaced my 8GB of RAM Mac Mini M1 with a 16GB one and I haven't seen any single crash in a couple of days. In particular I haven't seen any SIGILL crashes in VSCode, and mostly no EFAULT errors either by nodejs apps (maybe one in two days, vs several every hour on the 8GB RAM machine).

The issue reported in my comment above mentions:

In the wild, the bug occurs most readily on a system under heavy load (particularly, memory pressure).

Seems like a macOS bug, but it appears that node could implement a workaround if Apple doesn't fix it: libuv/libuv#3095 (comment)

[tobspr]

+1 to this issue, I'm facing this issue in nodemon which makes the process crash every 1-3 restarts, as well as some external libraries like imagemin-pngquant. Is there anything we can do to help tracking down the issue? (MacBook Pro M1, 8GB ram)