Incorrect #line directives cause Perl warnings
cesaro opened this issue · comments
Having incorrect #line
directives on the input C files causes geninfo --filter trivial
to call the Perl function containsTrivialFunction
in a way where variable $src
on lcovutil.pm:5372 is undefined. Probably lcov
should gracefully handle these wrong inputs.
Example:
$ cat -n a.c
1 // this file has 1 line
$ cat -n b.c
1 #line 1 "a.c"
2
3 int fun() { return 1; }
Note that the directive #line 1 "a.c"
wrongly indicates that fun
was defined on a.c
line 2, when in fact a.c
has only 1 line. Now run:
$ gcc -c --coverage b.c
$ geninfo . -i --filter trivial,range -o out
Found gcov version: 12.3.0
Using intermediate gcov format
geninfo: WARNING: (usage) branch filter enabled but branch coverage not enabled
(use "geninfo --ignore-errors usage,usage ..." to suppress this warning)
Recording 'internal' directories:
/path/to/dir
Writing temporary data to /tmp/geninfo_datwbiG
Scanning . for .gcno files ...
Found 1 graph files in .
using: chunkSize: 1, nchunks:1, intervalLength:0
Finished processing 1 GCNO file
Apply filtering..
geninfo: WARNING: Use of uninitialized value $src in scalar chomp
geninfo: WARNING: Use of uninitialized value $src in substitution (s///)
geninfo: WARNING: Use of uninitialized value $src in substitution (s///)
geninfo: WARNING: Use of uninitialized value $src in concatenation (.) or string
geninfo: WARNING: Use of uninitialized value $src in scalar chomp
geninfo: WARNING: Use of uninitialized value $src in substitution (s///)
geninfo: WARNING: Use of uninitialized value $src in substitution (s///)
geninfo: WARNING: Use of uninitialized value $src in concatenation (.) or string
Finished filter file processing
Finished .info-file creation
Summary coverage rate:
source files: 1
lines.......: no data found
functions...: no data found
Filter suppressions 'range':
3 instances
2 coverpoints
Message summary:
1 warning message:
usage: 1
This situation can be triggered by buggy versions of flex
:
$ cat -n lex.l
1 %%
2 %%
3 int fun() { return 1; }
$ flex --version
flex 2.5.37
$ flex -o lex.c lex.l
$ cat -n lex.c | tail -n 5
1716 #line 2 "lex.l"
1717
1718
1719 int fun() { return 1; }
1720
Note that lex.c
suggests that fun
is defined in line 4 of lex.l
, when in reality it was defined in line 3. This is was a flex
bug that is fixed as of (at least) version 2.6.2 of flex
, but which IMHO, should not trigger further noise in lcov
.
Closing this issue as I believe it is fixed in the commit, above.
If there is still a problem, please reopen this issue or file a new one.
Please include a testcase and/or a recipe to reproduce the issue.
Henry