SSLConfig: fix stale allocator names in dupe_z doc comments

Closed
RO
1mo ago
+2-2

Follow-up to #30875, requested in https://github.com/oven-sh/bun/pull/30875#discussion_r3264310978.

Problem

  • Two doc comments in src/runtime/socket/SSLConfig.rs (lines 61 and 67) name the wrong allocator. One says mi_free frees the dupe_z result. The other says dupe_z makes "a fresh mimalloc allocation".
  • Both contradict the block comment above them, which #30875 rewrote. bun_core::dupe_z allocates with bun_alloc::default_alloc::malloc (src/bun_core/util.rs:3685). free_sensitive_cstr frees with default_alloc::free (src/bun_alloc/lib.rs:1038). Under cfg(bun_asan) that is libc, not mimalloc.

Fix

  • Change the two comments to say free_sensitive and "default-allocator allocation". No code changes.
  • No test. The diff is two doc-comment lines, so the compiled binary is identical before and after. There is no behavior a test can observe.
  • Verified: cargo check -p bun_runtime is clean. bun bd builds and links.

Background

  • SSLConfig owns C strings (keys, passphrases) that the HTTP layer frees. The allocation and the free must use the same allocator. The block comment at lines 52 to 59 documents this contract. The two comments below it are the ones this PR corrects.
Notes

This PR first also carried a fix for src/install/PackageManager/security_scanner.rs. finish_spawn released the start() ref on both result arms, but StaticPipeWriter::start() already releases its own ref on Err. On the Err path this freed the writer while json_writer still pointed at it, and the cleanup guard then touched freed memory. #40478 (82123d3a61) fixed this on main: finish_spawn now returns before the deref when start() fails, and the RefPtr locals release on Drop. The rebase onto that commit dropped the security_scanner.rs hunk as superseded. Only the doc comment change remains.

No regression test: the diff changes comments only.