Основной дамп и отчет о покрытии gcov - PullRequest
Новая
       26

Основной дамп и отчет о покрытии gcov

3 голосов
/ 18 апреля 2011

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

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

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

Ответы [ 4 ]

4 голосов
/ 16 ноября 2011

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

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'
2 голосов
/ 18 апреля 2011

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

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

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

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

0 голосов
/ 18 апреля 2011

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

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

0 голосов
/ 18 апреля 2011

Посмотрите valgrind (или почтовый индекс, чтобы мы могли помочь)

...