robobun 52b82cbe40 Fix: Allow napi_reference_unref to be called during GC (#22597)
## Summary
- Fixes #22596 where Nuxt crashes when building with rolldown-vite
- Aligns Bun's NAPI GC safety checks with Node.js behavior by only
enforcing them for experimental NAPI modules

## The Problem

Bun was incorrectly enforcing GC safety checks
(`NAPI_CHECK_ENV_NOT_IN_GC`) for ALL NAPI modules, regardless of
version. This caused crashes when regular production NAPI modules called
`napi_reference_unref` from finalizers, which is a common pattern in the
ecosystem (e.g., rolldown-vite).

The crash manifested as:
```
panic: Aborted
- napi.h:306: napi_reference_unref
```

## Root Cause: What We Did Wrong

Our previous implementation always enforced the GC check for all NAPI
modules:

**Before (incorrect):**
```cpp
// src/bun.js/bindings/napi.h:304-311
void checkGC() const
{
    NAPI_RELEASE_ASSERT(!inGC(),
        "Attempted to call a non-GC-safe function inside a NAPI finalizer...");
    // This was called for ALL modules, not just experimental ones
}
```

This was overly restrictive and didn't match Node.js's behavior, causing
legitimate use cases to crash.

## The Correct Solution: How Node.js Does It

After investigating Node.js source code, we found that Node.js **only
enforces GC safety checks for experimental NAPI modules**. Regular
production modules are allowed to call functions like
`napi_reference_unref` from finalizers for backward compatibility.

### Evidence from Node.js Source Code

**1. The CheckGCAccess implementation**
(`vendor/node/src/js_native_api_v8.h:132-143`):
```cpp
void CheckGCAccess() {
  if (module_api_version == NAPI_VERSION_EXPERIMENTAL && in_gc_finalizer) {
    // Only fails if BOTH conditions are true:
    // 1. Module is experimental (version 2147483647)
    // 2. Currently in GC finalizer
    v8impl::OnFatalError(...);
  }
}
```

**2. NAPI_VERSION_EXPERIMENTAL definition**
(`vendor/node/src/js_native_api.h:9`):
```cpp
#define NAPI_VERSION_EXPERIMENTAL 2147483647  // INT_MAX
```

**3. How it's used in napi_reference_unref**
(`vendor/node/src/js_native_api_v8.cc:2814-2819`):
```cpp
napi_status NAPI_CDECL napi_reference_unref(napi_env env,
                                            napi_ref ref,
                                            uint32_t* result) {
  CHECK_ENV_NOT_IN_GC(env);  // This check only fails for experimental modules
  // ... rest of implementation
}
```

## Our Fix: Match Node.js Behavior Exactly

**After (correct):**
```cpp
// src/bun.js/bindings/napi.h:304-315
void checkGC() const
{
    // Only enforce GC checks for experimental NAPI versions, matching Node.js behavior
    // See: https://github.com/nodejs/node/blob/main/src/js_native_api_v8.h#L132-L143
    if (m_napiModule.nm_version == NAPI_VERSION_EXPERIMENTAL) {
        NAPI_RELEASE_ASSERT(!inGC(), ...);
    }
    // Regular modules (version <= 8) can call napi_reference_unref from finalizers
}
```

This change means:
- **Regular NAPI modules** (version 8 and below):  Can call
`napi_reference_unref` from finalizers
- **Experimental NAPI modules** (version 2147483647):  Cannot call
`napi_reference_unref` from finalizers

## Why This Matters

Many existing NAPI modules in the ecosystem were written before the
stricter GC rules and rely on being able to call functions like
`napi_reference_unref` from finalizers. Node.js maintains backward
compatibility by only enforcing the stricter rules for modules that
explicitly opt into experimental features.

By not matching this behavior, Bun was breaking existing packages that
work fine in Node.js.

## Test Plan

Added comprehensive tests that verify both scenarios:

### 1. test_reference_unref_in_finalizer.c (Regular Module)
- Uses default NAPI version (8)
- Creates 100 objects with finalizers that call `napi_reference_unref`
- **Expected:** Works without crashing
- **Result:**  Passes with both Node.js and Bun (with fix)

### 2. test_reference_unref_in_finalizer_experimental.c (Experimental
Module)
- Uses `NAPI_VERSION_EXPERIMENTAL` (2147483647)
- Creates objects with finalizers that call `napi_reference_unref`
- **Expected:** Crashes with GC safety assertion
- **Result:**  Correctly fails with both Node.js and Bun (with fix)

## Verification

The tests prove our fix is correct:

```bash
# Regular module - should work
$ bun-debug --expose-gc main.js test_reference_unref_in_finalizer '[]'
 SUCCESS: napi_reference_unref worked in finalizers without crashing

# Experimental module - should fail
$ bun-debug --expose-gc main.js test_reference_unref_in_finalizer_experimental '[]'
 ASSERTION FAILED: Attempted to call a non-GC-safe function inside a NAPI finalizer
```

Both behaviors now match Node.js exactly.

## Impact

This fix:
1. Resolves crashes with rolldown-vite and similar packages
2. Maintains backward compatibility with the Node.js ecosystem
3. Still enforces safety for experimental NAPI features
4. Aligns Bun's behavior with Node.js's intentional design decisions

🤖 Generated with Claude Code

Co-Authored-By: Claude <noreply@anthropic.com>

---------

Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
Co-authored-by: Zack Radisic <zack@theradisic.com>
2025-09-12 23:13:44 -07:00
fmt
2025-09-12 17:24:47 -07:00
2025-08-19 23:15:53 -07:00
2025-09-12 01:08:46 -07:00
fmt
2025-09-12 17:24:47 -07:00
2024-12-26 11:48:30 -08:00
2024-12-12 03:21:56 -08:00
2025-01-07 20:19:12 -08:00
2025-07-21 16:26:07 -07:00
2025-09-07 18:51:39 -07:00
2025-08-25 21:04:18 -07:00
2024-07-24 01:30:31 -07:00
2025-04-19 05:41:34 -07:00
2025-07-10 00:10:43 -07:00
2025-07-10 00:10:43 -07:00

Logo

Bun

stars Bun speed

Documentation   •   Discord   •   Issues   •   Roadmap

Read the docs →

What is Bun?

Bun is an all-in-one toolkit for JavaScript and TypeScript apps. It ships as a single executable called bun.

At its core is the Bun runtime, a fast JavaScript runtime designed as a drop-in replacement for Node.js. It's written in Zig and powered by JavaScriptCore under the hood, dramatically reducing startup times and memory usage.

bun run index.tsx             # TS and JSX supported out-of-the-box

The bun command-line tool also implements a test runner, script runner, and Node.js-compatible package manager. Instead of 1,000 node_modules for development, you only need bun. Bun's built-in tools are significantly faster than existing options and usable in existing Node.js projects with little to no changes.

bun test                      # run tests
bun run start                 # run the `start` script in `package.json`
bun install <pkg>             # install a package
bunx cowsay 'Hello, world!'   # execute a package

Install

Bun supports Linux (x64 & arm64), macOS (x64 & Apple Silicon) and Windows (x64).

Linux users — Kernel version 5.6 or higher is strongly recommended, but the minimum is 5.1.

x64 users — if you see "illegal instruction" or similar errors, check our CPU requirements

# with install script (recommended)
curl -fsSL https://bun.com/install | bash

# on windows
powershell -c "irm bun.com/install.ps1 | iex"

# with npm
npm install -g bun

# with Homebrew
brew tap oven-sh/bun
brew install bun

# with Docker
docker pull oven/bun
docker run --rm --init --ulimit memlock=-1:-1 oven/bun

Upgrade

To upgrade to the latest version of Bun, run:

bun upgrade

Bun automatically releases a canary build on every commit to main. To upgrade to the latest canary build, run:

bun upgrade --canary

View canary build

Guides

Contributing

Refer to the Project > Contributing guide to start contributing to Bun.

License

Refer to the Project > License page for information about Bun's licensing.

Description
Bun is a fast, incrementally adoptable all-in-one JavaScript, TypeScript & JSX toolkit. Use individual tools like bun test or bun install in Node.js projects, or adopt the complete stack with a fast JavaScript runtime, bundler, test runner, and package manager built in. Bun aims for 100% Node.js compatibility.
Readme 680 MiB
Languages
Zig 60.5%
C++ 24.9%
TypeScript 8.3%
C 3.3%
JavaScript 1.4%
Other 1.1%