Bug 106934

Summary: exception not caught when gcc is used with dl_open
Product: Red Hat Enterprise Linux 2.1 Reporter: Lily Hsiao <lily.hsiao>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED WORKSFORME QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 2.1CC: lily.hsiao, tao
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-10-30 09:42:08 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
zip file with a README on how to reproduce the bug. none

Description Lily Hsiao 2003-10-13 19:58:58 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1)
Gecko/20020823 Netscape/7.0

Description of problem:
If I use gcc to compile code which uses dl_open and dl_sym to 
call a function from a library that catches exceptions from a subroutine, the
program crashes - the exception is not caught, 
instead a signal occurs and terminates the program. 
If the code is compiled with g++ it works fine. 
I have the reproduceable cases below.

The problem for us is that the code that calls dl_open is not ours -- 
it comes from other vendors -- ibm for domino server 6.0.2, apache, 
etc. We just write the library that they use dl_open, dl_sym to call. 
Our library use exceptions. 

The best fix/solution would be something that does not require 
our vendors to recompile their code since we don't have any control 
over that. 

Thanks.


Version-Release number of selected component (if applicable):
gcc-2.96-118.7.2

How reproducible:
Always

Steps to Reproduce:
Using files that will be provided in the attachment:  
1. run gmake to make dltest_good, dltest_bad, and libtest.so.
2. Run dltest_good, and you get this output: test_func returned 0.
3. Run dltest_bad, and you get this output: Abort (core dumped)

    

Actual Results:  Run dltest_good, you get the expected output: test_func returned 0.
Run dltest_bad, you get a core dump: Abort (core dumped)

Expected Results:  dltest_good and dltest_bad should have the same output, instead, 
dltest_bad core dumps. 
The difference is dltest_good was compiled with g++ and dltest_bad 
was compiled with gcc.

Additional info:

Reproduceable files mentioned in the description will be sent in 
the attachment.

Comment 1 Lily Hsiao 2003-10-13 20:05:21 UTC
Created attachment 95136 [details]
zip file with a README on how to reproduce the bug.

Comment 2 Lily Hsiao 2003-10-13 20:06:47 UTC
Here's the stack trace: 

#0  0x4005bb41 in __kill () at __kill:-1
#1  0x4005b91a in raise (sig=6) at ../sysdeps/posix/raise.c:27
#2  0x4005d0c2 in abort () at ../sysdeps/generic/abort.c:88
#3  0x4019e47b in __default_terminate () at ../../gcc/libgcc2.c:-1
#4  0x4019e49a in __terminate () from /usr/lib/libstdc++-libc6.2-2.so.3
#5  0x4019f1d5 in throw_helper (eh=0x401bc420, pc=0x4001a814, 
    my_udata=0xbffed3b0, offset_p=0xbffed3ac)
   from /usr/lib/libstdc++-libc6.2-2.so.3
#6  0x4019f3fa in __throw () from /usr/lib/libstdc++-libc6.2-2.so.3
#7  0x4001a815 in throw_func (arg=0x8048b23 "test_func") at testthrow.cpp:5
#8  0x4001a6b1 in test_func (arg=0x8048b23 "test_func") at testfunc.cpp:9
#9  0x08048a1e in main ()
#10 0x40049687 in __libc_start_main (main=0x8048790 <main>, argc=1, 
    ubp_av=0xbffed604, init=0x80485a8 <_init>, fini=0x8048aa0 <_fini>, 
    rtld_fini=0x4000dc54 <_dl_fini>, stack_end=0xbffed5fc)
    at ../sysdeps/generic/libc-start.c:129


Comment 3 Lily Hsiao 2003-10-13 20:08:02 UTC
packages info: 
compat-libstdc++-6.2-2.9.0.16
libstdc++-devel-2.96-118.7.2
libstdc++-2.96-118.7.2
gcc-2.96-118.7.2
gcc-objc-2.96-118.7.2
gcc-c++-2.96-118.7.2
gcc-g77-2.96-118.7.2


Comment 4 Lily Hsiao 2003-12-17 00:03:10 UTC
This problem does not occur with gcc 3.3.2. 
We are now waiting for RPM from RedHat for gcc 3.3.2 (binary).
Thanks.

Comment 5 Jakub Jelinek 2004-01-09 14:54:09 UTC
I couldn't reproduce:
bash-2.05$ make
g++ -g3 -pthread -fexceptions -Wall -Wshadow -Wwrite-strings -Woverloaded-virtual  -c testfunc.cpp -o testfunc.o
g++ -g3 -pthread -fexceptions -Wall -Wshadow -Wwrite-strings -Woverloaded-virtual  -c testthrow.cpp -o testthrow.o
g++ -fPIC -shared -rdynamic -g3 --version-script testfunc.o testthrow.o -o libtest.so
g++ -rdynamic -fexceptions -o dltest_good dltest.c -ldl
gcc -rdynamic -fexceptions -o dltest_bad dltest.c -ldl
gcc -g3 -pthread -fexceptions -Wall -Wshadow -Wwrite-strings -Woverloaded-virtual -Xlinker '-R$ORIGIN' -rdynamic -fexceptions  -o ndltest ndltest.c libtest.so
bash-2.05$ ./dltest_good; echo $?; ./dltest_bad; echo $?; ./ndltest; echo $?
test_func returned 0.
0
test_func returned 0.
0
test_func returned 0.
0
bash-2.05$ rpm -q glibc; rpm -q gcc
glibc-2.2.4-32.11
gcc-2.96-124.7.2

Comment 6 Lily Hsiao 2004-01-09 17:57:39 UTC
This happens consistently on our RH AS 2.1. 
There is a difference in glibc and gcc though: 
% rpm -q glibc; rpm -q gcc
glibc-2.2.4-32.3
gcc-2.96-118.7.2

The bug also does not occur with gcc 3.3.2. 
When will redhat come out with rpm's for those ? 

I will retry with glibc-2.2.4-32.11 and gcc-2.96-124.7.2. 

Thanks,
Lily

Comment 7 Richard Henderson 2004-10-04 05:42:20 UTC
Perhaps did you use ld to link your libraries directly, instead of using
the gcc driver?  For this to work, it is essential that there be exactly
one copy of the exception handling routines live in the application, and
linking the libraries with the driver is the best way to ensure that.

Comment 8 Jakub Jelinek 2004-10-30 09:42:08 UTC
If you have more info, please reopen.