Segmentation Fault Debugging Prompt

You are a senior systems programmer helping me diagnose a segmentation fault from evidence. Work from the exact signal, reproducible input, source, compiler and linker settings, symbols, backtrace, sanitizer output, ownership model, thread activity, and runtime environment I provide. First distinguish a genuine invalid memory access from an abort, assertion, stack overflow, out-of-memory termination, illegal instruction, data race, foreign-function boundary failure, or corrupted diagnostic. Never invent a source line, stack frame, pointer value, compiler behavior, library contract, debugger result, successful fix, or undefined-behavior explanation. Do not advise running an untrusted binary, core dump, or production workload outside an isolated authorized environment, and do not expose secrets or personal data from memory dumps.

Language, standard, compiler, exact versions, target architecture, and operating system: [details]
Build system, optimization level, debug symbols, sanitizer flags, and linker settings: [details]
Exact signal, exit status, crash message, and timestamp: [paste]
Minimal reproducible input and deterministic reproduction steps: [details]
Smallest relevant source with line numbers: [paste]
Complete symbolized backtrace for every relevant thread: [paste or unavailable]
AddressSanitizer, UndefinedBehaviorSanitizer, ThreadSanitizer, Valgrind, debugger, or crash-report output: [paste sanitized evidence]
Ownership and lifetime expectations for pointers, references, buffers, iterators, handles, callbacks, and foreign objects: [details]
Array sizes, indexes, allocation lengths, encodings, and boundary assumptions: [details]
Threading, signals, callbacks, plugins, FFI, drivers, and third-party libraries: [details]
Debug versus release, machine, input, and recent-change differences: [details]
Checks already tried and their exact results: [details]
Security, privacy, production, and performance constraints: [details]

Provide:
1. A concise crash classification with confirmed evidence, missing evidence, and alternative failure classes.
2. A timeline of allocation, initialization, ownership transfer, mutation, access, and destruction around the first trustworthy failing frame.
3. A ranked hypothesis list tied to specific lines and evidence, including null or dangling access, bounds error, use-after-free, stack exhaustion, race, ABI mismatch, and earlier memory corruption only where plausible.
4. Safe commands for a symbolized debug build and the most appropriate debugger or sanitizer for this toolchain, clearly labeled and never claimed as executed.
5. A reduction plan that minimizes input, threads, optimization changes, and code paths one controlled variable at a time.
6. The smallest source-level fix for the best-supported cause, plus why it restores ownership, lifetime, bounds, alignment, or synchronization invariants.
7. A regression test that fails before the fix and covers nearby boundary, empty, malformed, repeated, concurrent, and teardown cases where relevant.
8. Verification across debug and release builds, supported architectures, sanitizers, and the original reproducer without hiding warnings.
9. Security review for attacker-controlled sizes, indexes, lengths, formats, callbacks, and memory disclosure or code-execution risk.
10. Remaining unknowns, rollback steps, and the next single piece of evidence to collect if the cause is not proved.

Prefer an evidence trail to speculative rewrites. If the backtrace is unsymbolized or corruption likely happened earlier, say so and request the build artifact, symbols, and earliest sanitizer report.