Node.js v24.14.0 (linux-arm64) crashes with heap memory corruption / double free or corruption (out) on aarch64 — possible allocator bug in ARM64 build

[Latebloomingcrabapple]

Body:

Environment

Field	Value
Node.js version	v24.14.0
OS / Arch	Linux aarch64
Package	node-v24.14.0-linux-arm64
libc	glibc (system default on aarch64)

---

Description

On aarch64 Linux, Node.js v24.14.0 (linux-arm64 build) consistently produces a fatal heap memory error at runtime:

double free or corruption (out)
Aborted (core dumped)

This is not isolated to a specific user-space package or application — the crash occurs across multiple unrelated Node.js projects, suggesting the root cause lies within the Node.js runtime itself (V8 heap, libuv, or the bundled memory allocator) rather than in application-level code.

The error pattern — double free or corruption (out) — is characteristic of a heap allocator violation, where a memory region is freed more than once or a write overflows a heap chunk boundary. On ARM64, this class of bug is sometimes triggered by alignment assumptions or allocator behavior that differs from x86_64.

---

Steps to Reproduce

1. Install node-v24.14.0-linux-arm64 on an aarch64 Linux machine.
2. Create a minimal Node.js project:

   mkdir test-crash && cd test-crash
   npm init -y
   npm install express   # or any package with native deps

3. Run any script:

   node index.js

4. Observe crash:

   double free or corruption (out)
   Aborted (core dumped)
   

---

Expected Behavior

Node.js v24.14.0 on linux-arm64 should run stably without heap corruption errors under normal workloads.

---

Actual Behavior

The process aborts with a double free or corruption (out) signal on aarch64. The crash is:

• Consistent — reproducible across multiple projects and invocations.
• Architecture-specific — behavior has not been observed on x86_64 with the same Node.js version.
• Not application-specific — occurs regardless of which Node.js project is run.

---

Suspected Root Cause

This crash pattern is consistent with one or more of the following:

• V8's heap allocator making unsafe memory assumptions specific to ARM64 pointer or alignment behavior.
• A regression in libuv on the aarch64 build introduced in v24.x.
• The bundled tcmalloc / partition allocator exhibiting undefined behavior under aarch64's memory model (e.g., related to LSE atomics or 16KB page size on certain ARM64 kernels).
• Possible glibc version mismatch between the build environment and the target system.

---

Additional Context

• No crash occurs when the npm cache is cleared before each run (npm cache clean --force), which suggests a corrupted or misaligned memory state may be accumulating across processes, possibly via shared memory segments or cache-related file I/O on arm64.
• A stack trace / core dump analysis would be highly valuable — willing to provide one if guidance on capturing it is given.
• Suggested next step: compare the arm64 allocator path in V8 between v22.x (LTS) and v24.x to identify any behavioral change on aarch64.

---

Is this a regression?

Unknown — this is the first version of Node.js tested on this aarch64 machine. Testing against Node.js v22.x (LTS) on the same system would help confirm whether this is a v24-specific regression.

[Renegade334]

There's a reason why we have a bug template – please use it in the future. Can you confirm what environment/distro you're running on (not Android, by any chance?) and provide the output of uname -a as a minimum. Testing to see if this reproduces on other versions would also be helpful.

When you say "run any script" – what are you actually running? Is this just a blank file, or are you actually executing code when this triggers?

[MikeMcC399]

In a related post on npm/cli#9118 it says that the issue occurs when executing npm install. Since these are basic functions that are working reliably elsewhere, there may be a hardware error or basic compatibility issue with the system in question. First it needs an answer about which environment is actually in use.

[Latebloomingcrabapple]

我们之所以提供错误报告模板是有原因的——请以后使用它。请问您能否确认一下您运行的系统环境/发行版（请问不是安卓系统吗？），并uname -a至少提供一些输出信息。如果能测试一下这个问题是否在其他版本上也会出现，那就更好了。

当你说“运行任意脚本”时——你实际运行的是什么？这只是一个空白文件，还是当它触发时，你实际执行的是代码？

The relevant system is described in the post; you may not have checked it carefully.

[MikeMcC399]

@Latebloomingcrabapple

The relevant system is described in the post; you may not have checked it carefully.

Please give some additional information about the following:

1. The output of running uname -a on your system
2. The name and version number of your operating system. An example: would be "Ubuntu 24.04.4 LTS"
3. The model name of the hardware you are running under. For example: "HP EliteBook Ultra G1q Next Gen AI PC"
4. If you are running the operating system directly on "bare metal" or if you are running in a virtualized environment such as Docker

Without this it will be difficult to assist you further.