Отчет о покрытии core dump и gcov

Я провожу стресс-тестирование многопоточной программы, а также собираю покрытие. Насколько мне известно, gcov не создает файлы .gcda, когда программа завершается с помощью _exit () или некоторых сигналов, таких как SIGABRT, SIGSEGV и т. Д.

Когда программа дает сбой, основной файл генерируется сигналом, а данные покрытия gcov не генерируются. Очевидно, я мог обработать сигнал и сгенерировать данные о покрытии, но в этом случае я не смог сгенерировать файл дампа ядра. Но я хотел бы создать как дамп ядра, так и файл данных gcov, чтобы выяснить причину сбоя.

Мой вопрос в том, есть ли способ сгенерировать дамп ядра без сигналов или есть ли способ сгенерировать файл данных покрытия gcov, когда программа внезапно завершается?


c c++ linux code-coverage gcov
person Doe    schedule 17.04.2011    source источник

Ответы (4)


arrow_upward
4
arrow_downward

Если вам нужно автоматизировать регрессионное тестирование покрытия кода. Попробуй это:

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

Внутри main.c вашей программы поместите:

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

Затем заново соберите свою программу и запустите:

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

таким образом он все равно должен генерировать файлы .gcda

$ gcov hello
File 'hello.c'
Lines executed:100.00% of 14
hello.c:creating 'hello.c.gcov'
person gigasai    schedule 16.11.2011

arrow_upward
2
arrow_downward

Что вам нужно сделать, так это исправить ошибки, прежде чем вы начнете измерять покрытие тестами.

Если ваша программа не проходит другие тесты, информация о покрытии в любом случае не имеет смысла. Сбой явно является какой-то ошибкой, поэтому вам нужно это исправить.

Исправьте ошибки, тогда вы сможете узнать, насколько эффективно тестируется ваша (исправная) программа.

Возможно, поможет, если вы напишете автоматизированный тест для воспроизведения сбоя, чтобы убедиться, что он впоследствии не регрессирует?

person MarkR    schedule 17.04.2011

arrow_upward
0
arrow_downward

Взгляните на valgrind (или почтовый индекс, чтобы мы могли помочь)

person sehe    schedule 17.04.2011

arrow_upward
0
arrow_downward

Я сторонник использования только покрытия кода при выполнении тестов - детерминированных тестов. Возможно (и желательно) получить 100% покрытие строки с помощью модульных тестов.

Также с тестами, если вы действительно получаете какой-либо сбой, было бы легко отключить тест в системе управления версиями, пока он не будет исправлен.

person quamrana    schedule 18.04.2011