RE: Exception thrown from multithreaded shared lib not caught in main

RE: Exception thrown from multithreaded shared lib not caught in main

[Martin York]

void Lixo::lib_func() throw()
{
    throw Lixo::ValidationException("Hello!");
}

The above code, will result in a call to std::unexpected() and thus to std::terminare() and from there abort() resulting in the application exiting without the stack unwinding to main().

By specifying that the method 'lib_func()' throws nothing 'throw()' any thrown exception (because they are all unexpected) should generate a call to std::unexpected().




Martin.


 

-----Original Message-----
From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On Behalf Of Joao Luis Pinto
Sent: 06 December 2004 03:05
To: gcc-help@gcc.gnu.org
Subject: Re: Exception thrown from multithreaded shared lib not caught in main

Hello again,

Following my previously presented problem, I have built an example that replicates the problem:

http://jpinto.homeip.net/~jpinto/lixo-0.1.0.tar.gz

Just run ./configure && make check

It builds a shared library with a function that throws an exception, and an executable that calls the library function. Aparently multi-threading is not the issue. The problem is that the exception is never caught in main(), and unhandled() gets called.

Tested with g++-3.3.4 and g++-3.4.2 (Debian testing x86).

Thank you for your time.

João Luis

Re: Exception thrown from multithreaded shared lib not caught in main

[Joao Luis Pinto]

Hi Martin,

>void Lixo::lib_func() throw()
>{
>    throw Lixo::ValidationException("Hello!");
>}
>
>The above code, will result in a call to std::unexpected() and thus to std::terminare() and from there abort() resulting in the application exiting without the stack unwinding to main().
>
>By specifying that the method 'lib_func()' throws nothing 'throw()' any thrown exception (because they are all unexpected) should generate a call to std::unexpected().
>  
>

That was it! Silly me... :$

Thanks for the reminder, and to Lyle for also having a look.

João Luis

RE: Exception thrown from multithreaded shared lib not caught in main

[lrtaylor]

There's more to handling exceptions than just linking with the shared version of libgcc...  However, I think Martin probably has found your problem.  That was actually my first thought, but I stopped looking when I saw the build line...

Thanks,
Lyle


-----Original Message-----
From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On Behalf Of Joao Luis Pinto
Sent: Tuesday, December 07, 2004 8:19 AM
To: lrtaylor
Cc: gcc-help@gcc.gnu.org
Subject: Re: Exception thrown from multithreaded shared lib not caught in main

lrtaylor@micron.com wrote:

>Is there a particular reason you're using -nostdlib when building your library:
>
>g++ -shared -nostdlib /usr/lib/crti.o /mu/dev/gcc/3.3.1/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/crtbeginS.o  .libs/lib_func.o .libs/validation_exception.o .libs/exception.o  -Wl,--rpath -Wl,/mu/dev/gcc/3.3.1/lib/. -Wl,--rpath -Wl,/mu/dev/gcc/3.3.1/lib/. -L/mu/dev/gcc/3.3.1/lib/gcc-lib/i686-pc-linux-gnu//3.3.1 -L/mu/dev/gcc/3.3.1/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/../../.. /mu/dev/gcc/3.3.1/lib/./libstdc++.so -lm -lc -lgcc_s /mu/dev/gcc/3.3.1/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/crtendS.o /usr/lib/crtn.o  -Wl,-soname -Wl,liblixo-0.1.0.so -o .libs/liblixo-0.1.0.so
>
>In order for exceptions to be thrown across a library boundary, your library needs to be linked properly.  I suspect it's not.  Why not just let g++ determine what standard libraries to link to, etc.?  You might also try adding the argument --eh-frame-hdr which is needed for setting up stack unwinding.  I don't know if it will work the way you're doing things, thouugh...
>
>Thanks,
>Lyle
>  
>
Hi Lyle,

The -nostdlib flag was set by a (more or less vanilla) 
autoconf-automake-with-libtool run. I didn't set it manualy. Anyway, 
libstdc++ and libgcc (shared version libgcc_s) are manualy linked later 
on, as you can see also in your run. Is there some startup action being 
lost in this built process by using the flag?

As for the linker flag, quoting the g++ man page:

"However, if a library or main executable is supposed to throw or catch 
exceptions, you must link it using the G++ or GCJ driver, as appropriate 
for the languages used in the program, or using the option 
-shared-libgcc, such that it is linked with the shared libgcc."

But it looks like libgcc_s is being linked in.

Any idea on what might be going on?

Thank you,

João Luis

Re: Exception thrown from multithreaded shared lib not caught in main

[Joao Luis Pinto]

lrtaylor@micron.com wrote:

>Is there a particular reason you're using -nostdlib when building your library:
>
>g++ -shared -nostdlib /usr/lib/crti.o /mu/dev/gcc/3.3.1/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/crtbeginS.o  .libs/lib_func.o .libs/validation_exception.o .libs/exception.o  -Wl,--rpath -Wl,/mu/dev/gcc/3.3.1/lib/. -Wl,--rpath -Wl,/mu/dev/gcc/3.3.1/lib/. -L/mu/dev/gcc/3.3.1/lib/gcc-lib/i686-pc-linux-gnu/3.3.1 -L/mu/dev/gcc/3.3.1/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/../../.. /mu/dev/gcc/3.3.1/lib/./libstdc++.so -lm -lc -lgcc_s /mu/dev/gcc/3.3.1/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/crtendS.o /usr/lib/crtn.o  -Wl,-soname -Wl,liblixo-0.1.0.so -o .libs/liblixo-0.1.0.so
>
>In order for exceptions to be thrown across a library boundary, your library needs to be linked properly.  I suspect it's not.  Why not just let g++ determine what standard libraries to link to, etc.?  You might also try adding the argument --eh-frame-hdr which is needed for setting up stack unwinding.  I don't know if it will work the way you're doing things, though...
>
>Thanks,
>Lyle
>  
>
Hi Lyle,

The -nostdlib flag was set by a (more or less vanilla) 
autoconf-automake-with-libtool run. I didn't set it manualy. Anyway, 
libstdc++ and libgcc (shared version libgcc_s) are manualy linked later 
on, as you can see also in your run. Is there some startup action being 
lost in this built process by using the flag?

As for the linker flag, quoting the g++ man page:

"However, if a library or main executable is supposed to throw or catch 
exceptions, you must link it using the G++ or GCJ driver, as appropriate 
for the languages used in the program, or using the option 
-shared-libgcc, such that it is linked with the shared libgcc."

But it looks like libgcc_s is being linked in.

Any idea on what might be going on?

Thank you,

João Luis

RE: Exception thrown from multithreaded shared lib not caught in main

[lrtaylor]

Is there a particular reason you're using -nostdlib when building your library:

g++ -shared -nostdlib /usr/lib/crti.o /mu/dev/gcc/3.3.1/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/crtbeginS.o  .libs/lib_func.o .libs/validation_exception.o .libs/exception.o  -Wl,--rpath -Wl,/mu/dev/gcc/3.3.1/lib/. -Wl,--rpath -Wl,/mu/dev/gcc/3.3.1/lib/. -L/mu/dev/gcc/3.3.1/lib/gcc-lib/i686-pc-linux-gnu/3.3.1 -L/mu/dev/gcc/3.3.1/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/../../.. /mu/dev/gcc/3.3.1/lib/./libstdc++.so -lm -lc -lgcc_s /mu/dev/gcc/3.3.1/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/crtendS.o /usr/lib/crtn.o  -Wl,-soname -Wl,liblixo-0.1.0.so -o .libs/liblixo-0.1.0.so

In order for exceptions to be thrown across a library boundary, your library needs to be linked properly.  I suspect it's not.  Why not just let g++ determine what standard libraries to link to, etc.?  You might also try adding the argument --eh-frame-hdr which is needed for setting up stack unwinding.  I don't know if it will work the way you're doing things, though...

Thanks,
Lyle


-----Original Message-----
From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On Behalf Of Joao Luis Pinto
Sent: Monday, December 06, 2004 1:05 AM
To: gcc-help@gcc.gnu.org
Subject: Re: Exception thrown from multithreaded shared lib not caught in main

Hello again,

Following my previously presented problem, I have built an example that 
replicates the problem:

http://jpinto.homeip.net/~jpinto/lixo-0.1.0.tar.gz

Just run ./configure && make check

It builds a shared library with a function that throws an exception, and 
an executable that calls the library function. Aparently multi-threading 
is not the issue. The problem is that the exception is never caught in 
main(), and unhandled() gets called.

Tested with g++-3.3.4 and g++-3.4.2 (Debian testing x86).

Thank you for your time.

João Luis

Re: Exception thrown from multithreaded shared lib not caught in main

[Joao Luis Pinto]

Hello again,

Following my previously presented problem, I have built an example that 
replicates the problem:

http://jpinto.homeip.net/~jpinto/lixo-0.1.0.tar.gz

Just run ./configure && make check

It builds a shared library with a function that throws an exception, and 
an executable that calls the library function. Aparently multi-threading 
is not the issue. The problem is that the exception is never caught in 
main(), and unhandled() gets called.

Tested with g++-3.3.4 and g++-3.4.2 (Debian testing x86).

Thank you for your time.

João Luis

Exception thrown from multithreaded shared lib not caught in main

[Joao Luis Pinto]

Dear all:

I'm building an executable that uses 2 shared libraries, compiled with 
-pthread. The executable is also compiled with -pthread. I'm using g++ 
version 3.3.4 (Debian testing x86).

One of the mentioned libraries function is throwing an exception (right 
at the start). This function call is surrounded by a try/catch block at 
main, that catches the particular thrown exception, all derived from 
std::exception and all unhandled (catch(...) ). The problem is that the 
exception does not reach this block, and abort is called. Here's a stack 
trace from gdb:

[Thread debugging using libthread_db enabled]
[New Thread 1077965824 (LWP 30731)]

Program received signal SIGABRT, Aborted.
[Switching to Thread 1077965824 (LWP 30731)]
0x43d4bed9 in raise () from /lib/tls/libc.so.6

(gdb) where
#0  0x43d4bed9 in raise () from /lib/tls/libc.so.6
#1  0x43d4d771 in abort () from /lib/tls/libc.so.6
#2  0x44c4c307 in __cxa_call_unexpected () from /usr/lib/libstdc++.so.5
#3  0x44c4c344 in std::terminate () from /usr/lib/libstdc++.so.5
#4  0x44c4c367 in std::terminate () from /usr/lib/libstdc++.so.5
#5  0x44c4c225 in __cxa_call_unexpected () from /usr/lib/libstdc++.so.5
#6  0x4000ec3e in Unitcommitment::read_conventional (connection=@0x0,
    longterm=true) at stl_alloc.h:242
#7  0x0804a782 in main (argc=1, argv=0x0) at main.cc:38

Any ideas on what's happening? I will be happy to provide further 
information if needed, like source code listings and g++ call transcript.

Thank you,

João Luis