Closed perillo closed 5 months ago
I actually can't reproduce this either on Linux (albeit with a slightly older kcov) or on MacOs.
However, if there's a memory overwrite issue, I guess I might just miss it. Maybe something in get_real_path?
Can you test with a build from master?
Sorry, wasn't clear: On MacOS, I tested with the latest master. Linux was slightly older.
Could it be that you have something in your path that affects it? E.g., for me it's
$ which kcov
/Users/ska/projects/build/kcov/src//kcov
I used kcov
from /usr/bin/kcov
, installed from Arch Linux official package.
> kcov /tmp/cover kcov
kcov: Process exited with signal 11 (SIGSEGV) at 0x7ffff7959710
________________________________________________________
Executed in 1.25 secs fish external
usr time 668.68 millis 484.00 micros 668.20 millis
sys time 518.00 millis 124.00 micros 517.88 millis
The address seems to be always the same. For the timing, note that I'm using an old PC.
You could try to run with --debug=31
to see if there's any particular address it doesn't like, and also with --verify
.
Although in those cases, the covered process is typically the one that crashes, not kcov itself.
The problem is the error message; it always prints kcov
instead of using argv[0]
so it is not clear what process is crashing in this context.
Here is the output using --verify
(from commit 5ae73ae):
> build/bin/kcov --verify cover kcov
kcov: warning: kcov: WARNING: kcov has been built without libbfd-dev (or
kcov: binutils-dev), so the --verify option will not do anything.
kcov: Process exited with signal 11 (SIGSEGV) at 0x7ffff7759710
> kcov --verify cover build/bin/kcov
kcov: 21 invalid breakpoints skipped in /usr/lib/libstdc++.so.6
Usage: kcov [OPTIONS] out-dir in-file [args...]
...
OK, so I believe the issue is then with the compiled code (maybe in libstdc++, by the looks of it). If the DWARF information is incorrect, e.g., in the middle of an instruction, kcov will set a breakpoint that actually destroys the code that runs (since the encoding now means something else).
This is basically only an issue on x86, which has variable length instructions, and the --verify
option disassembles the code and discards the faulty DWARF entries.
You can probably also get around this by e.g., --include-pattern=kcov
, or --skip-solibs
.
Anyway, I think I'll close this, since it's not really a bug in kcov, but in the toolchain. Also, covering kcov in general is only possible when using python or bash scripts, since ptrace is not recursive.
Good, day, the same error
kcov: Process exited with signal 4 (SIGILL) at 0x7ffff7b97057
kcov: Illegal instructions are sometimes caused by some GCC versions
kcov: miscompiling C++ headers. If the problem is persistent, try running
kcov: with --verify. For more information, see
kcov: http://github.com/SimonKagstrom/kcov/issues/18
kcov: WARNING: kcov has been built without libbfd-dev (or
kcov: binutils-dev), so the --verify option will not do anything.
binutils-dev installed built right, I even tried to change Cmake but error happening each time.
Linux: Linux 20.04.1 Ubuntu x86_64
@arzedlab, how did you build it? When you run cmake, it should printout if it finds libbfd so that it can disassemble the sources.
Anyway, I think that is really issue #18 , but there seems like the build didn't find libbfd which causes --verify
to do nothing.
kcov version
kcov 42 (but I can reproduce it with current master)
Example
When using a development version of
kcov
as the executable, the coverage file forsrc/configure.cc
reports a suspected line (in yellow):After this line, the remaining code in the
parse
function is not covered.