target/8755: exceptions not caught from shared library on solaris 2.8

[andete at worldcity dot nl]

>Number:         8755
>Category:       target
>Synopsis:       exceptions not caught from shared library on solaris 2.8
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          rejects-legal
>Submitter-Id:   net
>Arrival-Date:   Fri Nov 29 07:16:02 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     andete@worldcity.nl
>Release:        gcc-3.2.1
>Organization:
>Environment:
see description
>Description:
Hello,

When I have a shared library that throws an exception, and I want to catch it
in my main program that links the shared library, this fails to work on Solaris,
and works fine in Linux.

System details:

It doesn't work on Solaris 2.8 (SunOS 5.8 Generic_108528-16 sun4u sparc) with:

$ gcc -v
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.2/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls
Thread model: posix
gcc version 3.2

and:

$ gcc-3.2.1-v8 -v
Reading specs from /cm/vobs/miawap/tools/real/gcc-3.2.1-v8/lib/gcc-lib/sparc-sun-solaris2.8/3.2.1/specs
Configured with: ../gcc-v8-3.2.1-v8/configure --prefix=/cm/vobs/miawap/tools/real/gcc-3.2.1-v8 --exec_prefix=/cm/vobs/miawap/tools/real/gcc-3.2.1-v8 --sysconfdir=/cm/vobs/miawap/tools/real/gcc-3.2.1-v8/etc --localstatedir=/some/dileberately/faulty/path --infodir=/cm/vobs/miawap/tools/real/gcc-3.2.1-v8/info --mandir=/cm/vobs/miawap/tools/real/gcc-3.2.1-v8/man --enable-languages=c,c++ --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --program-suffix=-3.2.1-v8 --enable-shared --disable-nls --disable-multilib
Thread model: posix
gcc version 3.2.1

It does work, on linux (Linux 2.4.17 #1 Wed Jan 2 16:05:23 CET 2002 i686 unknown unknown GNU/Linux) with:

$ gcc-3.2 -v
Reading specs from /usr/lib/gcc-lib/i386-linux/3.2.1/specs
Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,proto,pascal,objc,ada --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.2 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-java-gc=boehm --enable-objc-gc i386-linux
Thread model: posix
gcc version 3.2.1

Sample code:

1) the library:

#include "mye.hh"

void foobar()
{
	throw MyE(std::string("FOO!\n"));
}

2) the exception header mye.hh :

#include <stdexcept>
#include <string>

class MyE: public std::runtime_error
{
public:
        MyE(const std::string &msg):std::runtime_error(msg) {}
        MyE(const MyE &foo):std::runtime_error(foo) {}
private:
        MyE &operator=(const MyE &foo);
        MyE();
};

void foobar();

3) the main application:

#include "mye.hh"
#include <iostream>
#include <string>
#include <exception>

#include <stdio.h>
#include <sys/types.h>
#include "system.h"

int
main (int argc, char **argv)
{
  int i;

	std::set_terminate(__gnu_cxx::__verbose_terminate_handler);

	try
	{
		foobar();
	}
	catch (MyE e)
	{
		std::cerr << e.what();
		std::cerr << "BAR!" << std::endl;
	}

  exit (0);
}

This is what happens on Linux:

$ ./libexptest
FOO!
BAR!

On Solaris:

./libexptest
terminate called after throwing a `MyE'
  what(): FOO!

Abort (core dumped)

Dependant on wether I explicitely link in libsupc++ or not,
I get the following backtrace:

Without -lsupc++:

(gdb) bt
#0  0xff21c534 in _libc_kill () from /usr/lib/libc.so.1
#1  0xff1b5884 in abort () from /usr/lib/libc.so.1
#2  0xff2d95d4 in ?? () at dyn-string.c:70 from /usr/local/lib/libstdc++.so.5
#3  0xff2d9748 in ?? () at dyn-string.c:70 from /usr/local/lib/libstdc++.so.5
#4  0xff370a54 in _Z6foobarv () at libexp.cc:5
#5  0x10c18 in main (argc=1, argv=0xffbefafc) at libexptest.cc:47

With -lsupc++:

#0  0xff21c534 in _libc_kill () from /usr/lib/libc.so.1
#1  0xff1b5884 in abort () from /usr/lib/libc.so.1
#2  0x13690 in _ZN10__cxxabiv111__terminateEPFvvE (handler=0x2527c <abort>)
    at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:47
#3  0x136e0 in _ZSt9terminatev () at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:57
#4  0x13854 in __cxa_throw (obj=0x29980, tinfo=0xff380eac, dest=0xff370e38 <_ZN22SelectHandlerExceptionD1Ev>)
    at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:77
#5  0xff370d84 in _Z6foobarv () at libexp.cc:5
#6  0x123fc in main (argc=1, argv=0xffbefafc) at libexptest.cc:39

I think the problem is quite obvious.

Thanks,

Joost Damad
>How-To-Repeat:
Make a shared library which trows an exception and try to catch it in an application.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: