lcov stopped processing files and was stuck on particular ones. The problem was eventually narrowed down to the gcov call which, when enabling error and std output, showed that it got stuck while trying to create a '#path#to#current#header.h.gcov' file. Making sure that gcov is not called with the -a (or --all-blocks) flag enabled, allowed gcov to finish successfully. This does not apply to all .gcda files being analyzed, just some files which aren't drastically different from others which get processed fine when using the -a option. Chris
I noticed the same thing. The files available here: http://geometrica.saclay.inria.fr/team/Marc.Glisse/tmp/cov-bug/ send gcov-4.6 -a into an infinite loop while they crash gcov-4.7 -a (x86_64 debian testing system).
Created attachment 27465 [details] inputs.tar.gz I'm seeing very similar behavior running gcov on the attached files (inputs.tar.gz contains utility.gcda and utility.gcno). "gcov utility.gcda -b -c -a -p" hangs indefinitely (at least, it ran for 24 hours before I killed it) "gcov utility.gcda -b -c -p" returns in less than a second. This is using Fedora 16's build on an x86_64 system (gcc-4.6.3-2.fc16.x86_64 RPM).
Also confirmed with gcc 4.8.2 from Debian, as well as a nightly build of 4.9.0.
Just to add on, the issue also happen in gcc 4.4.7 from RHE 6.4. Anyone have any possible solution or workaround for it? If I disable the all-blocks option, it will lost the branch coverage data. Thanks!
Seems present in Ubuntu Saucy gcov version 4.8.1 Seems related to / Duplicate of ... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42945
I've just tried to reproduce it with current trunk, but I see an invalid read: ==12454== Invalid read of size 1 ==12454== at 0x4C304F2: strlen (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==12454== by 0x45833D: xstrdup (xstrdup.c:33) ==12454== by 0x403072: read_graph_file (gcov.c:1383) ==12454== by 0x403072: process_file (gcov.c:894) ==12454== by 0x403072: main (gcov.c:631) ==12454== Address 0x0 is not stack'd, malloc'd or (recently) free'd I guess it's somehow connected to fact the x.gcna and x.gcda files have a different layout. Can you please provide a source file which can be used to reproduce the problem?
No reply, closing as WORKSFORME.
Well, DOESNTWORKFORME. I observed it in gcc (Debian 4.9.2-10) 4.9.2 In fact IIRC I tried with GCC 6 and was able to reproduce - this is a pretty longstanding bug. I'll try to isolate a testcase for you, and re-check the behaviour on newer GCCs
Ok, reopening. I will resolve that having a test-case ;)
Created attachment 40326 [details] the soure file
Created attachment 40327 [details] teh gcov file
Created attachment 40328 [details] the .gcda file
I hope the files I just uploaded might be of use. lcov hangs indefinitely on this file. Command line: /usr/bin/lcov --rc lcov_branch_coverage=1 --directory . --capture --output-file unittests.info This was on gcc 4.9; can't confirm on gcc6 yet (haven't yet gotten it to compile :-( )
One remaining file is parameterregistry.cpp.gcno file.
No reply for quite some time. Please try GCC 5+ and reopen if can be reproduced.
I still see this problem in GCC 5.4.0. I am on ubuntu 16.04.12 with lcov version 1.12 and gcov version is 5.4.0. This is how it is compiling: ---------------------------- g++ -std=c++14 -DHAVE_CONFIG_H -I. -I.. -fprofile-arcs -ftest-coverage -DGITVERSION=\"2.2.4-2-gc134167-dirty\" -O2 -Wall -Wextra -pedantic -I/usr/local/include/ -L/usr/local/lib/ -MT Helper-abc.o -MD -MP -MF .deps/Helper-abc.Tpo -c -o Helper-abc.o `test -f 'abc.cpp' || echo './'`abc.cpp With branch coverage enabled the lcov call is freezing lcov --rc lcov_branch_coverage=1 --directory $PWD --capture --output-file tests_coverage.info Only the .gcda file generated for abc.cpp is freezing rest it is ok. I am literally desparate for some workaround. It's been a long standing ticket not seen any workaround or fix.
Please update to at least GCC 8.4.0, it should be fixed there. Older releases are not supported right now.
Thank you @martin. I am not sure whether ubuntu 16.04 is compatible with gcc 8.4.0. Our app. is currently built for ubuntu 16.04 and I don't know what breaking changes it could bring if we upgrade gcc. Do you know any workaround other than disabling the whole branch coverage?
(In reply to Prasannanjaneyulu from comment #18) > Thank you @martin. I am not sure whether ubuntu 16.04 is compatible with gcc > 8.4.0. Our app. is currently built for ubuntu 16.04 and I don't know what > breaking changes it could bring if we upgrade gcc. I strongly recommend to update to a supported GCC. Note that in the meantime we've fixed many issues that can theoretically affect your application. > > Do you know any workaround other than disabling the whole branch coverage? No.