Re: make coverage

[Bruno Haible]

Tim Rühsen wrote:
> $ ./gnulib-tool --create-testdir --dir=../testdir1
> $ cd ../testdir
> $ ./configure CFLAGS="-g -coverage"
> $ make clean && make coverage

I did
$ ./gnulib-tool --create-testdir --dir=../testdir-all
$ cd ../testdir-all
$ ./configure CFLAGS="-ggdb --coverage"
$ make coverage

and these tests pass:

PASS: test-fprintf-posix.sh
PASS: test-fprintf-posix2.sh
PASS: test-fprintf-posix3.sh
...
PASS: test-printf-posix.sh
PASS: test-printf-posix2.sh

This is on Ubuntu 16.04, with
$ ulimit -s
8192

> 7 failures are due to using system libunistring (Version
> 0.9.6+really0.9.3-0.1) and can be avoided by ./configure
> --with-included-libunistring.

Ugh. Looks like your distributor plays weird games with the libunistring shared
library version.
https://launchpad.net/debian/+source/libunistring/0.9.6+really0.9.3-0.1
This happens if a distributor gives a higher .so version to a shared library
than it really is.

> The other 2 are
> FAIL: test-printf-posix2.sh
> FAIL: test-fprintf-posix2.sh
> 
> $ cat gltests/test-printf-posix2.sh.log
> Segmentation fault
> FAIL test-printf-posix2.sh (exit status: 1)

I get
$ cat gltests/test-printf-posix2.sh.log
PASS test-printf-posix2.sh (exit status: 0)

> $ valgrind gltests/./test-printf-posix2 0
> ...
> ==2265== Cannot map memory to grow the stack for thread #1 to 0xffeffb000
> ==2265==
> ==2265== Process terminating with default action of signal 11 (SIGSEGV)
> ==2265==  Access not within mapped region at address 0xFFEFFB43C
> ==2265== Cannot map memory to grow the stack for thread #1 to 0xffeffb000
> ==2265==    at 0x10A296: gcov_do_dump (in 
> /usr/oms/src/testdir1/gltests/test-printf-posix2)
> ...
> Segmentation fault

I get the same thing under valgrind.
$ valgrind gltests/test-printf-posix2 0 
==24958== Memcheck, a memory error detector
==24958== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==24958== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==24958== Command: gltests/test-printf-posix2 0
==24958== 
==24958== Cannot map memory to grow the stack for thread #1 to 0xffeffa000
==24958== 
==24958== Process terminating with default action of signal 11 (SIGSEGV)
==24958==  Access not within mapped region at address 0xFFEFFAFF4
==24958== Cannot map memory to grow the stack for thread #1 to 0xffeffa000
==24958==    at 0x4020F6: gcov_do_dump (in 
/media/develdata/devel/GNULIB/testdir-all/gltests/test-printf-posix2)
==24958==  If you believe this happened as a result of a stack
==24958==  overflow in your program's main thread (unlikely but
==24958==  possible), you can try to increase the size of the
==24958==  main thread stack using the --main-stacksize= flag.
==24958==  The main thread stack size used in this run was 5000000.
==24958== Cannot map memory to grow the stack for thread #1 to 0xffeffa000
==24958== 
==24958== Process terminating with default action of signal 11 (SIGSEGV)
==24958==  Access not within mapped region at address 0xFFEFFAF88
==24958== Cannot map memory to grow the stack for thread #1 to 0xffeffa000
==24958==    at 0x4A28680: _vgnU_freeres (in 
/usr/lib/valgrind/vgpreload_core-amd64-linux.so)
==24958==  If you believe this happened as a result of a stack
==24958==  overflow in your program's main thread (unlikely but
==24958==  possible), you can try to increase the size of the
==24958==  main thread stack using the --main-stacksize= flag.
==24958==  The main thread stack size used in this run was 5000000.
==24958== 
==24958== HEAP SUMMARY:
==24958==     in use at exit: 0 bytes in 0 blocks
==24958==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==24958== 
==24958== All heap blocks were freed -- no leaks are possible
==24958== 
==24958== For counts of detected and suppressed errors, rerun with: -v
==24958== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Speicherzugriffsfehler (Speicherabzug geschrieben)

but I don't want to debug valgrind here.

What do you get if you change the value 5000000 in tests/test-fprintf-posix2.c
to a larger or smaller value?

Bruno