Re: [gcov] No data gathered for child processes

[Scott Spivak <scott dot spivak at hp dot com>]

Didier 'Ptitjes' <ptitjes <at> free.fr> writes:

> 
> Hi Holger,
> 
> First thanks for your support.
> 
> Holger Blasum wrote:
> > Hello Didier,
> > 
> > On Sat, Sep 19, 2009 at 09:04:54PM +0200, Didier Ptitjes wrote:
> >> GTest forks the test process in order to test for asserting tests.
> >> Looking at the reports of lcov, it looks like there is absolutely no
> >> information gathered about the child processes.
> > ...
> >> I already have seen this question asked two times on gcc-help but none
> >> got a real answer:
> >> http://gcc.gnu.org/ml/gcc-help/2009-07/msg00334.html
> >> http://gcc.gnu.org/ml/gcc/2008-09/msg00490.html
> > 
> > Hmm, I have no quick idea how to fix your problem, but it might be 
> > helpful to understand where it occurs (then one can think of a
> > work-around): basically the gcov tools work in a way  
> > (1) that enabling -ftest-coverage will result in a different binary
> > than the binary without -ftest-coverage (1.4.1 in [1]), this gives you
> > *.gcno files
> > (2) when the instrumented binary it is run you have a data 
> > collection (1.4.2 in [1]) phase where the binary adds up 
> > counters in memory whenever passing through C sequence points 
> > and then you have a reporting phase where the memory data is dumped 
> > into *.gcda files.
> > (3) then there is a reporting phase (1.4.3 in [1]) where that *.gcda
> > and *.gcno files are converted into *.gcov files
> > 
> > The first thing to divide and conquer this would be to test and report 
> > * whether after the phase (1) all *.gcno files are built for both 
> > parent and child, 
> > * whether after the phase (2) all *.gcda files are built/modified 
> > for parent and child.
> 
> OK, I can confirm that I actually have *.gcno and *.gcda files for every 
> of my library .c files. (I tried to build them for test cases themselves 
> without any change).
> 
> You must note that the parent process and the child processes have the 
> exact same code. In fact, the parent process is just forked.
> 
> For an example of the forking code you can look at:
> 
http://git.gnome.org/cgit/libgee/tree/tests/testreadonlycollection.vala#n121
> 
> This is Vala code but it is just transformed into the following C code:
> 
> <code>
> if (g_test_trap_fork ((guint64) 0, G_TEST_TRAP_SILENCE_STDOUT |
>                                       G_TEST_TRAP_SILENCE_STDERR)) {
> 	g_assert (gee_collection_add (self->ro_collection, "two"));
> 	_g_object_unref0 (dummy);
> 	return;
> }
> g_test_trap_assert_failed ();
> g_assert (gee_collection_get_size (self->ro_collection) == 1);
> g_assert (gee_collection_contains (self->ro_collection, "one"));
> </code>
> 
> g_test_trap_fork uses fork() to fork the process.
> 
> Here is the g_test_trap_fork code if this can enlighten the problem:
> http://git.gnome.org/cgit/glib/tree/glib/gtestutils.c#n1582
> 
> I did not yet resolve the problem. I hope I will be able with your help.
> 
> Best regards, Didier.
> 
> 

FWIW, I ran into the same issue and, since I only really care whether an 
assert (and thus an abort()) is getting called during a given test, I came 
up with the following.  This approach doesn't require the forking of a child 
process as ASSERT_DEATH does, and so I was able to capture gcov data for the 
assert() statement.  Note that simply catching SIGABRT wasn't enough, 
because abort() still terminates the program after the signal handler 
returns (which I don't want), hence the setjmp and longjmp.

	static jmp_buf jmpBuf;

	void abortHandler(int param)
	{
		abortCalled = true;
		void (*prev_handler)(int);

		prev_handler = signal(SIGABRT, abortHandler);

		longjmp(jmpBuf, 1);
	}

	#define ASSERT_ABORT(statement) \
		abortCalled = false; \
		\
		signal(SIGABRT, abortHandler); \
		\
		if (!setjmp(jmpBuf)) \
		{ \
			statement; \
		} \
		\
		ASSERT_TRUE(abortCalled);

You can use it it like any other gtest macro:

		ASSERT_ABORT(myObject.doSomething());


--Scott