Archive for category programming

Use gcov and lcov to know your test coverage

As we all know, unit test has been a crucial part of software development. I feel I was walking on ice if I was coding without writing tests. But even if we have unit tests, things may still go wrong if the tests have bad coverage. Fortunately, there are many tools today to help us analyze our code and give us every detail of the quality of our unit tests. GNU gcov is such a tool for code compiled with GCC.

gcov is very easy to use. If you’re developing a C/C++ project, all you have to do is to compile your project with “-g -O0 –coverage”. “–coverage” is a synonym for-fprofile-arcs, -ftest-coverage(compiling) and-lgcov(linking). This tells the compiler to generate additional information and code needed by gcov.

OK, let’s run our tests. GCC will generate a bunch of files(profiles) that will be used later. These files know how your tests was executed and record many information such as arc transition counts and some summary information. Now we’re ready to view our test coverage now with gcov.  But gcov doesn’t give us a report that is easy to read and it’s not convenient. Here comes the tool called “LCOV”.

LCOV test coverage report for libbash

Read the rest of this entry »

, , ,


Handling unit test with C++ visibility=hidden

Recently I started working on the libbash project. I will write several articles talking about it in future. Now I’d just like to write something about the problem we encountered during development.

Our project will be a shared library. The C++ visibility support could improve the overall performance. Put simply, it hides most of the ELF symbols which would have previously (and unnecessarily) been public. Well it’s good for the library, it’s not good for unit tests(namely gtest) because they need to know the symbols.

Of course we don’t want  the unit tests to be part of our library. So we need to find some way to let the unit test know the symbols and separate them into different automake targets. Our first solution is to use hidden visibility for the library and create an internal target with default visibility for the unit test. However, that requires compiling the source code twice. Finally Petteri Räty come with a solution (He is too busy to write a post :P):

libcppbash_la_SOURCES = blah
libcppbash_la_CXXFLAGS = $(AM_CXXFLAGS) -fvisibility=hidden -fvisibility-inlines-hidden

cppunittests_SOURCES = blah
cppunittests_LDADD = $(GTEST_LIBS)
cppunittests_LDFLAGS = -static

Here’s his explanation:
libtool by default builds both a shared and a static library for our project. This is why you see it building things twice (with PIC and without). Giving -static to libtool is just telling it to use the static version. Using the static version means everything ends up in the unit test binaries.

, , ,


Valgrind – Your Memory Assistant

Valgrind is a programmer tool that allows to track memory related errors in C and C++ programs. This tool helped me greatly when I was checking out potential memory leaks.

As we all know, it’s really difficult to ensure that your program don’t have any memory leak at all. A good coding practice always helps, but usually it’s infeasible to find all bugs by our eyes. So we need a tool to automatically find these bugs. Valgrind is such a tool and is very easy to use. Before using it, you could compile your program with -g to include debugging information and -O0 to disable compiler’s optimization. Doing these will let memcheck’s error messages include exact line numbers.

Then you just use:

valgrind --leak-check=yes myprog arg1 arg2

The result will be displayed and it will tell you where the potential memory leaks are. You could fix the bugs according to it. There are more options and you could check them out on man page.

For gnome applications building with glib, things are a little different since glib has it’s own memory management library. Here are some tips I stolen from  Gnome community:

G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck --leak-check=full --leak-resolution=high --num-callers=20 --log-file=vgdump your-program

and you could also use it for libtool program. Check this out to see how to do this.



Debug libtool program with gdb

libtool program is a shell script that can’t work with gdb.Here is an example:
$ ls -l check_ifnet
-rwxr-xr-x 1 gentoo gentoo 4269 Aug 18 20:46 check_ifnet
$file check_ifnet
check_ifnet: POSIX shell script text executable

For libtool programs, the shared libraries are put into .lib directory and that script sets up the running environment (See more information I find that many people manually copy the shared libraries for debugging purpose. That’s not quite convenient.

I have two ways to test these kind of programs with gdb:

  1. edit the program and change this line “exec “$progdir/$program” ${1+”$@”}” to “gdb “$progdir/$program” ${1+”$@”}”. Then run the program.
  2. libtool –mode=execute gdb your_program (This one is better)

, , ,