Bug 106934 - exception not caught when gcc is used with dl_open
exception not caught when gcc is used with dl_open
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: gcc (Show other bugs)
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Depends On:
  Show dependency treegraph
Reported: 2003-10-13 15:58 EDT by Lily Hsiao
Modified: 2007-11-30 17:06 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-30 05:42:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
zip file with a README on how to reproduce the bug. (2.44 KB, text/plain)
2003-10-13 16:05 EDT, Lily Hsiao
no flags Details

  None (edit)
Description Lily Hsiao 2003-10-13 15:58:58 EDT
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. 


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

How reproducible:

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 16:05:21 EDT
Created attachment 95136 [details]
zip file with a README on how to reproduce the bug.
Comment 2 Lily Hsiao 2003-10-13 16:06:47 EDT
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 16:08:02 EDT
packages info: 
Comment 4 Lily Hsiao 2003-12-16 19:03:10 EST
This problem does not occur with gcc 3.3.2. 
We are now waiting for RPM from RedHat for gcc 3.3.2 (binary).
Comment 5 Jakub Jelinek 2004-01-09 09:54:09 EST
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.
test_func returned 0.
test_func returned 0.
bash-2.05$ rpm -q glibc; rpm -q gcc
Comment 6 Lily Hsiao 2004-01-09 12:57:39 EST
This happens consistently on our RH AS 2.1. 
There is a difference in glibc and gcc though: 
% rpm -q glibc; rpm -q gcc

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. 

Comment 7 Richard Henderson 2004-10-04 01:42:20 EDT
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 05:42:08 EDT
If you have more info, please reopen.

Note You need to log in before you can comment on or make changes to this bug.