`fs.access` causes abort() when run in Emacs shell

[freesteph]

• Version: v6.0.0
• Platform: OSX: 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_64
• Subsystem: GNU Emacs 25.0.93.1 (might affect other clients?)

After upgrading 6.0, I can't run npm in an Emacs subshell because it crashes on any call to fs.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

[bnoordhuis]

According to the stack trace, the problem is that libuv can't spawn threads for its thread pool. Perhaps emacs sets ulimit -u too low. Does env UV_THREADPOOL_SIZE=1 npm <cmd> work?

[freesteph]

Unfortunately it still crashes. I have tried with Emacs's multi-term, ansi-term, eshell and shell and 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.access call makes the program terminates normally.

[freesteph]

Also, ulimit -u returns 709 in both my normal ZSH prompt and the Emacs-wrapped ZSH prompt.

[bnoordhuis]

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.)

[ianmcdonald]

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 node or npm init throws Abort trap: 6.

Outside of emacs with v.6.0.0, everything is cool.

Inside emacs with with v.5.9.1, everything is cool.

[bnoordhuis]

I 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?

[ericjuta]

Reporting the same problem!
Abort trap: 6 in any emacs shell with node v6.0.0 and node v6.1.0.

[evanlucas]

Confirmed on v6+ for me. https://github.com/libuv/libuv/blob/v1.x/src/unix/thread.c#L86 is returning 22.

[kouhin]

Maybe same problem.
Flycheck(with eslint) and company-tern can't work after upgrading 6.0.0 and 6.1.0

[bnoordhuis]

@evanlucas Errno 22 is EINVAL. Is it possible that rlim_cur isn't a multiple of 4096?

[evanlucas]

On my system, that is the case. rlim_cur is 8720000 for some reason

[bnoordhuis]

Okay, 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;

[evanlucas]

@bnoordhuis I'm thinking that libuv/libuv@3db07cc is what is exposing this issue. Pulling that out fixes it

[evanlucas]

ah didn't see your comment when I posted @bnoordhuis. Confirmed that applying this patch fixes the issue for me. Yay!!!