Skip to content

stress: locate panics per thread, and say when a panic is in a dependency - #2

Merged
nimbrel merged 5 commits into
mainfrom
fix/panic-sites-and-attribution
Sep 26, 2026
Merged

nimbrel merged 5 commits into
mainfrom
fix/panic-sites-and-attribution

Conversation

@nimbrel

@nimbrel nimbrel commented Sep 26, 2026

Copy link
Copy Markdown
Contributor

Panic findings from stress were matched to callables by message text, so two sites that panic with the same message could be filed under one callable, and a second site could disappear.

  • The driver records each panic's native thread id and callable in call order; Rust prints the same id in its panic line, so each finding is one site naming the callables that panicked there, with their own counts. Without a thread id, a finding lists every site sharing the message.
  • A panic whose site is in a dependency (a registry or git crate, the standard library, or PyO3's argument conversion) names it and its version, and the headline counts it separately. When the log holds a Rust backtrace, the first frame in the crate's own code is the location; otherwise the message suggests a replay with RUST_BACKTRACE=1.
  • A stress/panic message says when mutators were running.
  • JSON gains stress.panics, stress.panic_threads and a dependency field on dependency panics.

Always-on backtraces were measured and left off: they slowed calls about tenfold and changed the schedule under test.

New fixture racy/stress-panic-two-sites plus 10 tests.

Panic sites were matched to callables by message text, so two sites that
panic with the same message were filed under whichever printed first, and
the second site never appeared as a finding.

The driver now records, per native thread, which callable panicked and in
what order, and keeps every distinct panic message per callable with a
count. Rust prints the same thread id in its panic line, so the two
sequences are joined in order: each site gets exactly the calls that
panicked there, and a callable that panicked at two sites is counted at
each. When Rust prints no thread id, a panic is located by message
and a finding names every site that shares it.

Signed-off-by: nimbrel <[email protected]>
…rame

A panic inside a dependency (PyO3's conversions, any other crate, or the
standard library) was located at the dependency's line with no stack, and
the headline called it a panic "in your extension".

The finding now says which dependency and version the site is in, names
PyO3's argument conversion when it is there, and carries a `dependency`
field; the headline counts such panics as "inside a dependency, reached
from your extension". When the log holds a Rust backtrace, the first frame
in the crate's own code becomes the location and the frames down to it
become the stack; otherwise the message says to replay with
RUST_BACKTRACE=1. Backtraces stay off by default: turned on for a whole
run they slow each panicking call about tenfold, which changes the
schedule being tested.

Signed-off-by: nimbrel <[email protected]>
The single-threaded baseline never sees a mutator's transient state, so a
call that panics on input a mutator made invalid read as a plain
concurrency panic. When mutators ran, the stress/panic message now names
them and restates the rule they must follow: keep the shared inputs valid
at every instant.

Signed-off-by: nimbrel <[email protected]>
Neither method panics on one thread; each panics at its own line once two threads overlap, with the same message. The sanitizer ground truth asserts one stress/panic finding per line, each naming only its own method.

Signed-off-by: nimbrel <[email protected]>
Remove the message-matching limitation, describe the dependency label and the RUST_BACKTRACE replay, and add an Unreleased CHANGELOG section with the new JSON fields.

Signed-off-by: nimbrel <[email protected]>
@nimbrel
nimbrel merged commit de93bf3 into main Sep 26, 2026
6 checks passed
@nimbrel
nimbrel deleted the fix/panic-sites-and-attribution branch September 28, 2026 12:44
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.

1 participant