adds environment variable for proper tmpdir setup
actual fix for
d2a4fb8124
(which was reverted)
this fixes flakyness in node:fs and node:cluster when using
scripts/runner.node.mjs locally with the --parallel flag
### What does this PR do?
Enable compiler flags
Update SQLite amalgamation using https://www.sqlite.org/download.html
source code
[sqlite-src-3500400.zip](https://www.sqlite.org/2025/sqlite-src-3500400.zip)
with:
```bash
./configure CFLAGS="-DSQLITE_ENABLE_UPDATE_DELETE_LIMIT"
make sqlite3.c
```
This is the same version that before just with this adicional flag that
must be enabled when generating the amalgamation so we are actually able
to use this option. You can also see that without this the build will
happen but the feature will not be enable
https://buildkite.com/bun/bun/builds/27940, as informed in
https://www.sqlite.org/howtocompile.html topic 5.
### How did you verify your code works?
Add in CI two tests that check if the feature is enabled on windows
---------
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
# bun test
Fixes#8768, Fixes#14624, Fixes#20100, Fixes#19875, Fixes#14135,
Fixes#20980, Fixes#21830, Fixes#5738, Fixes#19758, Fixes#12782,
Fixes#5585, Fixes#9548, Might fix 5996
# New features:
## Concurrent tests
Concurrent tests allow running multiple async tests at the same time.
```ts
// concurrent.test.ts
test.concurrent("this takes a while 1", async () => {
await Bun.sleep(1000);
});
test.concurrent("this takes a while 2", async () => {
await Bun.sleep(1000);
});
test.concurrent("this takes a while 3", async () => {
await Bun.sleep(1000);
});
```
Without `.concurrent`, this test file takes 3 seconds to run because
each one has to wait for the one before it to finish before it can
start.
With `.concurrent`, this file takes 1 second because all three sleeps
can run at once.
```
$> bun-after test concurrent
concurrent.test.js:
✓ this takes a while 1 [1005.36ms]
✓ this takes a while 2 [1012.51ms]
✓ this takes a while 3 [1013.15ms]
3 pass
0 fail
Ran 3 tests across 1 file. [1081.00ms]
```
To run all tests as concurrent, pass the `--concurrent` flag when
running tests.
Limitations:
- concurrent tests cannot attribute `expect()` call counts to the test,
meaning `expect.assertions()` does not function
- concurrent tests cannot use `toMatchSnapshot`. `toMatchInlineSnapshot`
is still supported.
- `beforeAll`/`afterAll` will never be executed concurrently.
`beforeEach`/`afterEach` will.
## Chaining
Chaining multiple describe/test qualifiers is now allowed. Previously,
it would fail.
```ts
// chaining-test-qualifiers.test.ts
test.failing.each([1, 2, 3])("each %i", async i => {
throw new Error(i);
});
```
```
$> bun-after test chaining-test-qualifiers
a.test.js:
✓ each 1
✓ each 2
✓ each 3
```
# Breaking changes:
## Describe ordering
Previously, describe callbacks were called immediately. Now, they are
deferred until the outer callback has finished running. The previous
order matched Jest. The new order is similar to Vitest, but does not
match exactly.
```ts
// describe-ordering.test.ts
describe("outer", () => {
console.log("outer before");
describe("inner", () => {
console.log("inner");
});
console.log("outer after");
});
```
Before, this would print
```
$> bun-before test describe-ordering
outer before
inner
outer after
```
Now, this will print
```
$> bun-after test describe-ordering
outer before
outer after
inner
```
## Test ordering
Describes are no longer always called before tests. They are now in
order.
```ts
// test-ordering.test.ts
test("one", () => {});
describe("scope", () => {
test("two", () => {});
});
test("three", () => {});
```
Before, this would print
```
$> bun-before test test-ordering
✓ scope > two
✓ one
✓ three
```
Now, this will print
```
$> bun-after test test-ordering
✓ one
✓ scope > two
✓ three
```
## Preload hooks
Previously, beforeAll in a preload ran before the first file and
afterAll ran after the last file. Now, beforeAll will run at the start
of each file and afterAll will run at the end of each file. This
behaviour matches Jest and Vitest.
```ts
// preload.ts
beforeAll(() => console.log("preload: beforeAll"));
afterAll(() => console.log("preload: afterAll"));
```
```ts
// preload-ordering-1.test.ts
test("demonstration file 1", () => {});
```
```ts
// preload-ordering-2.test.ts
test("demonstration file 2", () => {});
```
```
$> bun-before test --preload=./preload preload-ordering
preload-ordering-1.test.ts:
preload: beforeAll
✓ demonstration file 1
preload-ordering-2.test.ts:
✓ demonstration file 2
preload: afterAll
```
```
$> bun-after test --preload=./preload preload-ordering
preload-ordering-1.test.ts:
preload: beforeAll
✓ demonstration file 1
preload: afterAll
preload-ordering-2.test.ts:
preload: beforeAll
✓ demonstration file 2
preload: afterAll
```
## Describe failures
Current behaviour is that when an error is thrown inside a describe
callback, none of the tests declared there will run. Now, describes
declared inside will also not run. The new behaviour matches the
behaviour of Jest and Vitest.
```ts
// describe-failures.test.ts
describe("erroring describe", () => {
test("this test does not run because its describe failed", () => {
expect(true).toBe(true);
});
describe("inner describe", () => {
console.log("does the inner describe callback get called?");
test("does the inner test run?", () => {
expect(true).toBe(true);
});
});
throw new Error("uh oh!");
});
```
Before, the inner describe callback would be called and the inner test
would run, although the outer test would not:
```
$> bun-before test describe-failures
describe-failures.test.ts:
does the inner describe callback get called?
# Unhandled error between tests
-------------------------------
11 | throw new Error("uh oh!");
^
error: uh oh!
-------------------------------
✓ erroring describe > inner describe > does the inner test run?
1 pass
0 fail
1 error
1 expect() calls
Ran 1 test across 1 file.
Exited with code [1]
```
Now, the inner describe callback is not called at all.
```
$> bun-after test describe-failures
describe-failures.test.ts:
# Unhandled error between tests
-------------------------------
11 | throw new Error("uh oh!");
^
error: uh oh!
-------------------------------
0 pass
0 fail
1 error
Ran 0 tests across 1 file.
Exited with code [1]
```
## Hook failures
Previously, a beforeAll failure would skip subsequent beforeAll()s, the
test, and the afterAll. Now, a beforeAll failure skips any subsequent
beforeAll()s and the test, but not the afterAll.
```js
beforeAll(() => {
throw new Error("before all: uh oh!");
});
test("my test", () => {
console.log("my test");
});
afterAll(() => console.log("after all"));
```
```
$> bun-before test hook-failures
Error: before all: uh oh!
$> bun-after test hook-failures
Error: before all: uh oh!
after all
```
Previously, an async beforeEach failure would still allow the test to
run. Now, an async beforeEach failure will prevent the test from running
```js
beforeEach(() => {
await 0;
throw "uh oh!";
});
it("the test", async () => {
console.log("does the test run?");
});
```
```
$> bun-before test async-beforeeach-failure
does the test run?
error: uh oh!
uh oh!
✗ the test
$> bun-after test async-beforeeach-failure
error: uh oh!
uh oh!
✗ the test
```
## Hook timeouts
Hooks will now time out, and can have their timeout configured in an
options parameter
```js
beforeAll(async () => {
await Bun.sleep(1000);
}, 500);
test("my test", () => {
console.log("ran my test");
});
```
```
$> bun-before test hook-timeouts
ran my test
Ran 1 test across 1 file. [1011.00ms]
$> bun-after test hook-timeouts
✗ my test [501.15ms]
^ a beforeEach/afterEach hook timed out for this test.
```
## Hook execution order
beforeAll will now execute before the tests in the scope, rather than
immediately when it is called.
```ts
describe("d1", () => {
beforeAll(() => {
console.log("<d1>");
});
test("test", () => {
console.log(" test");
});
afterAll(() => {
console.log("</d1>");
});
});
describe("d2", () => {
beforeAll(() => {
console.log("<d2>");
});
test("test", () => {
console.log(" test");
});
afterAll(() => {
console.log("</d2>");
});
});
```
```
$> bun-before test ./beforeall-ordering.test.ts
<d1>
<d2>
test
</d1>
test
</d2>
$> bun-after test ./beforeall-ordering.test.ts
<d1>
test
</d1>
<d2>
test
</d2>
```
## test inside test
test() inside test() now errors rather than silently failing. Support
for this may be added in the future.
```ts
test("outer", () => {
console.log("outer");
test("inner", () => {
console.log("inner");
});
});
```
```
$> bun-before test
outer
✓ outer [0.06ms]
1 pass
0 fail
Ran 1 test across 1 file. [8.00ms]
$> bun-after test
outer
1 | test("outer", () => {
2 | console.log("outer");
3 | test("inner", () => {
^
error: Cannot call test() inside a test. Call it inside describe() instead.
✗ outer [0.71ms]
0 pass
1 fail
```
## afterAll inside test
afterAll inside a test is no longer allowed
```ts
test("test 1", () => {
afterAll(() => console.log("afterAll"));
console.log("test 1");
});
test("test 2", () => {
console.log("test 2");
});
```
```
$> bun-before
test 1
✓ test 1 [0.05ms]
test 2
✓ test 2
afterAll
$> bun-after
error: Cannot call afterAll() inside a test. Call it inside describe() instead.
✗ test 1 [1.00ms]
test 2
✓ test 2 [0.20ms]
```
# Only inside only
Previously, an outer 'describe.only' would run all tests inside it even
if there was an inner 'test.only'. Now, only the innermost only tests
are executed.
```ts
describe.only("outer", () => {
test("one", () => console.log("should not run"));
test.only("two", () => console.log("should run"));
});
```
```
$> bun-before test
should not run
should run
$> bun-after test
should run
```
With no inner only, the outer only will still run all tests:
```ts
describe.only("outer", () => {
test("test 1", () => console.log("test 1 runs"));
test("test 2", () => console.log("test 2 runs"));
});
```
# Potential follow-up work
- [ ] for concurrent tests, display headers before console.log messages
saying which test it is for
- this will need async context or similar
- refActiveExecutionEntry should also be able to know the current test
even in test.concurrent
- [ ] `test("rerun me", () => { console.log("run one time!"); });`
`--rerun-each=3` <- this runs the first and third time but not the
second time. fix.
- [ ] should to cache the JSValue created from
DoneCallback.callAsFunction
- [ ] implement retry and rerun params for tests.
- [ ] Remove finalizer on ScopeFunctions.zig by storing the data in 3
jsvalues passed in bind rather than using a custom class. We should also
migrate off of the ClassGenerator for ScopeFunctions
- [ ] support concurrent limit, how many concurrent tests are allowed to
run at a time. ie `--concurrent-limit=25`
- [ ] flag to run tests in random order
- [ ] `test.failing` should have its own style in the same way
`test.todo` passing marks as 'todo' insetead of 'passing'. right now
it's `✓` which is confusing.
- [ ] remove all instances of bun.jsc.Jest.Jest.current
- [ ] test options should be in BunTestRoot
- [ ] we will need one global still, stored in the globalobject/vm/?.
but it should not be a Jest instance.
- [ ] consider allowing test() inside test(), as well as afterEach and
afterAll. could even allow describe() too. to do this we would switch
from indices to pointers and they would be in a linked list. they would
be allocated in memorypools for perf/locality. some special
consideration is needed for making sure repeated tests lose their
temporary items. this could also improve memory usage soomewhat.
- [ ] consider using a jsc Bound Function rather than CallbackWithArgs.
bound functions allow adding arguments and they are only one value for
GC instead of many. and this removes our unnecessary three copies.
- [ ] eliminate Strong.Safe. we should be using a C++ class instead.
- [ ] consider modifying the junit reporter to print the whole describe
tree at the end instead of trying to output as test results come in. and
move it into its own file.
- [ ] expect_call_count/expect_assertions is confusing. rename to
`expect_calls`, `assert_expect_calls`. or something.
- [ ] Should make line_no be an enum with a none option and a function
to get if line nombers are enabled
- [ ] looks like we don't need to use file_id anymore (remove
`bun.jsc.Jest.Jest.runner.?.getOrPutFile(file_path).file_id;`, store the
file path directly)
- [ ] 'dot' test reporter like vitest?
- [ ] `test.failing.if(false)` errors because it can't replace mode
'failing' with mode 'skip'. this should probably be allowed instead.
- [ ] trigger timeout termination exception for `while(true) {}`
- [ ] clean up unused callbacks. as soon as we advance to the next
execution group, we can fully clean out the previous one. sometimes
within an execution sequence we can do the same.
- clean by swapping held values with undefined
- [ ] structure cache for performance for donecallback/scopefunctions
- [ ] consider migrating CallbackWithArgs to be a bound function. the
length of the bound function can exclude the specified args.
- [ ] setting both result and maybe_skip is not ideal, maybe there
should be a function to do both at once?
- [ ] try using a linked list rather than arraylist for describe/test
children, see how it affects performance
- [ ] consider a memory pool for describescope/executionentry. test if
it improves performance.
- [ ] consider making RefDataValue methods return the reason for failure
rather than ?value. that way we can improve error messages. the reason
could be a string or it could be a defined error set
- [ ] instead of 'description orelse (unnamed)', let's have description
default to 'unnamed' and not free it if it === the global that defines
that
- [ ] Add a phase before ordering results that inherits properties to
the parents. (eg inherit only from the child and inherit has_callback
from the child. and has_callback can be on describe/test individually
rather than on base). then we won't have that happening in an init()
function (terrible!)
- [ ] this test was incidentally passing because resolves.pass() wasn't
waiting for promise
```
test("fetching with Request object - issue #1527", async () => {
const server = createServer((req, res) => {
res.end();
}).listen(0);
try {
await once(server, "listening");
const body = JSON.stringify({ foo: "bar" });
const request = new Request(`http://localhost:${server.address().port}`,
{
method: "POST",
body,
});
expect(fetch(request)).resolves.pass();
} finally {
server.closeAllConnections();
}
});
```
- [ ] the error "expect.assertions() is not supported in the describe
phase, in concurrent tests, between tests, or after test execution has
completed" is not very good. we should be able to identify which of
those it is and print the right error for the context
- [ ] consider: instead of storing weak pointers to BunTest, we can
instead give the instance an id and check that it is correct when
getting the current bun test instance from the ref
- [ ] auto_killer: add three layers of auto_killer:
- preload (includes file & test)
- file (includes test)
- test
- that way at the end of the test, we kill the test processes. at the
end of the file, we kill the file processes. at the end of all, we kill
anything remaining.
AsyncLocalStorage
- store active_id & refdatavalue. active_id is a replacement for the
above weak pointers thing. refdatavalue is for determining which test it
is. this probably fits in 2×u64
- use for auto_killer so timeouts can kill even in concurrent tests
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
tests not in `test/no-validate-leaksan.txt` will run with leaksanitizer
in CI
leaks documented in `test/leaksan.supp` will not cause a test failure
-- notes about leaksanitizer
- will not catch garbage collected objects accumulated during
long-running processes
- will not catch js objects (eg a strong held to a promise)
- will catch native calls to `malloc` not `free`d
- will catch allocations made in C, Zig, C++, libc, dependencies,
dlopen'd
---------
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
## Summary
This PR introduces a CMake-generated header file containing all
dependency versions, eliminating the need for C++ code to depend on
Zig-exported version constants.
## Changes
- **New CMake script**: `cmake/tools/GenerateDependencyVersions.cmake`
that:
- Reads versions from the existing `generated_versions_list.zig` file
- Extracts semantic versions from header files where available
(libdeflate, zlib)
- Generates `bun_dependency_versions.h` with all dependency versions as
compile-time constants
- **Updated BunProcess.cpp**:
- Now includes the CMake-generated `bun_dependency_versions.h`
- Uses `BUN_VERSION_*` constants instead of `Bun__versions_*`
- Removes dependency on Zig-exported version constants
- **Build system updates**:
- Added `GenerateDependencyVersions` to main CMakeLists.txt
- Added build directory to include paths in BuildBun.cmake
## Benefits
✅ Single source of truth for dependency versions
✅ Versions accessible from C++ without Zig exports
✅ Automatic regeneration during CMake configuration
✅ Semantic versions shown where available (e.g., zlib 1.2.8 instead of
commit hash)
✅ Debug output file for verification
## Test Results
Verified that `process.versions` correctly shows all dependency
versions:
```javascript
$ bun -e "console.log(JSON.stringify(process.versions, null, 2))"
{
"node": "24.3.0",
"bun": "1.2.22-debug",
"boringssl": "29a2cd359458c9384694b75456026e4b57e3e567",
"libarchive": "898dc8319355b7e985f68a9819f182aaed61b53a",
"mimalloc": "4c283af60cdae205df5a872530c77e2a6a307d43",
"webkit": "0ddf6f47af0a9782a354f61e06d7f83d097d9f84",
"zlib": "1.2.8",
"libdeflate": "1.24",
// ... all versions present and correct
}
```
## Generated Files
- `build/debug/bun_dependency_versions.h` - Header file with version
constants
- `build/debug/bun_dependency_versions_debug.txt` - Human-readable
version list
🤖 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?
### How did you verify your code works?
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.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?
### How did you verify your code works?
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Various types have a `deepClone` method, but there are two different
signatures in use. Some types, like those in the `css` directory, have
an infallible `deepClone` method that cannot return an error. Others,
like those in `ast`, are fallible and can return `error.OutOfMemory`.
Historically, `BabyList.deepClone` has only worked with the fallible
kind of `deepClone`, necessitating the addition of
`BabyList.deepClone2`, which only works with the *in*fallible kind.
This PR:
* Updates `BabyList.deepClone` so that it works with both kinds of
method
* Updates `BabyList.deepClone2` so that it works with both kinds of
method
* Renames `BabyList.deepClone2` to `BabyList.deepCloneInfallible`
* Adds `bun.handleOom(...)`, which is like `... catch bun.outOfMemory()`
but it can't accidentally catch non-OOM-related errors
* Replaces an occurrence of `anyerror` with a more specific error set
(For internal tracking: fixes STAB-969, STAB-970)
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
## Summary
- Replace cmake-based clang-format with dedicated bash script that
directly processes source files
- Optimize CI to only install clang-format-19 instead of entire LLVM
toolchain
- Script enforces specific clang-format version with no fallbacks
## Changes
1. **New bash script** (`scripts/run-clang-format.sh`):
- Directly reads C++ files from `CxxSources.txt`
- Finds all header files in `src/` and `packages/` directories
- Respects existing `.clang-format` configuration files
- Requires specific clang-format version (no fallbacks)
- Defaults to format mode (modifies files in place)
2. **Optimized GitHub Action**:
- Only installs `clang-format-19` package with `--no-install-recommends`
- Avoids installing unnecessary components like manpages
- Uses new bash script instead of cmake targets
3. **Updated package.json scripts**:
- `clang-format`, `clang-format:check`, and `clang-format:diff` now use
the bash script
## Test plan
- [x] Verified script finds and processes all C++ source and header
files
- [x] Tested formatting works correctly by adding formatting issues and
running the script
- [x] Confirmed script respects `.clang-format` configuration files
- [x] Script correctly requires specific clang-format version
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude <claude@anthropic.ai>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Splits up js_parser.zig into multiple files. Also changes visitExprInOut
to use function calls rather than switch
Not ready:
- [ ] P.zig is ~70,000 tokens, still needs to get smaller
- [x] ~~measure zig build time before & after (is it slower?)~~ no
significant impact
---------
Co-authored-by: pfgithub <6010774+pfgithub@users.noreply.github.com>
### What does this PR do?
reduce number of zombie build processes that can happen in CI or when
building locally
### How did you verify your code works?
`add` no longer locks a mutex, and `finish` no longer locks a mutex
except for the last task. This could meaningfully improve performance in
cases where we spawn a large number of tasks on a thread pool. This
change doesn't alter the semantics of the type, unlike the standard
library's `WaitGroup`, which also uses atomics but has to be explicitly
reset.
(For internal tracking: fixes ENG-19722)
---------
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
### What does this PR do?
lets you get useful info out of this script even if you set the number
of attempts too high and you don't want to wait
### How did you verify your code works?
local testing
(I cancelled CI because this script is not used anywhere in CI so it
wouldn't tell us anything useful)
### What does this PR do?
- for these kinds of aborts which we test in CI, introduce a feature
flag to suppress core dumps and crash reporting only from that abort,
and set the flag when running the test:
- libuv stub functions
- Node-API abort (used in particular when calling illegal functions
during finalizers)
- passing `process.kill` its own PID
- core dumps are suppressed with `setrlimit`, and crash reporting with
the new `suppress_reporting` field. these suppressions are only engaged
right before crashing, so we won't ignore new kinds of crashes that come
up in these tests.
- for the test bindings used to test the crash handler in
`run-crash-handler.test.ts`, disables core dumps but does not disable
crash reporting (because crashes get reported to a server that the test
is running to make sure they are reported)
- fixes a panic when printing source code around an error containing
`\n\r`
- updates the code where we clone vendor tests to checkout the right tag
- adds `vendor/elysia/test/path/plugin.test.ts` to
no-validate-exceptions
- this failure was exposed by starting to test the version of elysia we
have been intending to test. the crash trace suggests it may be fixed by
#21307.
- makes dumping core or uploading a crash report count as a failing test
- this ensures we don't realize a crash has occurred if it happened in a
subprocess and the main test doesn't adequately check the exit code. to
spawn a subprocess you expect to fail, prefer `expect(code).toBe(1)`
over `expect(code).not.toBe(0)`. if you really expect multiple possible
erroneous exit codes, you might try `expect(signal).toBeNull()` to still
disallow crashes.
### How did you verify your code works?
Running affected tests on a Linux machine with core dumps set up and
checking no new ones appear.
https://buildkite.com/bun/bun/builds/21465 has no core dumps.
I haven't checked all uses of tryTakeException but this bug is probably
not the only one.
Caught by running fuzzy-wuzzy with debug logging enabled. It tried to
print the exception. Updates fuzzy-wuzzy to have improved logging that
can tell you what was last executed before a crash.
---------
Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
### What does this PR do?
Closes#13012
On Linux, when any Bun process spawned by `runner.node.mjs` crashes, we
run GDB in batch mode to print a backtrace from the core file.
And on all platforms, we run a mini `bun.report` server which collects
crashes reported by any Bun process executed during the tests, and after
each test `runner.node.mjs` fetches and prints any new crashes from the
server.
<details>
<summary>example 1</summary>
```
#0 crash_handler.crash () at crash_handler.zig:1513
#1 0x0000000002cf4020 in crash_handler.crashHandler (reason=..., error_return_trace=0x0, begin_addr=...) at crash_handler.zig:479
#2 0x0000000002cefe25 in crash_handler.handleSegfaultPosix (sig=<optimized out>, info=<optimized out>) at crash_handler.zig:800
#3 0x00000000045a1124 in WTF::jscSignalHandler (sig=11, info=0x7ffe044e30b0, ucontext=0x0) at vendor/WebKit/Source/WTF/wtf/threads/Signals.cpp:548
#4 <signal handler called>
#5 JSC::JSCell::type (this=0x0) at vendor/WebKit/Source/JavaScriptCore/runtime/JSCellInlines.h:137
#6 JSC::JSObject::getOwnNonIndexPropertySlot (this=0x150bc914fe18, vm=..., structure=0x150a0102de50, propertyName=..., slot=...) at vendor/WebKit/Source/JavaScriptCore/runtime/JSObject.h:1348
#7 JSC::JSObject::getPropertySlot<false> (this=0x150bc914fe18, globalObject=0x150b864e0088, propertyName=..., slot=...) at vendor/WebKit/Source/JavaScriptCore/runtime/JSObject.h:1433
#8 JSC::JSValue::getPropertySlot (this=0x7ffe044e4880, globalObject=0x150b864e0088, propertyName=..., slot=...) at vendor/WebKit/Source/JavaScriptCore/runtime/JSCJSValueInlines.h:1108
#9 JSC::JSValue::get (this=0x7ffe044e4880, globalObject=0x150b864e0088, propertyName=..., slot=...) at vendor/WebKit/Source/JavaScriptCore/runtime/JSCJSValueInlines.h:1065
#10 JSC::LLInt::performLLIntGetByID (bytecodeIndex=..., codeBlock=0x150b861e7740, globalObject=0x150b864e0088, baseValue=..., ident=..., metadata=...) at vendor/WebKit/Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:878
#11 0x0000000004d7b055 in llint_slow_path_get_by_id (callFrame=0x7ffe044e4ab0, pc=0x150bc92ea0e7) at vendor/WebKit/Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:946
#12 0x0000000003dd6042 in llint_op_get_by_id ()
#13 0x0000000000000000 in ?? ()
```
</details>
<details>
<summary>example 2</summary>
```
#0 crash_handler.crash () at crash_handler.zig:1513
#1 0x0000000002c5db80 in crash_handler.crashHandler (reason=..., error_return_trace=0x0, begin_addr=...) at crash_handler.zig:479
#2 0x0000000002c59f60 in crash_handler.handleSegfaultPosix (sig=<optimized out>, info=<optimized out>) at crash_handler.zig:800
#3 0x00000000042ecc88 in WTF::jscSignalHandler (sig=11, info=0xfffff60141b0, ucontext=0xfffff6014230) at vendor/WebKit/Source/WTF/wtf/threads/Signals.cpp:548
#4 <signal handler called>
#5 bun.js.api.FFIObject.Reader.u8 (globalObject=0x4000554e0088) at /var/lib/buildkite-agent/builds/ip-172-31-75-92/bun/bun/src/bun.js/api/FFIObject.zig:65
#6 bun.js.jsc.host_fn.toJSHostCall__anon_1711576 (globalThis=0x4000554e0088, args=...) at /var/lib/buildkite-agent/builds/ip-172-31-75-92/bun/bun/src/bun.js/jsc/host_fn.zig:97
#7 bun.js.jsc.host_fn.DOMCall("Reader"[0..6],bun.js.api.FFIObject.Reader,"u8"[0..2],.{ .reads = .{ ... }, .writes = .{ ... } }).slowpath (globalObject=0x4000554e0088, thisValue=70370172175040, arguments_ptr=0xfffff6015460, arguments_len=1) at /var/lib/buildkite-agent/builds/ip-172-31-75-92/bun/bun/src/bun.js/jsc/host_fn.zig:490
#8 0x000040003419003c in ?? ()
#9 0x0000400055173440 in ?? ()
```
</details>
I used GDB instead of LLDB (as the branch name suggests) because it
seems to produce more useful stack traces with musl libc.
- [x] on linux, use gdb to print from core dump of main bun process
crashed
- [x] on linux, use gdb to print from all new core dumps (so including
bun subprocesses spawned by the test that crashed)
- [x] on all platforms, use a mini bun.report server to print a
self-reported trace (depends on oven-sh/bun.report#15; for now our
package.json points to a commit on the branch of that repo)
- [x] fix trying to fetch stack traces too early on windows
- [x] use output groups so the traces show up alongside the log for the
specific test instead of having to find it in the logs from the entire
run
- [x] get oven-sh/bun.report#15 merged, and point to a bun.report commit
on the main branch instead of the PR branch in package.json
### How did you verify your code works?
Manually, and in CI with a crashing test.
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
