The previous fix for middle dot characters accidentally broke $ and _
character parsing in JavaScript identifiers. These characters are
special cases in ECMAScript that must be explicitly added to the
ID_Start and ID_Continue sets, as they are not included in the
standard Unicode categories.
This restores support for:
- $ in destructuring: import { $ } from "bun"
- _ in variable names: const _private = 123
- All other $ and _ usage in identifiers
While maintaining the fix for Japanese middle dot characters.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
This fixes an issue where Japanese middle dot characters (U+30FB "・" and
U+FF65 "･") were incorrectly excluded from identifier continuation characters.
These characters are valid in ECMAScript identifiers and are commonly used
in Japanese text, particularly in real estate property names like "バス・トイレ".
Changes:
- Remove incorrect exclusion of middle dot characters from Unicode tables
- Regenerate identifier lookup tables with correct Unicode data
- Add regression test to prevent future issues
- Maintain correct behavior: middle dots can only continue identifiers, not start them
Fixes https://github.com/oven-sh/bun/discussions/22230🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
### What does this PR do?
### How did you verify your code works?
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
### What does this PR do?
Change tinyint/bool type from mysql to number instead of bool to match
mariadb and mysql2 behavior since tinyint/bool can be bigger than 1 in
mysql
Fixes https://github.com/oven-sh/bun/issues/22158
### How did you verify your code works?
Test
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Replace `catch bun.outOfMemory()`, which can accidentally catch
non-OOM-related errors, with either `bun.handleOom` or a manual `catch
|err| switch (err)`.
(For internal tracking: fixes STAB-1070)
---------
Co-authored-by: Dylan Conway <dylan.conway567@gmail.com>
### What does this PR do?
- Implements .onEnd
Fixes#22061
Once #22144 is merged, this also fixes:
Fixes#9862Fixes#20806
### How did you verify your code works?
Tests
---
TODO in a followup (#22144)
> ~~Make all entrypoints be called in onResolve~~
> ~~Fixes # 9862~~
> ~~Fixes # 20806~~
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
### What does this PR do?
optimize advance method
after this optimizations
100k req the query bellow in 1 connection takes 792ms instead of 6s
```sql
SELECT CAST(1 AS UNSIGNED) AS x
```
1mi req of the query bellow with 10 connections takes 57.41s - 62.5s
instead of 162.50s, mysql2 takes 1516.94s for comparison
```sql
SELECT * FROM users_bun_bench LIMIT 100
```
### How did you verify your code works?
Tested and benchmarked + CI
For jest compatibility. Fixes#5228
---------
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>
### What does this PR do?
fixes parsing strings like `"1e18495d9d7f6b41135e5ee828ef538dc94f9be4"`
### How did you verify your code works?
added a test.
## Summary
Fixes a bug in the internal `bun.spawnSync` implementation where
stderr's poll file descriptor was incorrectly set to stdout's fd when
polling both streams.
## The Bug
In `/src/bun.js/api/bun/process.zig` line 2204, when setting up the poll
file descriptor array for stderr, the code incorrectly used
`out_fds_to_wait_for[0]` (stdout) instead of `out_fds_to_wait_for[1]`
(stderr).
This meant:
- stderr's fd was never actually polled
- stdout's fd was polled twice
- Could cause stderr data to be lost or incomplete
- Could potentially cause hangs when reading from stderr
## Impact
This bug only affects Bun's internal CLI commands that use
`bun.spawnSync` with both stdout and stderr piped (like `bun create`,
`bun upgrade`, etc.). The JavaScript `spawnSync` API uses a different
code path and is not affected.
## The Fix
Changed line 2204 from:
```zig
poll_fds[poll_fds.len - 1].fd = @intCast(out_fds_to_wait_for[0].cast());
```
to:
```zig
poll_fds[poll_fds.len - 1].fd = @intCast(out_fds_to_wait_for[1].cast());
```
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Claude <noreply@anthropic.com>
## Summary
Fixes an issue where `--compile-exec-argv` options were incorrectly
appearing in `process.argv` when no user arguments were provided to a
compiled standalone binary.
## Problem
When building a standalone binary with `--compile-exec-argv`, the exec
argv options would leak into `process.argv` when running the binary
without any user arguments:
```bash
# Build with exec argv
bun build --compile-exec-argv="--user-agent=hello" --compile ./a.js
# Run without arguments - BEFORE fix
./a
# Output showed --user-agent=hello in both execArgv AND argv (incorrect)
{
execArgv: [ "--user-agent=hello" ],
argv: [ "bun", "/$bunfs/root/a", "--user-agent=hello" ], # <- BUG: exec argv leaked here
}
# Expected behavior (matches runtime):
bun --user-agent=hello a.js
{
execArgv: [ "--user-agent=hello" ],
argv: [ "/path/to/bun", "/path/to/a.js" ], # <- No exec argv in process.argv
}
```
## Solution
The issue was in the offset calculation for determining which arguments
to pass through to the JavaScript runtime. The offset was being
calculated before modifying the argv array with exec argv options,
causing it to be incorrect when the original argv only contained the
executable name.
The fix ensures that:
- `process.execArgv` correctly contains the compile-exec-argv options
- `process.argv` only contains the executable, script path, and user
arguments
- exec argv options never leak into `process.argv`
## Test plan
Added comprehensive tests to verify:
1. Exec argv options don't leak into process.argv when no user arguments
are provided
2. User arguments are properly passed through when exec argv is present
3. Existing behavior continues to work correctly
All tests pass:
```
bun test compile-argv.test.ts
✓ 3 tests pass
```
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
This PR adds `Bun.secrets`, a new API for securely storing and
retrieving credentials using the operating system's native credential
storage locally. This helps developers avoid storing sensitive data in
plaintext config files.
```javascript
// Store a GitHub token securely
await Bun.secrets.set({
service: "my-cli-tool",
name: "github-token",
value: "ghp_xxxxxxxxxxxxxxxxxxxx"
});
// Retrieve it when needed
const token = await Bun.secrets.get({
service: "my-cli-tool",
name: "github-token"
});
// Use with fallback to environment variable
const apiKey = await Bun.secrets.get({
service: "my-app",
name: "api-key"
}) || process.env.API_KEY;
```
Marking this as a draft because Linux and Windows have not been manually
tested yet. This API is only really meant for local development usecases
right now, but it would be nice if in the future to support adapters for
production or CI usecases.
### Core API
- `Bun.secrets.get({ service, name })` - Retrieve a stored credential
- `Bun.secrets.set({ service, name, value })` - Store or update a
credential
- `Bun.secrets.delete({ service, name })` - Delete a stored credential
### Platform Support
- **macOS**: Uses Keychain Services via Security.framework
- **Linux**: Uses libsecret (works with GNOME Keyring, KWallet, etc.)
- **Windows**: Uses Windows Credential Manager via advapi32.dll
### Implementation Highlights
- Non-blocking - all operations run on the threadpool
- Dynamic loading - no hard dependencies on system libraries
- Sensitive data is zeroed after use
- Consistent API across all platforms
## Use Cases
This API is particularly useful for:
- CLI tools that need to store authentication tokens
- Development tools that manage API keys
- Any tool that currently stores credentials in `~/.npmrc`,
`~/.aws/credentials` or in environment variables that're globally loaded
## Testing
Comprehensive test suite included with coverage for:
- Basic CRUD operations
- Empty strings and special characters
- Unicode support
- Concurrent operations
- Error handling
All tests pass on macOS. Linux and Windows implementations are complete
but would benefit from additional platform testing.
## Documentation
- Complete API documentation in `docs/api/secrets.md`
- TypeScript definitions with detailed JSDoc comments and examples
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
### What does this PR do?
This PR adds builtin YAML parsing with `Bun.YAML.parse`
```js
import { YAML } from "bun";
const items = YAML.parse("- item1");
console.log(items); // [ "item1" ]
```
Also YAML imports work just like JSON and TOML imports
```js
import pkg from "./package.yaml"
console.log({ pkg }); // { pkg: { name: "pkg", version: "1.1.1" } }
```
### How did you verify your code works?
Added some tests for YAML imports and parsed values.
---------
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>
* `IncrementalGraph(.client).File` packs its fields in a specific way to
save space, but it makes the struct hard to use and error-prone (e.g.,
untagged unions with tags stored in a separate `flags` struct). This PR
changes `File` to have a human-readable layout, but adds methods to
convert it to and from `File.Packed`, a packed version with the same
space efficiency as before.
* Reduce the need to pass the dev allocator to functions (e.g.,
`deinit`) by storing it as a struct field via the new `DevAllocator`
type. This type has no overhead in release builds, or when
`AllocationScope` is disabled.
* Use owned pointers in `PackedMap`.
* Use `bun.ptr.Shared` for `PackedMap` instead of the old
`bun.ptr.RefPtr`.
* Add `bun.ptr.ScopedOwned`, which is like `bun.ptr.Owned`, but can
store an `AllocationScope`. No overhead in release builds or when
`AllocationScope` is disabled.
* Reduce redundant allocators in `BundleV2`.
* Add owned pointer conversions to `MutableString`.
* Make `AllocationScope` behave like a pointer, so it can be moved
without invalidating allocations. This eliminates the need for
self-references.
* Change memory cost algorithm so it doesn't rely on “dedupe bits”.
These bits used to take advantage of padding but there is now no padding
in `PackedMap`.
* Replace `VoidFieldTypes` with `useAllFields`; this eliminates the need
for `voidFieldTypesDiscardHelper`.
(For internal tracking: fixes STAB-1035, STAB-1036, STAB-1037,
STAB-1038, STAB-1039, STAB-1040, STAB-1041, STAB-1042, STAB-1043,
STAB-1044, STAB-1045)
---------
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: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
## Summary
Fixes an assertion failure that occurred when `server.stop()` was called
while HTTP requests were still in flight.
## Root Cause
The issue was in `jsValueAssertAlive()` at
`src/bun.js/api/server.zig:627`, which had an assertion requiring
`server.listener != null`. However, `server.stop()` immediately sets
`listener` to null, causing assertion failures when pending requests
triggered callbacks that accessed the server's JavaScript value.
## Solution
Converted the server's `js_value` from `jsc.Strong.Optional` to
`jsc.JSRef` for safer lifecycle management:
- **On `stop()`**: Downgrade from strong to weak reference instead of
calling `deinit()`
- **In `finalize()`**: Properly call `deinit()` on the JSRef
- **Remove problematic assertion**: JSRef allows safe access to JS value
via weak reference even after stop
## Benefits
- ✅ No more assertion failures when stopping servers with pending
requests
- ✅ In-flight requests can still access the server JS object safely
- ✅ JS object can be garbage collected when appropriate
- ✅ Maintains backward compatibility - no external API changes
## Test plan
- [x] Reproduces the original assertion failure
- [x] Verifies the fix resolves the issue
- [x] Adds regression test to prevent future occurrences
- [x] Confirms normal server functionality still works
The fix includes a comprehensive regression test at
`test/regression/issue/server-stop-with-pending-requests.test.ts`.
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
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>
## Summary
- Implement `Symbol.asyncDispose` for the `Worker` class in
`worker_threads` module
- Enables automatic resource cleanup with `await using` syntax
- Calls `await this.terminate()` to properly shut down workers when they
go out of scope
## Implementation Details
The implementation adds a simple async method to the Worker class:
```typescript
async [Symbol.asyncDispose]() {
await this.terminate();
}
```
This allows workers to be used with the new `await using` syntax for
automatic cleanup:
```javascript
{
await using worker = new Worker('./worker.js');
// worker automatically terminates when leaving this scope
}
```
## Test Plan
- [x] Added comprehensive tests for `Symbol.asyncDispose` functionality
- [x] Tests verify the method exists and returns undefined
- [x] Tests verify `await using` syntax works correctly for automatic
worker cleanup
- [x] All new tests pass
- [x] Existing worker_threads functionality remains intact
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
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>
Followup to #22049: I'm pretty sure “platform-specific padding” on
Windows is a hallucination. I think this is due to ReleaseSafe adding
tags to untagged unions.
(For internal tracking: fixes STAB-1057)
### What does this PR do?
Support the following:
```javascript
const nom = await sql`SELECT name FROM food WHERE category IN ${sql(['bun', 'baozi', 'xiaolongbao'])}`;
```
Previously, only e.g., `sql([1, 2, 3])` was supported.
To be honest I'm not sure what the semantics of SQLHelper *ought* to be.
I'm pretty sure objects ought to be auto-inferred. I'm not sure about
arrays, but given the rest of the code in `SQLHelper` trying to read the
tea leaves on stringified numeric keys I figured someone cared about
this use case. I don't know about other types, but I'm pretty sure that
`Object.keys("bun") === [0, 1, 2]` is an oversight and unintended.
(Incidentally, the reason numbers previously worked is because
`Object.keys(4) === []`). I decided that all non-objects and non-arrays
should be treated as not having auto-inferred columns.
Fixes#18637
### How did you verify your code works?
I wrote a test, but was unable to run it (or any other tests in this
file) locally due to Docker struggles. I sure hope it works!
### What does this PR do?
This PR fixes https://github.com/oven-sh/bun/issues/19131.
I am not 100% certain that this fix is correct as I am still nebulous
regarding some decisions I've made in this PR. I'll try to provide my
reasoning and would love to be proven wrong:
#### Re-authentication
- The `is_authenticated` flag needs to be reset to false. When the
lifecycle reaches a point of attempting to connect, it sends out a
`HELLO 3`, and receives a response. `handleResponse()` is fired and does
not correctly handle it because there is a guard at the top of the
function:
```zig
if (!this.flags.is_authenticated) {
this.handleHelloResponse(value);
// We've handled the HELLO response without consuming anything from the command queue
return;
}
```
Rather, it treats this packet as a regular data packet and complains
that it doesn't have a promise to associate it to. By resetting the
`is_authenticated` flag to false, we guarantee that we handle the `HELLO
3` packet as an authentication packet.
It also seems to make semantic sense since dropping a connection implies
you dropped authentication.
#### Retry Attempts
I've deleted the `retry_attempts = 0` in `reconnect()` because I noticed
that we would never actually re-attempt to reconnect after the first
attempt. Specifically, I was expecting `valkey.zig:459` to potentially
fire multiple times, but it only ever fired once. Removing this reset to
zero caused successful reattempts (in my case 3 of them).
```zig
debug("reconnect in {d}ms (attempt {d}/{d})", .{ delay_ms, this.retry_attempts, this.max_retries });
```
I'm still iffy on whether this is necessary, but I think it makes sense.
```zig
this.client.retry_attempts = 0
```
### How did you verify your code works?
I have added a small unit test. I have compared mainline `bun`, which
fails that test, to this fix, which passes the test.
---------
Co-authored-by: Ciro Spaciari <ciro.spaciari@gmail.com>
## Summary
- Implements automated Windows code signing for x64 and x64-baseline
builds
- Integrates DigiCert KeyLocker for secure certificate management
- Adds CI/CD pipeline support for signing during builds
## Changes
- Added `.buildkite/scripts/sign-windows.sh` script for automated
signing
- Updated CMake configurations to support signing workflow
- Modified build scripts to integrate signing step
## Testing
- Script tested locally with manual signing process
- Successfully signed test binaries at:
- `C:\Builds\bun-windows-x64\bun.exe`
- `C:\Builds\bun-windows-x64-baseline\bun.exe`
## References
Uses DigiCert KeyLocker tools for Windows signing
## Next Steps
- Validate Buildkite environment variables in CI
- Test full pipeline in CI environment
---------
Co-authored-by: Jarred Sumner <jarred@bun.sh>
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>
### What does this PR do?
Fixes#20729
### How did you verify your code works?
There is a test
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
### What does this PR do?
Add MySQL support, Refactor will be in a followup PR
### How did you verify your code works?
A lot of tests
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: cirospaciari <6379399+cirospaciari@users.noreply.github.com>
### What does this PR do?
Fixes#22014
todo:
- [x] not spawn sync
- [x] better comm to subprocess (not stderr)
- [x] tty
- [x] more tests (also include some tests for the actual implementation
of a provider)
- [x] disable autoinstall?
Scanner template: https://github.com/oven-sh/security-scanner-template
<!-- **Please explain what your changes do**, example: -->
<!--
This adds a new flag --bail to bun test. When set, it will stop running
tests after the first failure. This is useful for CI environments where
you want to fail fast.
-->
---
- [x] Documentation or TypeScript types (it's okay to leave the rest
blank in this case)
- [x] Code changes
### How did you verify your code works?
<!-- **For code changes, please include automated tests**. Feel free to
uncomment the line below -->
<!-- I wrote automated tests -->
<!-- If JavaScript/TypeScript modules or builtins changed:
- [ ] I included a test for the new code, or existing tests cover it
- [ ] I ran my tests locally and they pass (`bun-debug test
test-file-name.test`)
-->
<!-- If Zig files changed:
- [ ] I checked the lifetime of memory allocated to verify it's (1)
freed and (2) only freed when it should be
- [ ] I included a test for the new code, or an existing test covers it
- [ ] JSValue used outside of the stack is either wrapped in a
JSC.Strong or is JSValueProtect'ed
- [ ] I wrote TypeScript/JavaScript tests and they pass locally
(`bun-debug test test-file-name.test`)
-->
<!-- If new methods, getters, or setters were added to a publicly
exposed class:
- [ ] I added TypeScript types for the new methods, getters, or setters
-->
<!-- If dependencies in tests changed:
- [ ] I made sure that specific versions of dependencies are used
instead of ranged or tagged versions
-->
<!-- If a new builtin ESM/CJS module was added:
- [ ] I updated Aliases in `module_loader.zig` to include the new module
- [ ] I added a test that imports the module
- [ ] I added a test that require() the module
-->
tests (bad currently)
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: Dylan Conway <dylan-conway@users.noreply.github.com>
Co-authored-by: Dylan Conway <dylan.conway567@gmail.com>
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
Add a new reference-counted shared pointer type, `bun.ptr.Shared`.
Features:
* Can hold data of any type; doesn't require adding a `ref_count` field
* Reference count is an internal implementation detail; will never get
out of sync due to erroneous manipulation
* Supports weak pointers
* Supports optional pointers with no overhead (`Shared(?*T)` is the same
size as `Shared(*T)`)
* Has an atomic thread-safe version: `bun.ptr.AtomicShared`
* Defaults to `bun.default_allocator`, but can handle other allocators
as well, with both static and dynamic polymorphism
The following types are now deprecated and will eventually be removed:
* `bun.ptr.RefCount`
* `bun.ptr.ThreadSafeRefCount`
* `bun.ptr.RefPtr`
* `bun.ptr.WeakPtr`
(For internal tracking: fixes STAB-1011)
### What does this PR do?
Disable postMessage optimization when string is < 256 chars
If you're going to potentially use these strings as a property or
identifier, which is much more likely for short strings than long
strings, we shouldn't ban atomizing them and the cost of cloning isn't
so much in that case
### How did you verify your code works?
### What does this PR do?
in the name
### How did you verify your code works?
tests, but using ci to see if anything else broke
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
## Summary
- Fixes a panic: "exact division produced remainder" that occurs when
reading files with odd number of bytes using utf16le/ucs2 encoding
- The crash happened in `encoding.zig:136` when
`std.mem.bytesAsSlice(u16, input)` was called on a byte slice with odd
length
- Fixed by properly checking for odd-length input and truncating to the
nearest even length
## Test plan
- Added regression tests in
`test/regression/issue/utf16-encoding-crash.test.ts`
- Tests verify that reading files with odd byte counts doesn't crash
- Tests verify correct truncation behavior matches Node.js expectations
- Verified edge cases (0, 1 byte inputs) return empty strings
## Root Cause
The original code checked `if (input.len / 2 == 0)` which only caught 0
and 1-byte inputs, but `std.mem.bytesAsSlice(u16, input)` panics on any
odd-length input (3, 5, 7, etc. bytes).
## Fix Details
- Changed condition to check `input.len % 2 != 0` for any odd length
- Truncate odd-length inputs to the nearest even length for valid UTF-16
processing
- Handle edge cases by returning empty string for 0 or 1-byte inputs
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
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: Dylan Conway <dylan.conway567@gmail.com>
### What does this PR do?
Support sqlite in the Bun.sql API
Fixes#18951Fixes#19701
### How did you verify your code works?
tests
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
Reverts oven-sh/bun#21962
`vm.ensureTerminationException` allocates a JSString, which is not safe
to do from a thread that doesn't own the API lock.
```ts
Bun Canary v1.2.21-canary.1 (f706382a) Linux x64 (baseline)
Linux Kernel v6.12.38 | musl
CPU: sse42 popcnt avx avx2 avx512
Args: "/var/lib/buildkite-agent/builds/ip-172-31-38-185/bun/bun/release/bun-linux-x64-musl-baseline-profile/bun-profile" "/var/lib/buildkite-agent/builds/ip-172-31-38-185/bun/bun/test/js/node/worker_threads"...
Features: bunfig http_server jsc tsconfig(3) tsconfig_paths workers_spawned(40) workers_terminated(34)
Builtins: "bun:main" "node:worker_threads"
Elapsed: 362ms | User: 518ms | Sys: 63ms
RSS: 0.34GB | Peak: 100.36MB | Commit: 0.34GB | Faults: 0 | Machine: 8.17GB
panic(main thread): Segmentation fault at address 0x0
oh no: Bun has crashed. This indicates a bug in Bun, not your code.
To send a redacted crash report to Bun's team,
please file a GitHub issue using the link below:
http://localhost:38809/1.2.21/Ba2f706382wNgkgUu11luEm6yX+lwy+Dgtt+oEurthoD8214mE___07+09DA2AA
6 | describe("Worker destruction", () => {
7 | const method = ["Bun.connect", "Bun.listen", "fetch"];
8 | describe.each(method)("bun when %s is used in a Worker that is terminating", method => {
9 | // fetch: ASAN failure
10 | test.skipIf(isBroken && method == "fetch")("exits cleanly", () => {
11 | expect([join(import.meta.dir, "worker_thread_check.ts"), method]).toRun();
^
error:
Command /var/lib/buildkite-agent/builds/ip-172-31-38-185/bun/bun/test/js/node/worker_threads/worker_thread_check.ts Bun.connect failed:
Spawned 10 workers RSS 79 MB
Spawned 10 workers RSS 87 MB
Spawned 10 workers RSS 90 MB
at <anonymous> (/var/lib/buildkite-agent/builds/ip-172-31-38-185/bun/bun/test/js/node/worker_threads/worker_destruction.test.ts:11:73)
✗ Worker destruction > bun when Bun.connect is used in a Worker that is terminating > exits cleanly [597.56ms]
✓ Worker destruction > bun when Bun.listen is used in a Worker that is terminating > exits cleanly [503.47ms]
» Worker destruction > bun when fetch is used in a Worker that is terminating > exits cleanly
1 pass
1 skip
1 fail
2 expect() calls
Ran 3 tests across 1 file. [1125.00ms]
======== Stack trace from GDB for bun-profile-28234.core: ========
Program terminated with signal SIGILL, Illegal instruction.
#0 crash_handler.crash () at crash_handler.zig:1523
[Current thread is 1 (LWP 28234)]
#0 crash_handler.crash () at crash_handler.zig:1523
#1 0x0000000002db77aa in crash_handler.crashHandler (reason=..., error_return_trace=0x0, begin_addr=...) at crash_handler.zig:471
#2 0x0000000002db2b55 in crash_handler.handleSegfaultPosix (sig=<optimized out>, info=<optimized out>) at crash_handler.zig:792
#3 0x0000000004716b58 in WTF::jscSignalHandler (sig=11, info=0x7ffe54051e90, ucontext=0x0) at vendor/WebKit/Source/WTF/wtf/threads/Signals.cpp:548
#4 <signal handler called>
#5 JSC::VM::currentThreadIsHoldingAPILock (this=0x148296c30000) at vendor/WebKit/Source/JavaScriptCore/runtime/VM.h:840
#6 JSC::sanitizeStackForVM (vm=...) at vendor/WebKit/Source/JavaScriptCore/runtime/VM.cpp:1369
#7 0x0000000003f4a060 in JSC::LocalAllocator::allocate(JSC::Heap&, unsigned long, JSC::GCDeferralContext*, JSC::AllocationFailureMode)::{lambda()#1}::operator()() const (this=<optimized out>) at cache/webkit-a73e665a39b281c5/include/JavaScriptCore/LocalAllocatorInlines.h:46
#8 JSC::FreeList::allocateWithCellSize<JSC::LocalAllocator::allocate(JSC::Heap&, unsigned long, JSC::GCDeferralContext*, JSC::AllocationFailureMode)::{lambda()#1}>(JSC::LocalAllocator::allocate(JSC::Heap&, unsigned long, JSC::GCDeferralContext*, JSC::AllocationFailureMode)::{lambda()#1} const&, unsigned long) (this=0x148296c38e48, cellSize=16, slowPath=...) at cache/webkit-a73e665a39b281c5/include/JavaScriptCore/FreeListInlines.h:46
#9 JSC::LocalAllocator::allocate (this=0x148296c38e30, heap=..., cellSize=16, deferralContext=0x0, failureMode=JSC::AllocationFailureMode::Assert) at cache/webkit-a73e665a39b281c5/include/JavaScriptCore/LocalAllocatorInlines.h:44
#10 JSC::GCClient::IsoSubspace::allocate (this=0x148296c38e30, vm=..., cellSize=16, deferralContext=0x0, failureMode=JSC::AllocationFailureMode::Assert) at cache/webkit-a73e665a39b281c5/include/JavaScriptCore/IsoSubspaceInlines.h:34
#11 JSC::tryAllocateCellHelper<JSC::JSString, (JSC::AllocationFailureMode)0> (vm=..., size=16, deferralContext=0x0) at cache/webkit-a73e665a39b281c5/include/JavaScriptCore/JSCellInlines.h:192
#12 JSC::allocateCell<JSC::JSString> (vm=..., size=16) at cache/webkit-a73e665a39b281c5/include/JavaScriptCore/JSCellInlines.h:212
#13 JSC::JSString::create (vm=..., value=...) at cache/webkit-a73e665a39b281c5/include/JavaScriptCore/JSString.h:204
#14 0x0000000004479ad1 in JSC::jsNontrivialString (vm=..., s=...) at vendor/WebKit/Source/JavaScriptCore/runtime/JSString.h:846
#15 JSC::VM::ensureTerminationException (this=0x148296c30000) at vendor/WebKit/Source/JavaScriptCore/runtime/VM.cpp:627
#16 JSGlobalObject__requestTermination (globalObject=<optimized out>) at ./build/release/./src/bun.js/bindings/ZigGlobalObject.cpp:3979
#17 0x0000000003405ab8 in bun.js.web_worker.notifyNeedTermination (this=0x542904f0d80) at /var/lib/buildkite-agent/builds/ip-172-31-16-28/bun/bun/src/bun.js/web_worker.zig:558
#18 0x0000000004362b6f in WebCore::Worker::terminate (this=0x984c900000000000) at ./src/bun.js/bindings/webcore/Worker.cpp:266
#19 WebCore::jsWorkerPrototypeFunction_terminateBody(JSC::JSGlobalObject*, JSC::CallFrame*, WebCore::JSWorker*)::{lambda()#1}::operator()() const (this=<optimized out>) at ./build/release/./src/bun.js/bindings/webcore/JSWorker.cpp:549
#20 WebCore::toJS<WebCore::IDLUndefined, WebCore::jsWorkerPrototypeFunction_terminateBody(JSC::JSGlobalObject*, JSC::CallFrame*, WebCore::JSWorker*)::{lambda()#1}>(JSC::JSGlobalObject&, JSC::ThrowScope&, WebCore::jsWorkerPrototypeFunction_terminateBody(JSC::JSGlobalObject*, JSC::CallFrame*, WebCore::JSWorker*)::{lambda()#1}&&) (lexicalGlobalObject=..., throwScope=..., valueOrFunctor=...) at ./src/bun.js/bindings/webcore/JSDOMConvertBase.h:174
#21 WebCore::jsWorkerPrototypeFunction_terminateBody (lexicalGlobalObject=<optimized out>, callFrame=<optimized out>, castedThis=<optimized out>) at ./build/release/./src/bun.js/bindings/webcore/JSWorker.cpp:549
#22 WebCore::IDLOperation<WebCore::JSWorker>::call<&WebCore::jsWorkerPrototypeFunction_terminateBody, (WebCore::CastedThisErrorBehavior)0> (lexicalGlobalObject=..., operationName=..., callFrame=...) at ./src/bun.js/bindings/webcore/JSDOMOperation.h:63
#23 WebCore::jsWorkerPrototypeFunction_terminate (lexicalGlobalObject=<optimized out>, callFrame=0x7ffe540536b8) at ./build/release/./src/bun.js/bindings/webcore/JSWorker.cpp:554
#24 0x000014825580c038 in ?? ()
#25 0x00007ffe540537b0 in ?? ()
#26 0x0000148255a626cb in ?? ()
#27 0x0000000000000000 in ?? ()
1 crashes reported during this test
```
## Summary
- Fixes a crash where invalid slice bounds caused a panic with message:
"start index N is larger than end index M"
- The issue occurred in `js_lexer.zig:767` when calculating string
literal content slice bounds
- Adds proper bounds checking to prevent slice bounds violations
- Includes regression test to prevent future occurrences
## Root Cause
The crash happened when `suffix_len` was larger than `lexer.end`,
causing the calculation `lexer.end - suffix_len` to result in a value
smaller than the `base` position. This created invalid slice bounds like
`[114..113]`.
## Solution
Added bounds checking to ensure:
1. `end_pos` is calculated safely: `if (lexer.end >= suffix_len)
lexer.end - suffix_len else lexer.end`
2. `slice_end` is always >= `base`: `@max(base, end_pos)`
## Test Plan
- [x] Added regression test in
`test/regression/issue/jsx-template-string-crash.test.ts`
- [x] Test verifies no crashes occur with JSX template string patterns
- [x] Verified normal template string functionality still works
- [x] All tests pass
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
### What does this PR do?
Fixes namespace import objects inheriting from `Object.prototype`,
preventing prototype pollution and ensuring ES specification compliance.
```js
import * as mod from './mod.mjs'
Object.prototype.foo = function() {
console.log('hello');
}
mod.foo(); // This should throw, but succeeded before
```
original report: https://x.com/sapphi_red/status/1957843865722863876
### How did you verify your code works?
I added a test that verifies:
- `mod.maliciousFunction()` throws when
`Object.prototype.maliciousFunction` is added (prevents pollution)
- `__esModule` property still works
- Original exports remain accessible
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
### What does this PR do?
Calling `process.exit` inside a Web Worker now immediately notifies the
VM that it needs to terminate. Previously, `napi_call_function` would
return success in a Web Worker even if the JS code called
`process.exit`. Now it'll return `napi_pending_exception`.
### How did you verify your code works?
Ran Node's NAPI tests (`node-api/test_worker_terminate/test.js` now
passes) in addition to our own NAPI tests.
### What does this PR do?
Use
https://gist.github.com/christianparpart/d8a62cc1ab659194337d73e399004036
like we do in `bun run --filter`
### How did you verify your code works?
tried in next.js repo and in debug build it no longer flickers
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
## Summary
Fixes a critical segmentation fault crash occurring during NAPI
finalizer cleanup when finalizers trigger GC operations. This crash was
reported with `node-sqlite3` and other NAPI modules during process exit.
## Root Cause
The crash was caused by **iterator invalidation** in
`napi_env__::cleanup()`:
1. Range-based for loop iterates over `m_finalizers`
(std::unordered_set)
2. `boundFinalizer.call(this)` executes finalizer callbacks
3. Finalizers can trigger JavaScript execution and GC operations
4. GC can add/remove entries from `m_finalizers` during iteration
5. **Iterator invalidation** → undefined behavior → segfault
## Solution
Added `JSC::DeferGCForAWhile deferGC(m_vm)` scope during entire
finalizer cleanup to prevent any GC operations from occurring during
iteration.
### Why This Approach?
- **Addresses root cause**: Prevents GC entirely during critical section
- **Simple & safe**: One-line RAII fix using existing JSC patterns
- **Minimal impact**: Only affects process cleanup (not runtime
performance)
- **Proven pattern**: Already used elsewhere in Bun's codebase
- **Better than alternatives**: Cleaner than Node.js manual iterator
approach
## Testing
Added comprehensive test (`test_finalizer_iterator_invalidation.c`) that
reproduces the crash by:
- Creating finalizers that trigger GC operations
- Forcing JavaScript execution during finalization
- Allocating objects that can trigger more GC
- Calling process exit to trigger finalizer cleanup
**Before fix**: Segmentation fault
**After fix**: Clean exit ✅
## Files Changed
- `src/bun.js/bindings/napi.h`: Core fix + include
- `test/napi/napi-app/test_finalizer_iterator_invalidation.c`: Test
addon
- `test/napi/napi-app/binding.gyp`: Build config for test addon
- `test/regression/issue/napi-finalizer-crash.test.ts`: Integration test
## Test Plan
- [x] Reproduces original crash without fix
- [x] Passes cleanly with fix applied
- [x] Existing NAPI tests continue to pass
- [x] Manual testing with node-sqlite3 scenarios
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
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: Kai Tamkun <kai@tamkun.io>
## Summary
Fixes a crash in `napi_is_exception_pending` that occurs during
environment cleanup when finalizers call this function.
The crash manifested as:
```
panic: Aborted
- napi.h:192: napi_is_exception_pending
- napi.h:516: wrap_cleanup
- napi.h:273: napi_env__::cleanup
```
## Root Cause
Bun's implementation was using `DECLARE_THROW_SCOPE` during cleanup when
JavaScript execution is not safe, and didn't follow Node.js's approach
of avoiding `NAPI_PREAMBLE` for this function.
## Changes Made
1. **Remove `NAPI_PREAMBLE_NO_THROW_SCOPE`** - Node.js explicitly states
this function "must execute when there is a pending exception"
2. **Use `DECLARE_CATCH_SCOPE`** instead of `DECLARE_THROW_SCOPE` for
safety during cleanup
3. **Add safety check** `!env->isFinishingFinalizers()` before accessing
VM
4. **Add `napi_clear_last_error` function** to match Node.js
implementation
5. **Use `napi_clear_last_error`** instead of `napi_set_last_error` for
consistent behavior
## Test Plan
Created comprehensive test that:
- ✅ **Reproduces the original crash scenario** (finalizers calling
`napi_is_exception_pending`)
- ✅ **Verifies it no longer crashes in Bun**
- ✅ **Confirms behavior matches Node.js exactly**
### Test Results
**Before fix:** Would crash with `panic: Aborted` during cleanup
**After fix:**
```
Testing napi_is_exception_pending behavior...
1. Testing basic napi_is_exception_pending:
Status: 0 (should be 0 for napi_ok)
Result: false (should be false - no exception pending)
2. Testing with pending exception:
Exception was thrown as expected: Test exception
3. Testing finalizer scenario (the crash case):
Creating object with finalizer that calls napi_is_exception_pending...
Objects created. Forcing garbage collection...
Garbage collection completed.
napi_is_exception_pending in finalizer: status=0, result=false
[...5 finalizers ran successfully...]
SUCCESS: napi_is_exception_pending works correctly in all scenarios!
```
**Node.js comparison:** Identical output and behavior confirmed.
## Impact
- **Fixes crashes** in native addons that call
`napi_is_exception_pending` in finalizers
- **Improves Node.js compatibility** by aligning implementation approach
- **No breaking changes** - only fixes crash scenario, normal usage
unchanged
The fix aligns Bun's NAPI implementation with Node.js's proven approach
for safe exception checking during environment cleanup.
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
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>
## Summary
Fixes a panic that occurred when parsing malformed integrity data in
lockfiles. The issue was in `integrity.zig` where base64 decoding
attempted to write more bytes than the fixed-size digest buffer could
hold, causing `panic: index out of bounds: index 64, len 64`.
## Root Cause
The `Integrity.parse()` function tried to decode base64 data into a
fixed 64-byte buffer without validating that the decoded size wouldn't
exceed the buffer capacity. When malformed or oversized base64 integrity
strings were encountered in lockfiles, this caused an out-of-bounds
write.
## Fix
Added proper bounds checking in `src/install/integrity.zig`:
- Validates expected digest length before decoding
- Checks decoded size against buffer capacity using `calcSizeForSlice()`
- Only decodes into appropriately sized buffer slice based on hash
algorithm
- Returns `unknown` tag for malformed data instead of panicking
## Test Plan
- [x] Verified release binary crashes with malformed integrity data
- [x] Verified debug build with fix handles malformed data gracefully
- [x] Added comprehensive regression tests for all hash types (sha1,
sha256, sha384, sha512)
- [x] Confirmed normal lockfile parsing continues to work correctly
- [x] Tests pass: `bun bd test
test/regression/issue/integrity-base64-bounds-check.test.ts`
## Before/After
**Before**: `panic: index out of bounds: index 64, len 64`
**After**: Graceful handling with warning about malformed integrity data
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
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>
### What does this PR do?
Solves https://github.com/oven-sh/bun/issues/21923
So: if on riscv64, bail out, and do not install the x86-64 version of
bun
### How did you verify your code works?
On my RISCV system:
```
git clone https://github.com/sanderjo/bun.git sjo-oven-sh-bun
cd sjo-oven-sh-bun/
git branch -a
git checkout origin/detect_and_refuse_riscv64
grep -irn riscv64 src/cli/install.sh
```
Yes, correct. And then:
```
sander@riscv:~/git/sjo-oven-sh-bun$ bash src/cli/install.sh
error: Not supported on riscv64
sander@riscv:~/git/sjo-oven-sh-bun$
```
Good.
Co-authored-by: sanderjo <sander.jonkers+github@github.com>
## Summary
Fixes a crash in Package.zig where top-level catalog strings weren't
being counted before appending to the string builder.
## Root Cause
The issue occurred in the `parseWithJSON` function where:
1. **Counting phase**: Only catalog strings in the "workspaces"
expression were counted via `lockfile.catalogs.parseCount()`
2. **Appending phase**: There was a conditional call to
`lockfile.catalogs.parseAppend()` for top-level JSON catalog strings
3. **Result**: String builder allocation was insufficient when top-level
catalog strings were processed
## Changes
- Added `lockfile.catalogs.parseCount(lockfile, json, &string_builder)`
in the counting phase to ensure top-level catalog strings are always
counted
- Added explanatory comment documenting why this counting is necessary
## Test Plan
- [x] Built debug version successfully
- [x] Verified bun-debug binary works correctly
- [ ] Should be tested with package.json files that have top-level
catalog configurations
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
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>
