c++/4678: Exception Handling Not Working on Large -fPIC Applications

c++/4678: Exception Handling Not Working on Large -fPIC Applications

[grendel]

>Number:         4678
>Category:       c++
>Synopsis:       Exception Handling Not Working on Large -fPIC Applications
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Oct 25 16:26:20 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Bill Reynolds
>Release:        unknown-1.0
>Organization:
>Environment:
Linux - stock redhat 7.1 w/all upgrades
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85)
>Description:
This bug is only reproducable when building a large (~60k lines of code) dll for a Java/JNI application. The application (and exception handling) works fine under windows using mingw.

An exception of the following form:

 Exception e("Instantiated outside of try block");

 try
 {
    throw e;
 }
 catch(Exception &e)
 {
   cerr<< "Caught Exception: " << e.getMessage() << "\n";
 }
 catch(...)
 {
   cerr<< "Caught Unknown Exception\n" ;
 }


works. The following snippet:


 try
 {
    throw Exception("Instantiated within try block");
 }
 catch(Exception &e)
 {
   cerr<< "Caught Exception: " << e.getMessage() << "\n";
 }
 catch(...)
 {
   cerr<< "Caught Unknown Exception\n" ;
 }


causes a core dump.

Here is the stack trace. Note that __rethrow is being called: the exception was never caught, even though there was a catch(...) block.


#0  0x40374ae1 in __kill () from /lib/i686/libc.so.6
#1  0x4003276b in raise (sig=6) at signals.c:65
#2  0x40376062 in abort () at ../sysdeps/generic/abort.c:88
#3  0x404eae55 in __default_terminate () from /usr/lib/libstdc++-libc6.1-1.so.2
#4  0x404eae72 in __terminate () from /usr/lib/libstdc++-libc6.1-1.so.2
#5  0x4a9c7f01 in __rethrow (index=0x4a4c15dc) at ../../gcc/libgcc2.c:3168
#6  0x4a4b8f94 in Java_com_leastsquares_decision_gambit_GambitWrapper_setDimsNative (env=0x804e094, obj=0xbfffd46c, hashCode=7474923, nPlayerOneDims=15, 
    nPlayerTwoDims=10) at GambitWrapperInterface.cc:55
#7  0x08062055 in ?? () at eval.c:41
#8  0x0805f685 in ?? () at eval.c:41
#9  0x0805f685 in ?? () at eval.c:41
#10 0x0805f685 in ?? () at eval.c:41
#11 0x40338d7e in StubRoutines::_code1 () at eval.c:41
#12 0x40130604 in JavaCalls::call_helper () at eval.c:41
#13 0x4018e48d in os::os_exception_wrapper () at eval.c:41
#14 0x40130840 in JavaCalls::call () at eval.c:41
#15 0x40135c1a in jni_invoke () at eval.c:41
#16 0x40140bb7 in jni_CallStaticVoidMethod () at eval.c:41
#17 0x08049344 in main () at eval.c:41
#18 0x40362627 in __libc_start_main (main=0x8048c90 <main>, argc=2, 
    ubp_av=0xbffff7b4, init=0x8048974 <_init>, fini=0x804aaec <_fini>, 
    rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbffff7ac)
    at ../sysdeps/generic/libc-start.c:129
>How-To-Repeat:
Unknown, small test cases behave correctly. I'll be happy to send the whole application to any interested party.
>Fix:
Unknown. Tried all of the -fexception-* flags ( -fexceptions, -fnew-exceptions, -fsj-lj-exceptions, -funwind-tables). 
>Release-Note:
>Audit-Trail:
>Unformatted: