Bug 19985 - [3.4/4.0/4.1 Regression] executables created with -fprofile-arcs -ftest-coverage segfault in gcov_exit ()
Summary: [3.4/4.0/4.1 Regression] executables created with -fprofile-arcs -ftest-cover...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: 3.4.4
Assignee: Janis Johnson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-15 21:43 UTC by Lothar Werzinger
Modified: 2005-07-23 22:49 UTC (History)
3 users (show)

See Also:
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 (6.97 KB, application/octet-stream)
2005-02-15 21:46 UTC, Lothar Werzinger
Details
smaller C test case (884 bytes, application/octet-stream)
2005-03-10 19:42 UTC, Janis Johnson
Details
small C++ test case for which executable must export a symbol (1.34 KB, application/octet-stream)
2005-03-15 17:17 UTC, Janis Johnson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lothar Werzinger 2005-02-15 21:43:29 UTC
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
Comment 1 Lothar Werzinger 2005-02-15 21:46:26 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
Comment 2 Andrew Pinski 2005-02-15 21:55:02 UTC
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?
Comment 3 Lothar Werzinger 2005-03-01 01:03:17 UTC
Changed severity to critical, as the compiler produces code that crashes when  
executing a coverage enabled executable. 
  
Comment 4 Andrew Pinski 2005-03-01 01:15:25 UTC
(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.
Comment 5 Lothar Werzinger 2005-03-01 01:23:05 UTC
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 
 
Comment 6 Renier Morales 2005-03-08 03:59:49 UTC
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.  
Comment 7 Janis Johnson 2005-03-10 19:42:14 UTC
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=".
Comment 8 Janis Johnson 2005-03-11 01:32:23 UTC
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".
Comment 9 Janis Johnson 2005-03-11 23:53:53 UTC
This is a regression from GCC 3.3.  I'm working on a patch.
Comment 10 Janis Johnson 2005-03-15 17:17:44 UTC
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.
Comment 11 Janis Johnson 2005-03-25 00:09:02 UTC
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.
Comment 12 CVS Commits 2005-05-02 18:02:56 UTC
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

Comment 13 CVS Commits 2005-05-02 18:05:46 UTC
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

Comment 14 CVS Commits 2005-05-02 18:09:05 UTC
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

Comment 15 Andrew Pinski 2005-05-02 19:02:35 UTC
Fixed.
Comment 16 Michael Matz 2005-06-21 20:31:20 UTC
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.