Red Hat Bugzilla – Bug 106934
exception not caught when gcc is used with dl_open
Last modified: 2007-11-30 17:06:53 EST
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.
Created attachment 95136 [details] zip file with a README on how to reproduce the bug.
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
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
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.
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
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
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.
If you have more info, please reopen.