SimonKagstrom / kcov

Code coverage tool for compiled programs, Python and Bash which uses debugging information to collect and report data without special compilation options
http://simonkagstrom.github.io/kcov/
GNU General Public License v2.0
709 stars 109 forks source link

kcov segfaults when the excutable is kcov #425

Closed perillo closed 5 months ago

perillo commented 5 months ago

kcov version

kcov 42 (but I can reproduce it with current master)

Example

> kcov cover kcov -h
kcov: Process exited with signal 11 (SIGSEGV) at 0x7ffff7759710

When using a development version of kcov as the executable, the coverage file for src/configure.cc reports a suspected line (in yellow):

1692 / 6        setKey("kcov-binary-path", get_real_path(argv[0])); 861

After this line, the remaining code in the parse function is not covered.

SimonKagstrom commented 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?

perillo commented 5 months ago

Can you test with a build from master?

SimonKagstrom commented 5 months ago

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
perillo commented 5 months ago

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.

SimonKagstrom commented 5 months ago

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.

perillo commented 5 months ago

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...]

...
SimonKagstrom commented 5 months ago

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.

arzedlab commented 4 months ago

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

SimonKagstrom commented 4 months ago

@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.