Open flavio opened 1 day ago
So each executable ran will generate a prof raw, so how rust's test stuff decides to split things into binaries and any spawned processes built as part of the tests will generate one.
As for the memory usage, unfortunately rust flags are applied to every crate in your dependency tree and all of them will be instrumented for coverage information as a result. This can result in an enormous amount of bloat with a full dependencies instrumented with counters that are often just 0 if it's library functionality you never use...
Still there is likely some room for me to minimise this some more... Out of curiosity have you tried with cargo-llvm-cov
and seen if it hits similarly high memory usage?
Still there is likely some room for me to minimise this some more... Out of curiosity have you tried with cargo-llvm-cov and seen if it hits similarly high memory usage?
I've tried cargo-llvm-cov
, it's memory consumption is significantly lower:
Finished report saved to /home/flavio/hacking/kubernetes/kubewarden/kwctl/target/llvm-cov/html
Command being timed: "cargo llvm-cov --html"
User time (seconds): 1710.16
System time (seconds): 34.59
Percent of CPU this job got: 590%
Elapsed (wall clock) time (h:mm:ss or m:ss): 4:55.32
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 3972312
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 995
Minor (reclaiming a frame) page faults: 5570003
Voluntary context switches: 86879
Involuntary context switches: 423985
Swaps: 0
File system inputs: 136
File system outputs: 12062096
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
Describe the bug
We're using tarpaulin to collect coverage of end-to-end test of kwctl, a Rust cli tool.
The tests are running fine and produce many
profraw
files. I've seen we are generating 138(!!!) files, maybe we're doing something stupid?!It looks like there's a memory leak when these files are aggregated. The "Merging coverage reports" step takes a long time and, while running, the memory usage increases significantly. On my system I've witnessed tarpaulin consume up to 28 GB of memory.
When running inside of a GitHub Action, tarpaulin is killed because it's consuming too much memory.
To Reproduce
We're using tarpaulin 0.31.2, with Rust 1.82.0, on x86_64 Linux.
The issue can be reproduced in this way:
kwctl
codemake coverage-e2e-tests
or justcargo tarpaulin --verbose --skip-clean --engine=llvm --all-features --implicit-test-threads --test e2e --out xml --out html --output-dir coverage/e2e-tests
You can also run these command by prepending GNU Time to have a rough idea about the amount of memory being used:
Expected behavior
The usage of memory should not be so high.