CODEWITHSUNDEEP
c++clinuxcode-coveragegcov
Doe
Doe

Reputation: 151

Core dump and gcov coverage report

I'm doing stress testing on multi-threaded program and collecting coverage as well. As far as I know, gcov doesn't produce .gcda files when program is terminated by _exit() or some signals such as SIGABRT, SIGSEGV and so on.

When the program crashes, core file is generated by signal and gcov coverage data isn't generated. Obviously I could handle the signal and generate the coverage data but in this case I couldn't generate core dump file. But I'd like to generate both core dump and gcov data file to figure out the cause of the crash.

My question is that is there any way to generate core dump without signals or is there any way to generate gcov coverage data file when the program abruptly terminates?

Upvotes: 3

Views: 3241

Answers (4)

gigasai
gigasai

Reputation: 584

If you have need to do regression testing of code coverage automatedly. Try this:

https://www.osadl.org/Dumping-gcov-data-at-runtime-simple-ex.online-coverage-analysis.0.html

Inside your program's "main.c" put:

static unsigned long long i = 0;
void __gcov_flush(void); /* check in gcc sources gcc/gcov-io.h for the prototype */

void my_handler(int signum)
{
  printf("received signal\n");
  printf("%llu\n", i);
  __gcov_flush(); /* dump coverage data on receiving SIGUSR1 */
}

int main(int argc, char **argv)
{
  struct sigaction new_action, old_action;
  int n;

  /* setup signal hander */
  new_action.sa_handler = my_handler;
  sigemptyset(&new_action.sa_mask);
  new_action.sa_flags = 0;

  sigaction(SIGUSR1, NULL, &old_action);
  if (old_action.sa_handler != SIG_IGN)
    sigaction (SIGUSR1, &new_action, NULL);
  //blah......

Then re-build your program and run:

$ ./hello &
$ killall -USR1 hello
received signal
2514147346

this way it should still generate .gcda files

$ gcov hello
File 'hello.c'
Lines executed:100.00% of 14
hello.c:creating 'hello.c.gcov'

Upvotes: 5

quamrana
quamrana

Reputation: 39354

I am a big advocate of only using code coverage whilst running tests - deterministic tests. Its possible (and desirable) to get 100% line coverage with unit tests.

Also with tests, if you do get a crash of some sort it would be easy to disable the test in source control until its fixed.

Upvotes: 0

sehe
sehe

Reputation: 392979

Have a look at valgrind (or post code so we can help)

Upvotes: -1

MarkR
MarkR

Reputation: 63538

What you need to do is, fix the bugs before you start measuring test coverage.

If your program is failing other tests, coverage information is meaningless anyway. Crashing is clearly a failure of some kind, so you need to fix this.

Fix the bugs, then you can find out how effectively your (non-faulty) program is being tested.

Perhaps it will help if you write an automated test to reproduce the crash, to ensure it doesn't subsequently regress?

Upvotes: 2

Related Questions