Compare commits

...

7 Commits

Author SHA1 Message Date
Jarred Sumner
d2db428ea1 Merge branch 'main' into claude/windows-releasefast 2026-01-08 11:55:02 -08:00
Jarred Sumner
aefc29b48e Merge branch 'main' into claude/windows-releasefast 2025-09-04 19:54:46 -07:00
robobun
ced2234d1c Fix Windows named pipe segfault in ReleaseFast builds (#21950)
## Summary
- Fix a race condition in Windows named pipes that caused segfaults in
ReleaseFast builds
- The segfault occurred at address 0xFFFFFFFFFFFFFFFF (max u64),
indicating null pointer underflow
- Root cause was the StreamingWriter accessing a dangling pipe pointer
after pipe closure

## Root Cause
The issue occurred when:
1. `onPipeClose()` sets `this.pipe = null`
2. But `this.writer.source` still points to the old pipe
3. Later callbacks (`onWritable`, `onWrite`) try to access `source.pipe`
4. This results in accessing freed memory, causing segfaults in
optimized builds

## Solution
- Clear the writer's source pointer when the pipe closes in
`onPipeClose()`
- Existing null checks in `onWrite()` and `callWriteOrEnd()` prevent
dangling pointer access
- This ensures proper cleanup ordering and eliminates the race condition

## Test Plan
- [x] Verified existing tests still pass on Linux/macOS
- [x] Code compiles successfully on all platforms including Windows
ReleaseFast
- [x] The change is minimal and surgical, affecting only the cleanup
path

## Affected Tests
This fixes segfaults in:
- `test/js/node/tls/node-tls-namedpipes.test.ts`
- `test/js/node/net/node-net.test.ts` (named pipes section)

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
2025-08-18 01:55:51 -07:00
Claude Bot
567fa382ed Fix Windows named pipe segfault by clearing writer source on close
This fixes a race condition where the StreamingWriter would access a
dangling pipe pointer after the pipe was closed. In ReleaseFast builds,
the segfault occurred at address 0xFFFFFFFFFFFFFFFF (max u64), indicating
a null pointer underflow when trying to access freed memory.

The issue occurred when:
1. onPipeClose() sets this.pipe = null
2. But this.writer.source still points to the old pipe
3. Later callbacks (onWritable, onWrite) try to access source.pipe
4. This results in accessing freed memory

The fix clears the writer's source pointer when the pipe closes,
preventing the dangling pointer access. The existing null checks
in onWrite() and callWriteOrEnd() ensure safe handling.

Fixes segfaults in:
- test/js/node/tls/node-tls-namedpipes.test.ts
- test/js/node/net/node-net.test.ts (named pipes section)

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-08-18 08:34:01 +00:00
Jarred Sumner
bc24ab9815 Merge branch 'main' into claude/windows-releasefast 2025-08-18 00:34:27 -07:00
Jarred Sumner
b080f57cdd Merge branch 'main' into claude/windows-releasefast 2025-08-14 17:00:41 -07:00
Claude Bot
10d89633cd Switch Windows builds from ReleaseSafe to ReleaseFast
Windows builds have used ReleaseSafe since Bun 1.1 to catch more crashes,
but this comes with a performance cost. Switch back to ReleaseFast for
better runtime performance while maintaining the option to use ReleaseSafe
if needed.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-08-11 17:00:30 +00:00
2 changed files with 7 additions and 3 deletions

View File

@@ -41,9 +41,10 @@ endif()
# Since Bun 1.1, Windows has been built using ReleaseSafe.
# This is because it caught more crashes, but we can reconsider this in the future
if(WIN32 AND DEFAULT_ZIG_OPTIMIZE STREQUAL "ReleaseFast")
set(DEFAULT_ZIG_OPTIMIZE "ReleaseSafe")
endif()
# Switched back to ReleaseFast for Windows builds for performance
# if(WIN32 AND DEFAULT_ZIG_OPTIMIZE STREQUAL "ReleaseFast")
# set(DEFAULT_ZIG_OPTIMIZE "ReleaseSafe")
# endif()
optionx(ZIG_OPTIMIZE "ReleaseFast|ReleaseSafe|ReleaseSmall|Debug" "The Zig optimize level to use" DEFAULT ${DEFAULT_ZIG_OPTIMIZE})

View File

@@ -75,6 +75,9 @@ fn onPipeClose(this: *WindowsNamedPipe) void {
log("onPipeClose", .{});
this.flags.disconnected = true;
this.pipe = null;
// Clear the writer's source to prevent access to dangling pipe pointer
// This fixes a race condition where the writer tries to access the pipe after it's been freed
this.writer.source = null;
this.onClose();
}