Cannot use node on Raspberry Pi Ubuntu

[donfrigo]

• Version: v14.1.0
• Platform: Linux ubuntu 5.4.0-1008-raspi modules: adding load linked modules feature #8-Ubuntu SMP Wed Apr 8 11:13:06 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux
• Subsystem: Raspberry Pi Ubuntu

What steps will reproduce the bug?

I am trying to build a dockerfile on my Raspberry Pi 4, running arm64 Ubuntu. The same dockerfile runs fine on my main computer. The dockerfile is as follows:

FROM node:14 as builder

WORKDIR /app

COPY .client/package.json .
COPY .package-lock.json .
RUN npm install
...

Upon building this file I get the following error:

Sending build context to Docker daemon  29.35MB
Step 1/12 : FROM node:14 as builder
 ---> 70b24a2d7b95
Step 2/12 : WORKDIR /app
 ---> Using cache
 ---> 2ab48332f35b
Step 3/12 : COPY .client/package.json .
 ---> Using cache
 ---> d7009f4cfa0b
Step 4/12 : COPY .client/package-lock.json .
 ---> Using cache
 ---> 59d4f21519ed
Step 5/12 : RUN npm install
 ---> Running in 84f62d84dcbe
Aborted (core dumped)
The command '/bin/sh -c npm install' returned a non-zero code: 134

The error code of 134 refers to running out of memory on the host, but I have checked both memory and storage and there seems to be plenty of space left. What could be the issue? Thank you!

Additional information

If I run the base image manually and open a terminal, I get the following:

# node -v
v14.1.0
# npm -v
Aborted (core dumped)
# node
Aborted (core dumped)

[donfrigo]

Seems to be related to some other issue in aarch64 kernel:
https://bugzilla.redhat.com/show_bug.cgi?id=1813089

[rvagg]

I guess if it’s a setrlimit thing then that makes sense since node does that pretty early. Not sure if this is something we can deal with here unless something specific to our code or build process can be shown. Likely to be something that intersects with @bnoordhuis’ interests and expertise though if he’s intrigued.

[bnoordhuis]

Node.js uses getrlimit/setrlimit to get/set the open file descriptor limit but it's non-fatal if those system calls don't work.

@donfrigo Can you check with gdb where node -e 42 crashes exactly? bt prints a backtrace.

[ofthesun9]

@bnoordhuis
Hope I did this right:

root@b9086729348f:/# gdb /usr/local/bin/node -e 42
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "aarch64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/bin/node...done.
(gdb) run
Starting program: /usr/local/bin/node 
warning: Error disabling address space randomization: Operation not permitted
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x0000ffff92dd2df4 in __GI_abort () at abort.c:89
#2  0x000000000129c9b0 in thread_stack_size () at ../deps/uv/src/unix/thread.c:176
#3  uv_thread_create_ex (arg=0x1d39d860, 
    entry=0xa87ca0 <node::WorkerThreadsTaskRunner::DelayedTaskScheduler::Start()::{lambda(void*)#1}::_FUN(void*)>, 
    params=<synthetic pointer>, tid=0x1d39dff0) at ../deps/uv/src/unix/thread.c:236
#4  uv_thread_create (tid=0x1d39dff0, 
    entry=0xa87ca0 <node::WorkerThreadsTaskRunner::DelayedTaskScheduler::Start()::{lambda(void*)#1}::_FUN(void*)>, arg=0x1d39d860)
    at ../deps/uv/src/unix/thread.c:212
#5  0x0000000000a862bc in node::WorkerThreadsTaskRunner::WorkerThreadsTaskRunner(int) ()
#6  0x0000000000a86580 in node::NodePlatform::NodePlatform(int, v8::TracingController*) ()
#7  0x00000000009f71d0 in node::InitializeOncePerProcess(int, char**) ()
#8  0x00000000009f7650 in node::Start(int, char**) ()
#9  0x0000ffff92dc0364 in __libc_start_main (main=0x0, argc=0, argv=0x0, init=<optimized out>, fini=<optimized out>, 
    rtld_fini=<optimized out>, stack_end=<optimized out>) at libc-start.c:291
#10 0x0000000000999f8c in _start ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) 

[bnoordhuis]

Thanks, that's really helpful! That's libuv trying to look up the stack size through getrlimit(RLIMIT_STACK). I've opened libuv/libuv#2848 to work around that.