Repository navigation
Node/yarn segmentation fault on redhat aarch64 #3202
Description
Activity
It would be good to clarify what versions of Node.js you are using.
Are you installing the versions from the Node.js downloads page on both RHEL and Ubuntu? If not are you using the versions of Node.js that come bundled into Ubuntu and RHEL?
@danbev had investigated what sounds like a similar failure with yarn on aarch64. If you are recreating this on the binaries you downloaded from: https://nodejs.org/en/download/, then possibly its a different issue or the fix applied to the 14.x stream did not fix the original issue (@danbev confirmed that a commit was in the 14.x stream intended to fix that issue and it looks like that was landed included in the latest community 14.x release).
If instead you are recreating on the binaries that come with RHEL, then I'm confused because as far as I know there is no v14.15.4 available yet as part of the RHEL containers/rpms.
Hi @mhdawson,
You are correct the binaries that come with RHEL do work but that is I believe it lands on a node 12 version.
What I have is a shell script that downloads the node package based on the node version specified for our project, which is 14.15.4 and I use the same package on both Ubuntu and RHEL.
This is the link I am using: https://nodejs.org/dist/v14.15.4/node-v14.15.4-linux-arm64.tar.gz
It does work on Ubuntu, so is this distribution not supported for RHEL yet?
Please let me know. Thanks!
@liza-mae I was trying to understand which binaries you were using. Those binaries should run/work on RHEL even though they are different from the ones packaged into the RHEL distributions.
@danbev can you look to see if this is the same problem that you investigated before? From what was in the PR/issues I think we thought the issue was fixed on 14.x (although with a different fix than on earlier versions) but from what @liza-mae is reporting that may not be the case.
Looking at v8.h in 14.15.4 the above fix is included, so if this is the version being used then this could be a different issue. I don't have an environment set up with
aarch64(this is something that the RHEL team at work usually provides us with when there is an issue to be investigated) so I don't have a quick way of verifying this I'm afraid. I can't tell by the output alone, it does look similar and I would have guessed it was the same but can't say for sure.I had a quick try in a CentOS8.3 docker container and couldn't reproduce this problem. Let me know if I've not followed the steps propely that you used to reproduce:
curl https://nodejs.org/dist/v14.15.4/node-v14.15.4-linux-arm64.tar.gz | tar xpfz - cd node-v14.15.4-linux-arm64/ export PATH=$PWD:$PATH npm install -g yarnAnd then
yarnappears to run ok:[sxa@5148ffbb568c ~]$ yarn add express yarn add v1.22.10 info No lockfile found. [1/4] Resolving packages... [2/4] Fetching packages... [3/4] Linking dependencies... [4/4] Building fresh packages... success Saved lockfile. success Saved 29 new dependencies. info Direct dependencies └─ express@4.17.1 info All dependencies ├─ accepts@1.3.7 ├─ array-flatten@1.1.1 ├─ body-parser@1.19.0 ├─ content-disposition@0.5.3 ├─ cookie-signature@1.0.6 ├─ cookie@0.4.0 ├─ destroy@1.0.4 ├─ ee-first@1.1.1 ├─ express@4.17.1 ├─ finalhandler@1.1.2 ├─ forwarded@0.1.2 ├─ inherits@2.0.3 ├─ ipaddr.js@1.9.1 ├─ media-typer@0.3.0 ├─ merge-descriptors@1.0.1 ├─ methods@1.1.2 ├─ mime-db@1.45.0 ├─ mime@1.6.0 ├─ ms@2.0.0 ├─ negotiator@0.6.2 ├─ path-to-regexp@0.1.7 ├─ proxy-addr@2.0.6 ├─ raw-body@2.4.0 ├─ safer-buffer@2.1.2 ├─ serve-static@1.14.1 ├─ type-is@1.6.18 ├─ unpipe@1.0.0 ├─ utils-merge@1.0.1 └─ vary@1.1.2 Done in 5.51s. [sxa@5148ffbb568c ~]$@danbev Based on the above it may not be trivial to reproduce it in Docker.
Interesting - tried with a CentOS8.2.2004 on AWS us-west-2 like yours and was able to reproduce ...
Reacted by liza-maeLIke the OP I've found that it works on all versions up to latest v12 (v12.20.1), segfaults on v13.0.0 and later as far as I can tell on those systems (Before and after performing a
yum updateto pull it up to8.3.2011and kernel4.18.0-240.10.1.el8_3makes no difference)Also with a debug build of node v14.15.4 I get a crash just by trying to start npm:
[sxa@ip-172-31-61-154 bin]$ npm # # Fatal error in ../deps/v8/src/heap/memory-chunk.cc, line 50 # Debug check failed: kMaxRegularHeapObjectSize <= memory (131072 vs. 65536). # # # #FailureMessage Object: 0xffffc1118e48 Trace/breakpoint trap (core dumped)I can also reproduce the crash on a (non-docker, non-AWS) CentOS 7.9/aarch64 system. I can also confirm it does NOT crash using code from HEAD (16.0.0)
Reacted by liza-maeThat's interesting, a quick look around suggests that all my Ubuntu/aarch64 systems seem to have a pagesize of
4096set, but as you suggest on CentOS it's65536(even when the total memory size on the machine is the same)Looks like the upgrade to V8 8.7.220 in the master branch fixed whatever the problem was which is why it doesn't crash in the master branch, but that won't be formally released until v16.0.0, so your PR seems like a good candidate for the next v14.x release
- added a commit that references this issue
on Apr 6, 2021
I have a cross post I did here in the yarn repo, but we did not get any answers, so I wanted to ask here also since the node version impacts whether or not the yarn command fails, as noted above.
Some core dump info below, can someone help?