Repository navigation
EFAULT, EPIPE errors on Big Sur on Apple Silicon (M1) #36826
Description
Activity
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.
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.
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)(friendly ping @aduh95, noticed some relevant nodejs macOS arm64 commits)
Sorry I can't really help you there, I haven't experience any of the problems described above 🤷♂️
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.
Reacted by IronbenHad 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.
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
libuvissue though.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#113410It seems that the crashes occur more frequently while memory pressure is high and swapping is occuring.
I'm not sure if
SIGILLis related to theseEFAULTbased crashes, but there's a report that describesSIGILLoccuring 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
Reacted by GautierUpdate: 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
SIGILLcrashes in VSCode, and mostly noEFAULTerrors 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)
+1 to this issue, I'm facing this issue in
nodemonwhich makes the process crash every 1-3 restarts, as well as some external libraries likeimagemin-pngquant. Is there anything we can do to help tracking down the issue? (MacBook Pro M1, 8GB ram)Reacted by prin, Gautier, Jesse Rosalia, thomaspease, Jffarge, Lucas Pose, Linus Unnebäck, Quentin Aslan, bl-ue, Hamza Baig and 5 moreI'm also having a seemingly related issue, with running this program in the background (on an M1 MacBook Pro - 16GB):
https://github.com/karlhorky/do-not-disturb-during-zoom-macos
Here's the error I get:
node:events:353 throw er; // Unhandled 'error' event ^ Error: read EFAULT at Pipe.onStreamRead (node:internal/stream_base_commons:213:20) 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' }I find that it often has happened during sleep / wake cycles, but that could also just be coincidence.
Wonder if the Big Sur 11.2 update that just appeared will help. Just installed now.
53 remaining items
I'm having this issue with MacBook Pro M1, 2020, 8Gb ram, 2020.
events.js:377 throw er; // Unhandled 'error' event ^ Error: read EFAULT at Pipe.onStreamRead (internal/stream_base_commons.js:209:20) Emitted 'error' event on Socket instance at: at emitErrorNT (internal/streams/destroy.js:106:8) at emitErrorCloseNT (internal/streams/destroy.js:74:3) at processTicksAndRejections (internal/process/task_queues.js:82:21) { errno: -14, code: 'EFAULT', syscall: 'read' } error Command failed with exit code 1.Node version
v14.18.0@micaiah-effiong could you please share a testcase?
And macOS version.Also see #36826 (comment)
@ChALkeR I'm using Monterrey 12.0.1. Tried node v17.1.0, 16.13.0 and 14.18.1 with no success. The application I'm running is meteor framework and they launched a recent version 2.5.1 compatible with M1 chips, but didn't work anyways too. It doesn't seem to be a framework problem (I suppose).
I have no idea how to solve this and it seems to be related to memory usage? Anyways I'm following up with this issue to see if someone shows up with the same issue. I also tried to use nvm and didn't solve my problem too.
@marcotas Thanks for the OS info! Could you try to reproduce the issue on #36826 (comment)?
That's a stand-alone script with no deps.If it doesn't reproduce, please try adding memory pressure (e.g. via the bottom part of that comment).
Also: does the setup with Meteor spawn child processes at all or not?
@micaiah-effiong could you please share a testcase? And macOS version.
Also see #36826 (comment)
I using a macOS Big Sur
version 11.1.
I am running an express server in a dev environment am I use nodemon to restart the server. After a couple of restarts, it crashes with the errorevents.js:377 throw er; // Unhandled 'error' event ^ Error: read EFAULT at Pipe.onStreamRead (internal/stream_base_commons.js:209:20) Emitted 'error' event on Socket instance at: at emitErrorNT (internal/streams/destroy.js:106:8) at emitErrorCloseNT (internal/streams/destroy.js:74:3) at processTicksAndRejections (internal/process/task_queues.js:82:21) { errno: -14, code: 'EFAULT', syscall: 'read' } error Command failed with exit code 1.@micaiah-effiong This was known on 11.1 due to a macOS issue and it was previously thought that it was resolved in macOS 11.4.
But there are new reports on 12 above, though I wasn't yet able to reproduce.
It would be great if someone would be able to either reproduce with the testcase from #36826 (comment) on any macOS version >= 11.4 or share a testcase that reproduces this on a macOS version >= 11.4.@ChALkeR I wasn't able to reproduce the error with your comment you suggested. Nothing happened at all. It seems to me it's something related to websockets though. Meteor framework uses websockets a LOT so I think this might be the case. I also tried this solution in Safari but it still happening, also tried to use only chrome but didn't change anything. Unfortunately it's not something I'm able to reproduce, because I'm just facing this in a meteor framework application. I'll give any more updates if I figure out something more.
Reacted by Nikita SkovorodaReacted by Nikita Skovoroda@marcotas
Thanks! If you could provide at least some way to reproduce (e.g. a repo/setup) I could try to work from there to build a minimal testcase.A repo which has some meteor setup triggering this might also help.
Preferably without docker or any other extra parts.
Reacted by Marco Avila@marcotas to me upgrade to 12.1 fixed damn error for a while and then I started to get it again. Problem goes away after I restart my mac. So probably upgrade to 12.1 has nothing to do with problem. It's rather reboot made a difference for you and me.
Hmm. I still couldn't reproduce this, but i didn't try keeping mac active for a while.
@IlyaEremin A few qustions that might help:
- Is it the reboot or does logout/relogin help?
- Does just closing all other apps help?
- Is this perhaps memory load related?
- Is there a way to trigger this quicker after a reboot?
@marcotas to me upgrade to 12.1 fixed damn error for a while and then I started to get it again. Problem goes away after I restart my mac. So probably upgrade to 12.1 has nothing to do with problem. It's rather reboot made a difference for you and me.
@IlyaEremin I was facing the same issue sometimes until I figured out that the problem was with the
wkhtmltopdfpackage not installed on my machine using homebrew. So I just installed using homebrew and I haven't gotten this error anymore.Reacted by Ilia Eremin and Valera Olexienko@marcotas man.... this is a miracle. I'm using
wkhtmltopdfin the project I work on and this was exactly the problem. After I installed one problem disappeared. Thank you a lot!Reacted by Marco Avilatry this
watchman watch-del-all
What steps will reproduce the bug?
Using node 15.5.0 compiled for 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:
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 --watchreinitiates 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.