Hugo,
On 1/25/22 13:13, Hugo Lefeuvre wrote:
We are wondering if this is caused by our measurement approach (gcov,
passing -fprofile-arcs -ftest-coverage in the CFLAGS and -lgcov to
LDFLAGS), or if this is known to the HAProxy community. We reproduced these
measurements across several recent versions of HAProxy, dev, 2.5, and 2.4.
Yes, I believe your measurement is flawed. I tried to reproduce the
results myself and was confused by seeing uri_normalizer.c not being
covered when it should be completely covered, except for error paths by
this test:
https://github.com/haproxy/haproxy/blob/master/reg-tests/http-rules/normalize_uri.vtc
Cleaning out all the coverage files and just running that specific test
using:
vtest -k -t 1 reg-tests/http-rules/normalize_uri.vtc
did not generate any new coverage files!
Digging into it, this appears to be caused by VTest terminating HAProxy
with a SIGINT, but HAProxy not binding an explicit SIGINT handler. In
this case it appears that no coverage files are generated.
To test this further I applied the following patch to exit as cleanly as
possible on SIGINT:
diff --git i/src/haproxy.c w/src/haproxy.c
index f10af5eae..38614a0cb 100644
--- i/src/haproxy.c
+++ w/src/haproxy.c
@@ -790,6 +790,13 @@ void mworker_reload()
mworker_reexec();
}
+void die_on_sigint(struct sig_handler *sh)
+{
+ int sig = sh->arg;
+
+ deinit_and_exit(0);
+}
+
static void mworker_loop()
{
@@ -3424,6 +3431,10 @@ int main(int argc, char **argv)
/* when multithreading we need to let only the thread 0 handle the
signals */
haproxy_unblock_signals();
+
+ signal_register_fct(SIGINT, die_on_sigint, SIGINT);
+
+
/* Finally, start the poll loop for the first thread */
run_thread_poll_loop(&ha_thread_info[0]);
and then reran the test suite. A few tests failed (this might be because
my patch inserted the deinit in the wrong location), but the coverage
looks much better:
I'm getting ~44% line and ~55% function coverage when compiling with
$ make -j4 all TARGET=linux-glibc V=1
uri_normalizer.c gets to 100% function and 85.4% line coverage. The
non-covered lines are the error handling (incidentally the call to
'my_unreachable()' also is marked as uncovered - which is expected).
Best regards
Tim Düsterhus
