Repository navigation
test: Harden CrashE2E timeout diagnostics - #9390
Closed
supervacuus wants to merge 4 commits into
Closed
supervacuus wants to merge 4 commits into
supervacuus wants to merge 4 commits into
Conversation
Accept either stopped state when waiting for termination. The last PID is diagnostic context, not a requirement for a confirmed stop. Cover simulator confirmation, no-such-process responses, unknown state, and invalidation of either stop confirmation by a subsequent launch.
Validate target-only binary capture and offline reporting on the CrashE2E macOS CI image before replacing timeout diagnostics. Check interrupted collection against a non-root heartbeat target and retain raw data across a deliberately stalled reporting phase. Upload probe evidence on success as well as failure. Keep sample unchanged until the collector has been validated.
supervacuus
added
the
run-full-ci
Size Analysis1 component analyzed iOS Builds
|
📲 Install BuildsiOS
|
Replace the eight-second sample invocation with a symbolicated, target-only spindump and a requested 60-second collection budget. Preserve scenario deadlines, cleanup, and missing-evidence diagnostics. Validate the non-root sudo invocation on CI. Keep the deliberate SIGINFO wait as an explicit observation rather than confusing it with normal capture behavior. Retain target-safety checks and fix the experimental probe group limit for macOS.
Add an opt-in app scenario that waits after SDK startup and a live Swift test of the normal timeout, stack capture, and cleanup path. Require symbolicated app stacks and a passing following scenario while retaining the original timeout failure. Reuse the ordinary iOS CI builds for both reporters and preserve separate timeout-test artifacts even when the test passes.
Contributor
🚨 Detected changes in high risk code 🚨High-risk code can easily blow up and is hard to test. We had severe bugs in the past. Be extra careful when changing these files, and have an extra careful look at these:
|
Collaborator
Author
|
closing in favor of #9412 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
(from @supervacuus: I only let the clanker iterate on some pathologies in the CI environment rather than my local machine, so that I can continue my work on #9327. Feel free to ignore this; I will drop it once I have sensible findings and create a new PR with cleaned up and reviewed changes)
Summary
Develop safer CrashE2E timeout diagnostics following #9345. Recent failures attempted
sample <pid> 2, but its eight-second command timeout discarded every inspected stack report, including captures already processing symbols.This draft starts with two separately reviewable changes:
.stopped(lastPID: nil)inwaitForAppToStop, with regression coverage for both stopped states and invalidation by subsequent launches.spindumpfeasibility probe to the existing macOS 26 SentryCrash iOS job. Production stack collection remains unchanged until the probe results and cancellation mechanism have been reviewed.Capture validation
The probe runs its target as the normal runner user and checks:
Probe artifacts are uploaded even on success: results, command output/timing, raw captures, reports, and the fixture binary/dSYM. Successful cancellation tests do not prove the absence of every race; collection must also be reviewed for ownership of target suspension before adoption.
The scenario's original timeout/failure is not relaxed. The intended follow-up in this draft is to integrate a validated capture/report pipeline and retain the state fix in the same PR.
Local validation
make format,make analyze, workflow lint, and pre-commit hooks passed.#skip-changelog