| Summary: | [3.4/4.0/4.1 Regression] executables created with -fprofile-arcs -ftest-coverage segfault in gcov_exit () | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Lothar Werzinger <lothar> |
| Component: | middle-end | Assignee: | Janis Johnson <janis> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | gcc-bugs, hubicka, matz |
| Priority: | P2 | ||
| Version: | 4.0.0 | ||
| Target Milestone: | 3.4.4 | ||
| Host: | Target: | ||
| Build: | Known to work: | 4.0.1 4.1.0 3.4.4 | |
| Known to fail: | 3.4.1 4.0.0 | Last reconfirmed: | |
| Attachments: |
test case to reproduce the segfault
smaller C test case small C++ test case for which executable must export a symbol |
||
|
Description
Lothar Werzinger
2005-02-15 21:43:29 UTC
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.
|