Skip to content

Fix process channel cleanup after exit - #298

Open
pauljccode wants to merge 1 commit into
rapid7:masterfrom
pauljccode:fix/process-channel-lifetime
Open

pauljccode wants to merge 1 commit into
rapid7:masterfrom
pauljccode:fix/process-channel-lifetime

Conversation

@pauljccode

@pauljccode pauljccode commented Oct 3, 2026 •

Copy link
Copy Markdown

An exited process can leave a dangling pointer in its channel. If the allocator reuses that address, closing the old channel can send SIGINT to a newer child. The failing log shows a new child receiving SIGINT immediately after delayed channel-close requests, consistent with this defect; allocator reuse was not captured.

Detach the process in the exit callback, allow cleanup after normal exit, and free the callback context on every exit path. Remove the read-time shutdown to avoid freeing the detached channel while channel_read still uses it. Non-interactive channels retain read-response-before-close ordering.

Related to #64 and #65, which addressed callbacks retaining a freed channel; this fixes a channel retaining a freed process.

Verification:

  • Mettle Verify: all eight macOS/Linux Ruby jobs passed, each with 65 examples and zero failures.
  • Acceptance and repeated checks: Linux passed 51 examples and native Intel macOS passed 46, plus ten focused post/test/cmd_exec repetitions per platform.

Detach exited processes before freeing them so delayed channel cleanup cannot signal a newer process through reused heap storage. Let the existing EOF exchange close drained channels, make cleanup after normal exit safe, and release the callback context on every exit path.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Todo

Development

Successfully merging this pull request may close these issues.

1 participant