What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
The most reliable way to get a crash fixed upstream is to make it happen on demand inside a test, then submit that test with the report or the patch. The test does two jobs: it proves the failure exists in a form maintainers can run, and it guards against the bug coming back once it is fixed. Even if you cannot write the fix yourself, a test that fails today and should pass after the fix is a useful contribution.
This guide walks through the sequence using pytest, the Python testing framework, as a concrete example. The steps are general, but the commands and markers are pytest-specific, and each upstream project has its own contribution rules.
Decide what the test should assert
A characterization test records what the code actually does. For a crash, that creates a small tension: the behavior you want to record is wrong. The practical answer is to write the test around the correct behavior and mark it as an expected failure until the bug is fixed. The test then documents the crash, fails for the right reason, and keeps the rest of the suite green.
pytest’s Contributing guidance puts it this way: “If you can write a demonstration test that currently fails but should pass (xfail), that is a very useful commit to make as well, even if you cannot fix the bug itself.” The quote comes from the pytest documentation’s Contributing page.
#1 Best Overall
- Used Book in Good Condition
Step 1: Preserve the observed failure as a test
Before you edit any implementation code, write down three things: the operation you ran, the inputs that triggered the failure, and the difference between expected and actual behavior. Then turn that into a test.
Reduce the setup only where doing so does not change the result. Remove unrelated fixtures, files, and configuration until the smallest input still crashes. Keep anything the crash depends on, even if it looks irrelevant.
A minimal example for a parser that crashes on empty input:
import pytest
from mylib import parse_header
@pytest.mark.xfail(strict=True, reason="Crashes on empty input; fix pending upstream")
def test_empty_header_does_not_crash():
result = parse_header(b"")
assert result is NoneThe strict=True argument matters. If someone fixes the bug and the test starts passing, pytest reports that as a failure, which prompts the maintainer to remove the marker and turn the demonstration into an ordinary regression test.
Step 2: Record the environment
Maintainers can only recreate a failure they can describe. Include the following in the report and, where relevant, in the test’s surrounding notes:
- Operating system and version
- Python interpreter version
- pytest version
- Installed libraries that the code path touches, with exact versions
- Any environment variables, configuration files, or command-line flags that change behavior
- The exact command that runs the failing test
Do not assume the crash is independent of platform or dependency versions until you have checked. A failure that appears only on one operating system or with one library release is still a valid bug, but the report has to say so.
Step 3: Diagnose without losing the reproducer
Keep the failing test as the fixed point while you investigate. Two pytest features help with diagnosis.
Drop into the debugger with –pdb
Run the single test and pytest will open the Python debugger at the point of failure:
pytest test_header.py::test_empty_header_does_not_crash --pdbUse this to inspect local variables and the call stack. Note that a marked xfail test may not stop in the debugger in the same way as a plain failing test, so temporarily remove the marker during investigation if you need to step through it.
Read faulthandler tracebacks
pytest documents faulthandler output for segmentation faults and for timeouts. When the process dies at the C level, a Python traceback alone may not show where it happened. The faulthandler output shows the Python frames active at the moment of the fault, which narrows down which call to examine.
Treat both tools as diagnostic aids. They help you understand the crash; they do not replace the failing test or the environment record.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Step 4: Confirm the failure is stable
A reproducer that sometimes passes is a weak regression signal. pytest’s documentation describes flaky tests as sporadic failures and names uncontrolled system state and insufficient environmental isolation among the common causes. Teams that tolerate flaky results start to distrust the suite and can miss real failures.
Rank #4
- Gift Idea: This acrylic is carefully designed and can be given as a gift to family, friends, colleagues, etc., to express your love and care and make people feel happy
- Decorative Gift: This decorative gift is exquisite and meaningful, and its interesting language can add a different atmosphere to ordinary daily spaces such as home, office, study, etc., and enhance visual appeal
- Suitable Size: 4 x 4 inch acrylic sign, 4 x 1.5 x 0.8 inch wooden frame. The size is just right, does not take up a lot of space, and is convenient to use and place anywhere
- Desktop Decoration: This acrylic can be placed on a flat surface for display, not only on the table but also on bookshelves, bookcases, dressing tables, etc., to decorate different places
- Lightweight and High Quality: Made of high-quality acrylic, with clear printing, not easy to fade and wear, relatively light and durable
Run the test repeatedly before you submit it. On a POSIX shell:
for i in $(seq 50); do
pytest test_header.py::test_empty_header_does_not_crash -q || break
doneIf the outcome changes between runs, look for shared state first: temporary files, environment variables, module-level caches, random seeds, the current working directory, and test ordering. Fix or document the source before submitting, so the maintainer does not have to reverse-engineer a noisy signal.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Step 5: Submit through the project’s upstream process
Once the test is stable and the environment is recorded, send it upstream. The steps differ by project, so start with the target repository’s own contribution guide and current bug-report template.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemspytest’s contribution documentation describes fixing an issue on the main branch through a regular pull request, and it describes a separate process for backporting bug fixes to patch releases. Those are pytest’s rules. Another project may require an issue first, a specific branch, a changelog entry, or a signed contributor agreement.
Best Value
The table below lists what a complete report usually contains. Match the field names and format to the target project’s template.
| Item | What to include | Why maintainers need it |
|---|---|---|
| Minimal reproducer | The smallest failing test, with the marker and reason | Lets them run the failure directly |
| Expected vs. actual | The correct result and the observed crash or exception | Separates the bug from a misunderstanding of the API |
| Environment | OS, Python, pytest, and relevant library versions | Shows whether the failure is version- or platform-specific |
| Exact command | The command line used to run the test | Removes ambiguity about flags and selection |
| Stability note | How many runs failed, and any known triggers | Tells them whether the signal is reliable |
| Patch status | Whether you have a fix, and whether the test is submitted with it | Determines whether the test is a standalone contribution or part of a pull request |
Scope and limits
This sequence is a pytest workflow. The techniques it relies on, including characterization tests, the xfail marker, and the pdb and faulthandler tools, depend on the pytest version you run and on the target project’s conventions. Check the current pytest documentation and the target repository’s contribution guide before you submit, because both change over time.
The guidance above does not establish how to capture crashes in other languages, and it does not establish that any particular approach reduces regression rates or shortens fix times. Judge each upstream project by its own rules.
Free tools Windows power users keep installed
One-click scans. No signup required.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
