views:

228

answers:

3

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 et 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 ?

A: 

Try TAP (Test Anything Protocol) .. its a lot easier to implement, ship and debunk. Its also very easy to make it valgrind aware and tends to play nicer with gdb.

An example of its use (though I have modified it a bit) is here.

Tim Post
+2  A: 

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.

Jonathan Leffler
+1  A: 

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