1359394 - linked-files-map.json does not have the correct property names

Status: RESOLVED WORKSFORME

(Testing :: Code Coverage, defect)

Description

[Kyle Lahnakoski [:ekyle]]

`linked-files-map.json` is generated with the gcno file to map the files-as-compiled to files-from-repo. 

For example, the property names in `linked-files-map.json` do not match the filenames showing in the gcno file. The map is close: 54% of the 69,569 files in gcno can be suffix-matched to files in `linked-files-map.json`; the majority of the remaining gcno files have "/home/worker/workspace/build/src/" as a filename prefix; a tiny fraction of gcno filenames appear to have no match (see below)


GCDA: http://queue.taskcluster.net/v1/task/Oh8ca9DgRt6JYRLac72x0A/artifacts/public/test_info//code-coverage-gcda.zip
GCNO: http://queue.taskcluster.net/v1/task/D72W5ENYT0uBjJcn-OgZ4w/artifacts/public/build/target.code-coverage-gcno.zip

No match found (to be expected)
> Can not translate /usr/include/string.h
> Can not translate /tmp/ccov/ccov/gfx/angle/glslang_lex.cpp
> Can not translate /tmp/ccov/ccov/gfx/angle/Tokenizer.l
> Can not translate /tmp/ccov/ccov/gfx/harfbuzz/src/NONE
> Can not translate /tmp/ccov/ccov/gfx/harfbuzz/src/hb-ot-shape-complex-indic-machine.hh
> Can not translate /tmp/ccov/ccov/gfx/harfbuzz/src/hb-ot-shape-complex-indic-machine.rl
> Can not translate /tmp/ccov/ccov/gfx/harfbuzz/src/hb-ot-shape-complex-use-machine.hh
> Can not translate /tmp/ccov/ccov/gfx/harfbuzz/src/hb-ot-shape-complex-use-machine.rl
> Can not translate /tmp/ccov/ccov/gfx/harfbuzz/src/hb-ot-shape-complex-myanmar-machine.hh
> Can not translate /tmp/ccov/ccov/gfx/harfbuzz/src/hb-ot-shape-complex-myanmar-machine.rl
> Can not translate /usr/include/sys/epoll.h
> Can not translate /usr/include/bits/stdio.h
> Can not translate /usr/include/sys/stat.h
> Can not translate /usr/include/stdlib.h
> Can not translate /usr/include/pulse/def.h

Comment 1

[Marco Castelluccio [:marco]]

I think we can ignore the /usr/include files.
The other files are not present in the source tree, I haven't looked into what they are yet.

Comment 2

[Chris Manchester (limited bugmail, email directly)]

Is the title of this bug accurate? Are we actually having an issue with the generated mapping? 

It looks like we just have some paths that need to be relativized to the srcdir and a small number of files incorporated into the build that don't live in the srcdir.

Comment 3

[Kyle Lahnakoski [:ekyle]]

Yes, the generated mapping is all wrong. In an attempt to find out how it is wrong I found 2 major patterns:

1. 54% of the gcno files can be found, but their path is wrong
2. the remaining gcno files (42%) start with "/home/worker/workspace/build/src/"

That may help you debug what is wrong with the current map.

Comment 4

[Chris Manchester (limited bugmail, email directly)]

From the archive in comment 0 I can grep through dom/media/Unified_cpp_dom_media2.gcno and find many references to `/home/worker/workspace/build/src/obj-firefox/dist/include/mozilla/media/MediaUtils.h`. `linked-files-map.json` has an entry: 

"dist/include/mozilla/media/MediaUtils.h": "dom/media/systemservices/MediaUtils.h",

and I can find `dom/media/systemservices/MediaUtils.h` in my source tree. I can pick through several examples like this. Where does this go wrong? Can we see a list of the files that can't be found?

Comment 5

[Kyle Lahnakoski [:ekyle]]

It is good to see that the gcno file paths are matching a significant portion of the property names found in `linked-files-map.json`; when I looked, only the file name matched, and the paths are completely different.

I will get back to you with a list of gcno files that can not be matched at all.

Comment 6

[Marco Castelluccio [:marco]]

We're now using the linked-files-map.json directly in grcov on test machines, and it appears to be working fine.