Repository navigation
Segmentation Faults on node 20.19.6 #60882
Description
Version
v20.19.6
Platform
> uname -a
Linux 79f27e4c6e8d 5.14.0-427.26.1.el9_4.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Jul 17 15:51:13 EDT 2024 x86_64 Linux
Subsystem
No response
What steps will reproduce the bug?
It is a bit difficult to explain...
Long story short: We were using this official docker image:
https://hub.docker.com/layers/library/node/20-alpine3.22/images/sha256-bcd88137d802e2482c9df3cdec71e0431857ebbbdba6973776b5593214056d86
And on Nov 25, 2025 at 9:39 pm it got updated, and we traced the change to this commit:
nodejs/docker-node@edcdc15
(node env was bumped from 20.19.5 to 20.19.6)
The problem:
Since our internal release that used this container version (2 days after the change got pushed), we started to see segmentation faults on our workloads.
For context: We use AWS ECS services with tasks running on Fargate and Fargate Spot instances.
The only lead we have is the exit code of the containers: 139
How often does it reproduce? Is there a required condition?
! There are no application logs that could indicate other issues/errors and after our investigations we ruled out the possibility that this error comes from application code.
As for the timing of these occurrences, it seems completely random. Sometimes workers would crash with exit code 139 3-30 seconds after launch, sometimes after a few minutes, other times no crash at all.
What is the expected behavior? Why is that the expected behavior?
No crashes!
What do you see instead?
This is the formatted error (from AWS ECS) we see for different tasks in our workloads:
Exit Code: 139
Reason: N/A
Stopped Reason: Essential container in task exited
Stop Code: EssentialContainerExited
Additional information
Our workaround was to switch to using the previous node version (20.19.5):
https://hub.docker.com/layers/library/node/20.19.5-alpine3.22/images/sha256-be8d32d651b3e0c9c2b28fdc1d3888408125d703232013cff955344d052027e5
This change fixed all our issues with containers crashing randomly with exit code 139.
I thought I should report this behavior since it might need further investigation.
Activity
raduqq commentedon Nov 28, 2025
very interesting and important issue, due to it causing faults in the system in a truly unexpected way.
marco-ippolito commentedon Nov 29, 2025
Without a reproduction is pretty much impossible to investigate. You can take a look at the changes in v20.19.6 https://github.com/nodejs/node/pull/60784/files
rkmax commentedon Nov 29, 2025
I have been fighting around segmentation faults without noticing it was a recent patch 🤯 . I was using the version 20.19-alpine3.21 without issues I just locked the version to 20.19.5-alpine3.21
Yes, but replicate this is truly hard, I tried everything and never was able to replicate it. only happens on GCP on cloud run. on VMs and local containers never happens
emmanuelnk commentedon Dec 1, 2025
We also experienced this exact same issue on ECS Fargate. We had to either downgrade to 20.19.5 or upgrade to Node 24. I believe there is a regression here. Please see #56236
Not sure how to reproduce but I'll try to think of a way (maybe docker container running 20.19.6) with a regular Express app.
richardlau commentedon Dec 1, 2025
If this is related to #56236 then #57910 needs a manual backport to land on Node.js 20 as it did not cherry-pick cleanly.
pauloshea42 commentedon Jan 22, 2026
We are facing the same issue on ECS Fargate.
trivikr commentedon Jul 16, 2026
This can be closed as Node.js 20 reached its End-of-Life (EOL) on April 30, 2026.
And the fix in #57910 was published in v22.16.0