I created a small test I will attach to this bug report that shows that executables created with -fprofile-arcs -ftest-coverage crash in gcov_exit () if they dynamically load functions from libraries. I tested with gcc 3.4.1 and 4.0-20050213. Both show the same problem. Here's the gdb stack trace for both compilers: Program terminated with signal 11, Segmentation fault. #0 gcov_exit () at ../../gcc-3.4.1/gcc/libgcov.c:139 139 if (!((1 << t_ix) & gi_ptr->ctr_mask)) (gdb) where #0 gcov_exit () at ../../gcc-3.4.1/gcc/libgcov.c:139 #1 0x4018b820 in exit () from /lib/tls/libc.so.6 #2 0x40176b1a in __libc_start_main () from /lib/tls/libc.so.6 #3 0x080491b1 in _start () at ../sysdeps/i386/elf/start.S:119 Program terminated with signal 11, Segmentation fault. #0 gcov_exit () at ../../gcc-4.0-20050213/gcc/libgcov.c:139 139 if (!((1 << t_ix) & gi_ptr->ctr_mask)) ((gdb) where #0 gcov_exit () at ../../gcc-4.0-20050213/gcc/libgcov.c:139 #1 0x4018b820 in exit () from /lib/tls/libc.so.6 #2 0x40176b1a in __libc_start_main () from /lib/tls/libc.so.6 #3 0x08049031 in _start () at ../sysdeps/i386/elf/start.S:119 The test uses SCons as a build tool. But I give the build arguments here for the 3.4.1 compiler: /opt2/GNU/bin/g++-3.4.1 -O0 -g -D_REENTRANT -W -Wall -Wpointer-arith -Wno-uninitialized -Woverloaded-virtual -Wcast-align -Wwrite-strings -Wcomments -march=pentiumpro -DCOVERAGE -fprofile-arcs -ftest-coverage -Isrc -c -o src/prog/.build/posix/coverage/main.o src/prog/main.cpp /opt2/GNU/bin/g++-3.4.1 -g -Wl,-E -o bin/posix/coverage/prog src/prog/.build/posix/coverage/main.o -Llib/posix/coverage -lstdc++ -lpthread -lrt -ldl -lgcov /opt2/GNU/bin/g++-3.4.1 -O0 -g -D_REENTRANT -W -Wall -Wpointer-arith -Wno-uninitialized -Woverloaded-virtual -Wcast-align -Wwrite-strings -Wcomments -march=pentiumpro -DCOVERAGE -fprofile-arcs -ftest-coverage -fPIC -Isrc -c -o src/calc/.build/posix/coverage/calc.os src/calc/calc.cpp /opt2/GNU/bin/g++-3.4.1 -g -Wl,-E -Wl,-soname=libcalc.so.1.0 -shared -o lib/posix/coverage/libcalc.so src/calc/.build/posix/coverage/calc.os -Llib/posix/coverage -lstdc++ -lpthread -lrt -ldl -lgcov Lothar
Created attachment 8201 [details] test case to reproduce the segfault This is a project of a small test case that reproduces the segmentation fault. It's build tool is SCons. If you don not want to use SCons, here's the command line(s) executed: /opt2/GNU/bin/g++-3.4.1 -O0 -g -D_REENTRANT -W -Wall -Wpointer-arith -Wno-uninitialized -Woverloaded-virtual -Wcast-align -Wwrite-strings -Wcomments -march=pentiumpro -DCOVERAGE -fprofile-arcs -ftest-coverage -Isrc -c -o src/prog/.build/posix/coverage/main.o src/prog/main.cpp /opt2/GNU/bin/g++-3.4.1 -g -Wl,-E -o bin/posix/coverage/prog src/prog/.build/posix/coverage/main.o -Llib/posix/coverage -lstdc++ -lpthread -lrt -ldl -lgcov /opt2/GNU/bin/g++-3.4.1 -O0 -g -D_REENTRANT -W -Wall -Wpointer-arith -Wno-uninitialized -Woverloaded-virtual -Wcast-align -Wwrite-strings -Wcomments -march=pentiumpro -DCOVERAGE -fprofile-arcs -ftest-coverage -fPIC -Isrc -c -o src/calc/.build/posix/coverage/calc.os src/calc/calc.cpp /opt2/GNU/bin/g++-3.4.1 -g -Wl,-E -Wl,-soname=libcalc.so.1.0 -shared -o lib/posix/coverage/libcalc.so src/calc/.build/posix/coverage/calc.os -Llib/posix/coverage -lstdc++ -lpthread -lrt -ldl -lgcov
Hmm, this looks like we don't deal with dlclose correctly. Honza could you comment on this if there is a way to deal with dlclose?
Changed severity to critical, as the compiler produces code that crashes when executing a coverage enabled executable.
(In reply to comment #3) > Changed severity to critical, as the compiler produces code that crashes when > executing a coverage enabled executable. Well considering this is werid case of using arc profiling with shared libraries it is not critical and has a workaround, not unloading the shared library.
A bug that creates wrong code is critical for me. As our application depends on dynamically loading libraries, there's simply NO workaround for this bug. We can NOT execute any executables built with code coverage with either 3.4.1 or 4.0.0. I am really worried that 4.0.0 may get released without fully working code coverage. P.S. I tried to mark the bug as "waiting for feedback", but it said I do not have the permissions. Am I not the owner of the bug? If possible mark the bug as "waiting for feedback" and the Target Milestone to 4.0.0. Thanks
I am experiencing the same exact problem with our project http://openhpi.sf.net. gcov_exit() segfaults when the project is compiled with -fprofile-arcs and -ftest-coverage using gcc-3.4.x, and unit tests are ran against the compiled library. This is a real and preoccupying problem for us on gcc-3.4.x.
Created attachment 8373 [details] smaller C test case The test case provided by the submitter runs successfully if the executable is built without -Wl,-E, as does the smaller C test case. I understand that the original program needs to use that option, so I'll continue looking into this to find a fix and perhaps a workaround. The new test case fails with a plain "make" invocation for mainline, 4.0-branch, and 3.4-branch, and passes for all of those with "make EXP=".
The submitter's testcase works if function __gcov_init in libgcov.c is declared hidden. Probably all of the __gcov* symbols ought to be hidden; I'll work on a patch to hide that symbol and others that seem appropriate. Possible workaround: The linker's -E option exports all global symbols from the executable to the dynamic symbol table. A subset of global symbols can be exported by using -E along with --version-script to list symbols to export. Depending on how many symbols a shared object needs to access from a shared object, this might be a reasonable workaround. I consulted an expert, and unfortunatly there doesn't seem to be a way to say "export all symbols except this small list".
This is a regression from GCC 3.3. I'm working on a patch.
Created attachment 8392 [details] small C++ test case for which executable must export a symbol There's no support in the GCC testsuite for a test like this; if there were, this is what it would do.
Nathan approved the mainline patch but I haven't yet checked it in because while testing backports I noticed more gcov symbols that were not hidden, and because the original submitter tried a 3.4 version of the patch and had new problems with it. He also has other problems that are not addressed by the patch, in a project that uses C++, shared libraries via dlopen/dlclose, threads, and TLS. We're trying to come up with test cases for the other problems.
Subject: Bug 19985 CVSROOT: /cvs/gcc Module name: gcc Changes by: janis@gcc.gnu.org 2005-05-02 18:02:48 Modified files: gcc : gcov-io.h ChangeLog Log message: PR 19985 * gcov-io.h: Declare gcov external functions hidden. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gcov-io.h.diff?cvsroot=gcc&r1=1.56&r2=1.57 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8561&r2=2.8562
Subject: Bug 19985 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-4_0-branch Changes by: janis@gcc.gnu.org 2005-05-02 18:05:28 Modified files: gcc : gcov-io.h ChangeLog Log message: PR 19985 * gcov-io.h: Declare gcov external functions hidden. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gcov-io.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.52&r2=1.52.34.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.210&r2=2.7592.2.211
Subject: Bug 19985 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_4-branch Changes by: janis@gcc.gnu.org 2005-05-02 18:08:50 Modified files: gcc : gcov-io.h ChangeLog Log message: PR 19985 * gcov-io.h: Declare gcov external functions hidden. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gcov-io.h.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.47.10.2&r2=1.47.10.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.852&r2=2.2326.2.853
Fixed.
This patch seems to be the reason for warnings like: In file included from ../../gcc/gcov-io.h:239, from ../../gcc/libgcov.c:51: ./auto-host.h:23:1: warning: "DEFAULT_USE_CXA_ATEXIT" redefined In file included from ./tm.h:12, from ../../gcc/libgcov.c:39: ../../gcc/defaults.h:712:1: warning: this is the location of the previous definition There are now many warnings of this type during building gcc. This is because auto-host.h is now included, but _after_ all the other headers, which do something like #ifndef BLA #define BLA ... #endif Because auto-host.h is not yet included there, BLA is not defined, so the default will be defined, and then auto-host.h is included leading to double definitions. libgcov.c talks about not able to include <config.h> because that's for the host, not for the target. So I don't know if auto-host.h (also for the host) should be included at all. But if it is, then it has to be earlier. Perhaps in libgcov.c directly as first file.