Subject: Catching exceptions within a shared library
To: None <port-i386@netbsd.org>
From: None <crvich@us.ibm.com>
List: port-i386
Date: 12/29/1999 11:05:51
     After getting my C++ shared library working for our project, I ran our
battery of exhaustive test scripts over everything and discovered that all
seems to be well except one annoying thing: the shared library is incapable
of catching its own exceptions properly (it catches it, but can't do much
afterwards).  The exes can catch exceptions thrown from the lib just fine,
but if the shared lib code tries to catch its own exception, it can neither
(A) reference the exception variable properly (sometimes gdb claims it
doesn't exist, sometimes its data is corrupted), or (B) rethrow a new
exception.  Segmentation faults, memory faults, bus errors, etc. result.
This problem doesn't exist if the library is a static/archive lib.  The
problem is not affected by optimization or debugging info.

     Our code is ported to eight other OS's, and I have never seen this
behavior before.  Has anyone encountered this?  Here's a small test case
that shows the problem (using egcs 1.1.2 on NetBSD 1.3.3):

/*** code for shared lib ***/
#include <iostream.h>

int foo()
{
  int i = 42;
  try
  {
    throw i;
  }
  catch (const int &e)
  {
    cerr << "EXCEPTION: " << e << endl;  // generates memory fault
  }
}


/*** code for exe ***/
extern int foo();
int main()
{
  return foo();
}


     To get the above to work, the try/catch can be moved into the exe
around the call to foo().

---
Ernest M. Crvich
IBM ODE team
Have footbag, will shred.