Core dump and gcov coverage report

Question

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?

score 4 · Answer 1 · answered Nov 16 '11 at 06:50

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'

score 2 · Answer 2 · answered Apr 17 '11 at 20:17

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?

score 0 · Answer 3 · answered Apr 17 '11 at 21:18

0

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

answered Apr 17 '11 at 21:18

sehe

374,641
47
450
633

score 0 · Answer 4 · answered Apr 18 '11 at 19:03

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.

Core dump and gcov coverage report

4 Answers4