Is your feature request related to a problem? Please describe.
For repeated measurement cycles (start/stop/extract/clear in a loop), Coverage.erase() is the only reliable reset API on Coverage itself. But erase() sets _inited_for_start = False, so the next start() reruns _init_for_start(), rebuilding Core, Collector, InOrOut, creating a new CoverageData, and registering cleanup handlers again.
In our case (a fuzzer collecting branch/arc coverage thousands of times in no_disk mode), this repeated re-initialization is overhead: tracing configuration does not change between cycles, only collected data does.
Note: this request is not about keeping per-thread tracer instances alive across start()/stop(); Collector.start() recreates tracer instances each time by design.
Describe the solution you'd like
A public method like Coverage.clear_data() that:
- Clears collected coverage data (SQLite rows / in-memory state)
- Keeps existing
Core/Collector/InOrOut wiring intact for the next start()
- Does not set
_inited_for_start = False
- Avoids repeated cleanup-handler registration for every cycle
Usage would be:
cov = coverage.Coverage(branch=True, data_file=None, config_file=False)
for i in range(10000):
cov.start()
do_work()
cov.stop()
data = cov.get_data()
# ... extract arcs/lines from data ...
cov.clear_data() # clear data, keep start-time initialization
Describe alternatives you've considered
- Calling
Coverage.erase() each cycle — functionally works, but reruns _init_for_start() each iteration. In no_disk mode it also accumulates CoverageData/SQLite objects until process shutdown, because old data objects are retained for _atexit force-close.
Additional context
Our use case is a fuzzer that reuses one Coverage instance across thousands of iterations in no_disk mode during compilation. Each iteration compiles different code and we extract arcs, so we need a clean slate each cycle. Include/exclude rules, branch mode, and other tracing configuration are fixed; only coverage data should reset.
Is your feature request related to a problem? Please describe.
For repeated measurement cycles (start/stop/extract/clear in a loop),
Coverage.erase()is the only reliable reset API onCoverageitself. Buterase()sets_inited_for_start = False, so the nextstart()reruns_init_for_start(), rebuildingCore,Collector,InOrOut, creating a newCoverageData, and registering cleanup handlers again.In our case (a fuzzer collecting branch/arc coverage thousands of times in
no_diskmode), this repeated re-initialization is overhead: tracing configuration does not change between cycles, only collected data does.Note: this request is not about keeping per-thread tracer instances alive across
start()/stop();Collector.start()recreates tracer instances each time by design.Describe the solution you'd like
A public method like
Coverage.clear_data()that:Core/Collector/InOrOutwiring intact for the nextstart()_inited_for_start = FalseUsage would be:
Describe alternatives you've considered
Coverage.erase()each cycle — functionally works, but reruns_init_for_start()each iteration. Inno_diskmode it also accumulatesCoverageData/SQLite objects until process shutdown, because old data objects are retained for_atexitforce-close.Additional context
Our use case is a fuzzer that reuses one
Coverageinstance across thousands of iterations inno_diskmode during compilation. Each iteration compiles different code and we extract arcs, so we need a clean slate each cycle. Include/exclude rules, branch mode, and other tracing configuration are fixed; only coverage data should reset.