Node/yarn segmentation fault on redhat aarch64 #3202
Comments
|
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 |
|
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: And then @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 ... |
|
LIke 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 |
|
Also with a debug build of node v14.15.4 I get a crash just by trying to start npm: |
|
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) |
Yeah, I've not been able to reproduce this docker either. Thanks. I'm going to set up a machine internally and see if I can reproduce this. |
|
@sxa Thanks for investigating this. I've been able to reproduce the issue thanks to your above description (I'm using CentOS8.2.2004). I'll take a closer look at this now. |
|
@liza-mae Could you provide the output of the following command from the system in question: $ getconf PAGESIZE |
|
Hi @danbev it is |
|
That's interesting, a quick look around suggests that all my Ubuntu/aarch64 systems seem to have a pagesize of |
Original commit message:
[heap] Make maximum regular code object size a runtime value.
Executable V8 pages include 3 reserved OS pages: one for the writable
header and two as guards. On systems with 64k OS pages, the amount of
allocatable space left for objects can then be quite smaller than the
page size, only 64k for each 256k page.
This means regular code objects cannot be larger than 64k, while the
maximum regular object size is fixed to 128k, half of the page size. As
a result code object never reach this limit and we can end up filling
regular pages with few large code objects.
To fix this, we change the maximum code object size to be runtime value,
set to half of the allocatable space per page. On systems with 64k OS
pages, the limit will be 32k.
Alternatively, we could increase the V8 page size to 512k on Arm64 linux
so we wouldn't waste code space. However, systems with 4k OS pages are
more common, and those with 64k pages tend to have more memory available
so we should be able to live with it.
Bug: v8:10808
Change-Id: I5d807e7a3df89f1e9c648899e9ba2f8e2648264c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460809
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#70569}
Refs: nodejs/help#3202
|
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 |
Original commit message:
[heap] Make maximum regular code object size a runtime value.
Executable V8 pages include 3 reserved OS pages: one for the writable
header and two as guards. On systems with 64k OS pages, the amount of
allocatable space left for objects can then be quite smaller than the
page size, only 64k for each 256k page.
This means regular code objects cannot be larger than 64k, while the
maximum regular object size is fixed to 128k, half of the page size. As
a result code object never reach this limit and we can end up filling
regular pages with few large code objects.
To fix this, we change the maximum code object size to be runtime value,
set to half of the allocatable space per page. On systems with 64k OS
pages, the limit will be 32k.
Alternatively, we could increase the V8 page size to 512k on Arm64 linux
so we wouldn't waste code space. However, systems with 4k OS pages are
more common, and those with 64k pages tend to have more memory available
so we should be able to live with it.
Bug: v8:10808
Change-Id: I5d807e7a3df89f1e9c648899e9ba2f8e2648264c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460809
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#70569}
Refs: nodejs/help#3202
Original commit message:
[heap] Make maximum regular code object size a runtime value.
Executable V8 pages include 3 reserved OS pages: one for the writable
header and two as guards. On systems with 64k OS pages, the amount of
allocatable space left for objects can then be quite smaller than the
page size, only 64k for each 256k page.
This means regular code objects cannot be larger than 64k, while the
maximum regular object size is fixed to 128k, half of the page size. As
a result code object never reach this limit and we can end up filling
regular pages with few large code objects.
To fix this, we change the maximum code object size to be runtime value,
set to half of the allocatable space per page. On systems with 64k OS
pages, the limit will be 32k.
Alternatively, we could increase the V8 page size to 512k on Arm64 linux
so we wouldn't waste code space. However, systems with 4k OS pages are
more common, and those with 64k pages tend to have more memory available
so we should be able to live with it.
Bug: v8:10808
Change-Id: I5d807e7a3df89f1e9c648899e9ba2f8e2648264c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460809
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#70569}
Refs: nodejs/help#3202
Original commit message:
[heap] Make maximum regular code object size a runtime value.
Executable V8 pages include 3 reserved OS pages: one for the writable
header and two as guards. On systems with 64k OS pages, the amount of
allocatable space left for objects can then be quite smaller than the
page size, only 64k for each 256k page.
This means regular code objects cannot be larger than 64k, while the
maximum regular object size is fixed to 128k, half of the page size. As
a result code object never reach this limit and we can end up filling
regular pages with few large code objects.
To fix this, we change the maximum code object size to be runtime value,
set to half of the allocatable space per page. On systems with 64k OS
pages, the limit will be 32k.
Alternatively, we could increase the V8 page size to 512k on Arm64 linux
so we wouldn't waste code space. However, systems with 4k OS pages are
more common, and those with 64k pages tend to have more memory available
so we should be able to live with it.
Bug: v8:10808
Change-Id: I5d807e7a3df89f1e9c648899e9ba2f8e2648264c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460809
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#70569}
PR-URL: #37225
Refs: nodejs/help#3202
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Stewart X Addison <sxa@redhat.com>
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Original commit message:
[heap] Make maximum regular code object size a runtime value.
Executable V8 pages include 3 reserved OS pages: one for the writable
header and two as guards. On systems with 64k OS pages, the amount of
allocatable space left for objects can then be quite smaller than the
page size, only 64k for each 256k page.
This means regular code objects cannot be larger than 64k, while the
maximum regular object size is fixed to 128k, half of the page size. As
a result code object never reach this limit and we can end up filling
regular pages with few large code objects.
To fix this, we change the maximum code object size to be runtime value,
set to half of the allocatable space per page. On systems with 64k OS
pages, the limit will be 32k.
Alternatively, we could increase the V8 page size to 512k on Arm64 linux
so we wouldn't waste code space. However, systems with 4k OS pages are
more common, and those with 64k pages tend to have more memory available
so we should be able to live with it.
Bug: v8:10808
Change-Id: I5d807e7a3df89f1e9c648899e9ba2f8e2648264c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460809
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#70569}
PR-URL: #37225
Refs: nodejs/help#3202
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Stewart X Addison <sxa@redhat.com>
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Building the console on top of the tectonic-console-builder (for CI and OKD) is blocked on arm64 by nodejs/help#3202 as we build the image on rhel8, shipping a 64k pagesize kernel. The fix landed in nodejs from v14.17.0.
Building the console on top of the tectonic-console-builder (for CI and OKD) is blocked on arm64 by nodejs/help#3202 as we build the image on rhel8, shipping a 64k pagesize kernel. The fix landed in nodejs from v14.17.0.
Building the console on top of the tectonic-console-builder (for CI and OKD) is blocked on arm64 by nodejs/help#3202 as we build the image on rhel8, shipping a 64k pagesize kernel. The fix landed in nodejs from v14.17.0.
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?
The text was updated successfully, but these errors were encountered: