mozilla / grcov Goto Github PK

As discussed on IRC, it would be nice to have an output format specifier that outputs coveralls format, but also adds function information to each child (esp. from where to where, line-wise, functions are in the source file).

This information is very useful for automated analysis on a per-function basis.

Changes in GCC 8:
gcc-mirror/gcc@a82502d
gcc-mirror/gcc@3cf7fdd

cc @sylvestre

Using grcov prevents debugging the ETL pipeline on my local windows machine.

Hopefully the rust standard lib can perform this.

https://github.com/marco-c/grcov/blob/master/src/main.rs#L50

fn rmdir(directory: &str) {
    let status = Command::new("rm") 

Each covered line is in the covered array as an object (eg {"line": 42}). Please add the coverage count to this object under count property:

Example, Line 42 has been executed 4 times:

{"line": 42, "count": 4}

The count property should not be included if the count is 1. There should be no objects with count of zero.

Mainly, we will run into issues with paths.

I added it for compatibility with ActiveData-ETL, but it should be removed both here and from ActiveData-ETL.

I had a hard time yesterday finding the new c/c++ coverage records. Maybe we should mark them as such.

I suggest adding {"source.language": "c/c++"} (lowercase).

It doesn't work anymore since the introduction of the C++ code.

The ActiveData ETL machines use grcov, but their drives are being filled with files like

/tmp/grcov.nfGLoxvBaMDa

is grcov cleaning up after it is done?

@jcranmer

Currently we support outputting it in the Coveralls format, we should support the LCOV format too.

At the moment, grcov supports reading gcno/gcda files from ZIP archives and directories, but it doesn't support reading gcno files from a ZIP archive and gcda files from a directory.

For more context, see https://bugzilla.mozilla.org/show_bug.cgi?id=1350446

I'd like to run grcov on a one-click loaner. The default version of gcc on the loaner is incompatible with grcov. There is no easy way to install a newer version.

• We could ask to reconfigure the one-click-loaner environment to match what is actually used for the build.
• Can grcov support earlier versions of gcc?

The default version of gcc available on a one-click loaner from a linux build job (e.g. [1]) is 4.4.7. This is not what is used by the actual build task that generated gcno files (./mach build), which actually uses tooltool to fetch gcc 4.9.4. [2,3]

I can modify the PATH on the loaner to use gcc 4.9.4, but I'm still missing libraries to get grcov working.

./grcov: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./grcov)
./grcov: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by ./grcov)

[1] https://treeherder.mozilla.org/#/jobs?repo=try&[email protected]&selectedJob=92502848
[2] https://treeherder.mozilla.org/logviewer.html#?job_id=92502848&repo=try&lineNumber=1095
[3] https://treeherder.mozilla.org/logviewer.html#?job_id=92502848&repo=try&lineNumber=1005

Currently, we are ignoring gcno files which have no gcda file associated. This means files whose lines are never executed are missing from coverage reports.

Instead of handling them manually, we could use some package (e.g. clap).

Currently, we are panicking when a lcov/gcov file is malformed.
We should still terminate grcov, but we should print more information first (which file we are parsing when the error occurs and which line is causing the error).

The parser functions should not panic, they should return an error. The panic should happen in the caller.

Please update the install script to install grcov so that the ActiveData-ETL can use it. ETL machines are setup by machine, there will be no human to fill in the blanks for scripts that almost work.

At the moment, integration tests are disabled for Windows on CI.

Right now, the Rust code is calling the C++ code to generate gcov files (in the intermediate format since ). Then, the Rust code parses the gcov files.

We should make this more intelligent, making the Rust code call the C++ code to parse the gcno file and the C++ code call back into Rust to populate the result struct while parsing.

Example of how to use a Rust object from C++: http://jakegoulding.com/rust-ffi-omnibus/objects/.

This 1) avoids I/O (as we wouldn't need to generate the gcov files), 2) avoids parsing the same info twice (once from the gcno and once from the gcov).

This query
{
"from":"coverage",
"where":{"eq":{"_id":"tc.601123:60111463.55"}}
}
https://activedata.allizom.org/tools/query.html#query_id=w+8Nmnkj

Showing source for /home/worker/workspace/build/src/js/src/vm/AsyncFunction.cpp

Shows a orphan record with some lines uncovered:

"method":{
	"total_covered":0,
	"covered":[],
	"total_uncovered":7,
	"uncovered":[223,210,227,216,220,232,230],
	"percentage_covered":0
}

Is that possible? Sorry for the dumb question.

File-level coverage is not required for all records, but it is required when the source.method.name is missing:

This query is looking for any covered:
https://activedata.allizom.org/tools/query.html#query_id=fyuJ+KGM

This query is limiting itself to the records that require source.file-covered
https://activedata.allizom.org/tools/query.html#query_id=2OdYyxTs

And outputting it in the Coveralls format.

This will be needed for Rust.

At the moment some errors are handled like this:

    if !check_gcov() {
        println!("[ERROR]: gcov (bundled with GCC) >= 4.9 is required.\n");
    }

We should print the error to stderr and exit(1).

See https://bugzilla.mozilla.org/show_bug.cgi?id=1349640.

Platform: Linux x86-64
Compiler: Clang 5, GCC 7.2.0

This issue may be due to me misunderstanding how to use grcov.

After generating .gcda / .gcno files with cargo-cov, grcov panics when trying to generate coveralls formatted files with:

grcov /dir/with/gcda-gcno-files --llvm -t coveralls --token *** --commit-sha *** > out.info

Here is an example of the errors:

'Failed parsing execution count: function _ZN5alloc5slice8{{impl}}18into_vec<[u8; 20]>E called 0 returned 0% blocks executed 0%: ParseIntError { kind: InvalidDigit }'

Not sure if this is related to #25. Thanks in advance for any help.

example:
https://coveralls.io/builds/11009109/source?filename=gcc%2Finclude%2Fc%2B%2B%2F4.9.4%2Fbits%2Fstl_numeric.h
https://coveralls.io/builds/11009109/source?filename=gcc%2Flib%2Fgcc%2Fx86_64-unknown-linux-gnu%2F4.9.4%2Finclude%2Favxintrin.h

The function to test is in src/gcov.rs.

It would be nice to have ActiveData-ETL use this. We need a deploy script (Ubuntu) to help test it, and to know all the know all the dependencies.

It is currently used for tests. We have to udpate the tests code in order to remove the old format.

apt.llvm.org is unavailable very frequently (see also travis-ci/apt-source-safelist#156).

running 1 test
rm -f a.out a.exe main.gcno main.gcda default.profraw
g++ -fprofile-arcs -ftest-coverage main.c
12345689test test_integration ... FAILED

failures:

---- test_integration stdout ----

tests/switch
GCC
thread 'test_integration' panicked at 'COMPILER_VER env variable is not defined: NotPresent', /checkout/src/libcore/result.rs:906:4
note: Run with RUST_BACKTRACE=1 for a backtrace.

failures:
test_integration

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out

error: test failed, to rerun pass '--test test'

Does this require gcov? Please add an example script that can setup some Linux to run the tests.

let status = Command::new("gcov") 

https://github.com/marco-c/grcov/blob/master/src/main.rs#L101

On this line, https://github.com/marco-c/grcov/blob/a82a737ba7a114ac19d650b1ef0d3db199e1cc67/src/main.rs#L1266

We should be outputting FNH, not FNF. Unless something has changed in how this data is processed?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82702