8

I'm trying to use check unit testing framework for my C application. But I can't use the debugger (gdb) with it because of two points:

  • first, check use some complex macros (START_TEST and END_TEST) and the debugger has trouble to put a breakpoint in my code between these two macros (in fact, I can put a software breakpoint but It is never seen by gdb)

  • second, check define some sort of exceptions by redefining behavior of interruption. Hence, when I try to put a hardware breakpoint, the test failed and exit because check consider the hardware breakpoint as a failure of my test.

Does anyone has already met this problem and has a solution?

sth
  • 222,467
  • 53
  • 283
  • 367
Kartoch
  • 7,610
  • 9
  • 40
  • 68

4 Answers4

12

Look at the no-fork mode:

Check normally forks to create a separate address space. This allows a signal or early exit to be caught and reported, rather than taking down the entire test program, and is normally very useful. However, when you are trying to debug why the segmentation fault or other program error occurred, forking makes it difficult to use debugging tools.

Tom Lord
  • 27,404
  • 4
  • 50
  • 77
Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
7

Actually, you CAN use fork-mode too.

gdb has two interesting options related to fork behaviour:
- detach-on-fork (set this to false)
- follow-on-fork (either parent or child; I always take child)

This will make gdb follow the child process. When the child process has ended, you have to manually switch back to the parent process by using the inferior command.

Paul Praet
  • 1,367
  • 14
  • 25
3

I read this and he suggests a very simple solution:

gdb > set environment CK_FORK=no

that worked for me. I could then set a breakpoint in functions the test cases call (that is, the functions under test), and it broke at the right place.

Stephen Rauch
  • 47,830
  • 31
  • 106
  • 135
mjdsmith
  • 991
  • 1
  • 6
  • 6
0

Try TAP (Test Anything Protocol) … it's a lot easier to implement, ship and debug. It's also very easy to make it valgrind-aware and tends to play nicer with gdb.

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
Tim Post
  • 33,371
  • 15
  • 110
  • 174
  • As of 2016-09-23, the TAP link to [http://ccan.ozlabs.org/info/tap.html](http://ccan.ozlabs.org/info/tap.html) is 404. The primary web site, ozlabs.org, is still running, but I can't locate the TAP information. Wikipedia has an entry for the [Test Anything Protocol](https://en.wikipedia.org/wiki/Test_Anything_Protocol); there's a web site for the [Test Anything Protocol](https://testanything.org/) with implementations in C, C++, Java, JavaScript, Python, Perl, etc. – Jonathan Leffler Sep 23 '16 at 15:33