Repository navigation
fs.access causes abort() when run in Emacs shell #6563
Description
Activity
According to the stack trace, the problem is that libuv can't spawn threads for its thread pool. Perhaps emacs sets
ulimit -utoo low. Doesenv UV_THREADPOOL_SIZE=1 npm <cmd>work?Unfortunately it still crashes. I have tried with Emacs's
multi-term,ansi-term,eshellandshelland they all crash on this program:var fs = require('fs'); fs.access('/usr/local/bin/node', fs.X_OK, function (er) { console.log('this never prints out'); });
removing the
fs.accesscall makes the program terminates normally.Also,
ulimit -ureturns 709 in both my normal ZSH prompt and the Emacs-wrapped ZSH prompt.If the stack trace is still the same, then emacs must be doing something that prevents node/libuv from operating normally.
I could make libuv print a nicer error message or trudge on in single-thread mode but that's a workaround more than anything else (and it met with some opposition from other maintainers last time I proposed it.)
When running v6.0.0 in emacs 24.5.1 (the most current version from Homebrew on OS X), I face a similar situation.
Running any node command from a terminal or shell bash session within emacs, even just running
nodeornpm initthrowsAbort trap: 6.Outside of emacs with v.6.0.0, everything is cool.
Inside emacs with with v.5.9.1, everything is cool.
Reacted by fromheten, Eric Juta, Kou, Martin Yrjölä, Stephen Way and Alice HernandezI wonder if it's because of 204f3a8 where we bumped MACOSX_DEPLOYMENT_TARGET from 10.5 to 10.7. What happens when you revert that commit and rebuild?
Reporting the same problem!
Abort trap: 6 in any emacs shell with node v6.0.0 and node v6.1.0.Confirmed on v6+ for me. https://github.com/libuv/libuv/blob/v1.x/src/unix/thread.c#L86 is returning
22.Maybe same problem.
Flycheck(with eslint) and company-tern can't work after upgrading 6.0.0 and 6.1.0@evanlucas Errno 22 is EINVAL. Is it possible that
rlim_curisn't a multiple of 4096?On my system, that is the case.
rlim_curis 8720000 for some reasonOkay, that explains it. Does this patch fix it?
diff --git a/deps/uv/src/unix/thread.c b/deps/uv/src/unix/thread.c index c35bc92..56bb8a4 100644 --- a/deps/uv/src/unix/thread.c +++ b/deps/uv/src/unix/thread.c @@ -28,6 +28,7 @@ #include <sys/time.h> #include <sys/resource.h> /* getrlimit() */ +#include <unistd.h> /* getpagesize() */ #include <limits.h> @@ -82,10 +83,13 @@ int uv_thread_create(uv_thread_t *tid, void (*entry)(void *arg), void *arg) { if (pthread_attr_init(attr)) abort(); - if (lim.rlim_cur != RLIM_INFINITY && - lim.rlim_cur >= PTHREAD_STACK_MIN) { - if (pthread_attr_setstacksize(attr, lim.rlim_cur)) - abort(); + if (lim.rlim_cur != RLIM_INFINITY) { + /* pthread_attr_setstacksize() expects page-aligned values. */ + lim.rlim_cur -= lim.rlim_cur % (rlim_t) getpagesize(); + + if (lim.rlim_cur >= PTHREAD_STACK_MIN) + if (pthread_attr_setstacksize(attr, lim.rlim_cur)) + abort(); } #else attr = NULL;
@bnoordhuis I'm thinking that libuv/libuv@3db07cc is what is exposing this issue. Pulling that out fixes it
ah didn't see your comment when I posted @bnoordhuis. Confirmed that applying this patch fixes the issue for me. Yay!!!
6 remaining items
- added a commit that references this issue
on May 17, 2016 - added a commit that references this issue
on Oct 18, 2016 - added a commit that references this issue
on Oct 17, 2017
Darwin steph-mbp 15.4.0 Darwin Kernel Version 15.4.0: Fri Feb 26 22:08:05 PST 2016; root:xnu-3248.40.184~3/RELEASE_X86_64 x86_64After upgrading 6.0, I can't run
npmin an Emacs subshell because it crashes on any call tofs.access; I'm aware this might be Emacs-specific (works fine in iTerm + ZSH) but in the slim case this is an actual regression I'm attaching the full stacktrace from my system.node_2016-05-04-104139_Stephanes-MacBook-Pro.crash.txt