mozilla / grcov

Rust tool to collect and aggregate code coverage data for multiple source files
Mozilla Public License 2.0
1.17k stars 148 forks source link

Adding a timout command when running the executable file could cause wrong coverage result #1065

Open cicilzx opened 1 year ago

cicilzx commented 1 year ago

I'm not sure it is a bug or my incorrect behaviour. Here is what I did:

  1. A simple Rust code:

    fn main() {}
  2. Build, run, and get coverage information:

    rustc -C instrument-coverage file.rs
    ./file
    grcov . --binary-path ./file -s ./file.rs -t lcov --branch --ignore-not-existing --ignore '../*' --ignore "/*" -o ./lcov1.info

    The rusult goes well, like this:

    TN:
    SF:
    FN:1,file10::main
    FNDA:1,file10::main
    FNF:1
    FNH:1
    BRF:0
    BRH:0
    DA:1,1
    DA:2,1
    DA:3,1
    LF:3
    LH:3
    end_of_record
  3. But if I add a timeout command like this:

    rustc -C instrument-coverage file.rs
    timeout 30m ./file
    grcov . --binary-path ./file -s ./file.rs -t lcov --branch --ignore-not-existing --ignore '../*' --ignore "/*" -o ./lcov2.info

    The coverage result is output like this:

    TN:
    SF:
    FN:1,file10::main
    FNDA:1,file10::main
    FNF:1
    FNH:1
    BRF:0
    BRH:0
    DA:1,1
    DA:2,1
    DA:3,1
    LF:3
    LH:3
    end_of_record
    SF:
    FN:1,file10::main
    FNDA:1,file10::main
    FNF:1
    FNH:1
    BRF:0
    BRH:0
    DA:1,1
    DA:2,1
    DA:3,1
    LF:3
    LH:3
    end_of_record

    I don't understand why there are two end_of_record, and the second group of coverage infomation seems to be odd. Is this a bug of rustc or grcov? Or is there something wrong with the way I'm doing it that causes the results to be incorrect?