Skip to content

fix: stabilize process streams, ARM64 LLVM ownership, and IOCP restart - #606

Merged
LunaStev merged 3 commits into
wavefnd:masterfrom
LunaStev:fix/process-arm64-iocp-lifetimes
Sep 12, 2026
Merged

fix: stabilize process streams, ARM64 LLVM ownership, and IOCP restart#606
LunaStev merged 3 commits into
wavefnd:masterfrom
LunaStev:fix/process-arm64-iocp-lifetimes

Conversation

@LunaStev

Copy link
Copy Markdown
Member

Fix child stream remapping, native ARM64 compiler allocator ownership, and Windows socket reuse across executor shutdown. Each issue has its own commit.

  • Preserve shared and cyclic descriptors when remapping child standard streams #558: Snapshot changing stream sources before remapping destinations. Preserve shared sources, two-way swaps, three-way cycles, and closed standard slots; reject invalid sources before temporary duplicates can occupy their descriptor numbers. Native regressions also check parent ownership and temporary descriptor cleanup.
  • Investigate native Windows ARM64 access violations across Wave cases #493: Use the static MSVC CRT for the ARM64 Rust host and provisioned libxml2, matching the pinned LLVM SDK's embedded rpmalloc. Repeat the CRT flag in provisioning's RUSTFLAGS, which overrides Cargo target configuration. Keep ordinary LLVM string destruction and add a native LLVM message/layout allocation-and-disposal test.
  • Keep live sockets usable across task executor shutdown and restart on Windows #531: Track IOCP socket associations separately from executor ownership. Shutdown drains operations and joins callbacks before releasing the executor reference; live sockets retain their port until successfully closed through the socket provider. Repeated shutdown, cancellation, socket reuse, and closing sockets before/after shutdown are covered by a native fixture. Windows ARM64 CI explicitly runs it using MSVC output.

The allocator diagnosis uses the existing native ARM64 diagnostic artifact. Its PDB and disassembly show LLVMCopyStringRepOfTargetData calling the dynamic-CRT _strdup import, while LLVMDisposeMessage branches to the executable's rpmalloc free; the recorded crash RVA 0xae8a98 lies in that function. The static CRT keeps these allocation helpers in the same allocator domain. This corrects the linkage rather than bypassing disposal.

Validation:

  • cargo test --locked --workspace --all-targets --jobs 2: 195 tests passed on Linux.
  • cargo clippy --locked --workspace --all-targets --jobs 2 -- -D warnings, Rust formatting, std policy, workflow YAML parsing, and git diff --check passed.
  • New runtime regressions passed on native Linux; Windows x64/ARM64 GNU/MSVC object emission passed, including the core64 feature configuration.
  • Windows GNU x64 executor fixture under an isolated Wine prefix: original IOCP code exits 31; patched code exits 0. Shared stdout/stderr spawn: original code exits 12; patched code exits 0.
  • Native Windows ARM64 results remain pending PR CI. Local Linux/Wine checks do not establish native ARM64 success; CI includes both the allocator regression and MSVC executor restart regression.

Fixes #558
Fixes #493
Fixes #531

Fixes wavefnd#558. Snapshot changing sources before remapping standard streams, preserve closed standard slots, and clean up temporary descriptors. Add bounded native regressions for shared output, cycles, and invalid sources.
Fixes wavefnd#493. Link the Rust host and libxml2 with the static MSVC CRT required by the pinned LLVM SDK's embedded rpmalloc. The failing native artifact imports _strdup from the dynamic CRT but routes LLVMDisposeMessage to rpmalloc free. Keep normal string disposal and exercise C API message/layout ownership in native ARM64 CI.
Fixes wavefnd#531. Track associated socket ownership separately from the executor, drain operations before releasing its reference, and reclaim ports after the last managed socket closes. Exercise repeated exchange, cancellation, executor restart, and both socket-close orderings with bounded native regressions and Windows target coverage.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

1 participant