Skip to content

[Backtracing][Linux] Correctly handle signals from other processes.#89461

Draft
al45tair wants to merge 1 commit into
swiftlang:mainfrom
al45tair:eng/PR-177740814
Draft

[Backtracing][Linux] Correctly handle signals from other processes.#89461
al45tair wants to merge 1 commit into
swiftlang:mainfrom
al45tair:eng/PR-177740814

Conversation

@al45tair
Copy link
Copy Markdown
Contributor

It's possible to kill -SEGV or kill -ILL a Swift program; when this happens, we need to be aware and handle it slightly differently to normal, because the signal we get doesn't have the same information attached to it that it normally would.

Additionally we need to make sure the behaviour is as expected. That means, for PID 1, the process should output a backtrace and continue running, while in the normal case the process should terminate with a status code reflecting the signal that was delivered.

rdar://177740814

@al45tair al45tair requested review from carlpeto and weissi May 27, 2026 11:04
@al45tair al45tair requested a review from mikeash as a code owner May 27, 2026 11:04
@al45tair al45tair marked this pull request as draft May 27, 2026 11:04
@al45tair
Copy link
Copy Markdown
Contributor Author

@swift-ci Please smoke test

// this case what we want to do is stop the memory server and
// reinstall the signal handlers in order that we catch future
// crashes.
memserver_stop();
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@al45tair I don't love this because that's functionality that's only accessible from PID 1. Would it not be possible to re-raise the signal in a way that's guaranteed to kill the process even as pid 1?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It won't ever kill the process if it's PID 1, because Linux protects PID 1 processes from being killed by crashes(!)

Trying to terminate would actually change the standard behaviour for PID 1. I did think about it, but I don't think we should do that.

It's possible to `kill -SEGV` or `kill -ILL` a Swift program; when
this happens, we need to be aware and handle it slightly differently
to normal, because the signal we get doesn't have the same
information attached to it that it normally would.

Additionally we need to make sure the behaviour is as expected.
That means, for PID 1, the process should output a backtrace *and
continue running*, while in the normal case the process should
terminate with a status code reflecting the signal that was
delivered.

rdar://177740814
@al45tair al45tair force-pushed the eng/PR-177740814 branch from c33828b to 7663621 Compare May 27, 2026 13:13
@al45tair
Copy link
Copy Markdown
Contributor Author

@swift-ci Please smoke test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants