A C++ exception causes a ABORT signal

[papypapa]

Hello C++ developers,

Context: program written in C++ and run under Linux


1) I ignore the ABORT signal by using the "signal" primitive ==> signal(SIGABRT,SIG_IGN); ==> OK

2) I try to connect (a c++ client) to a server by using the 'connect" primitive.
It fails because the server is not present ==> OK
In this case, i throw an exception.
The problem is that the kernel sends the ABORT signal whereas i have ignored it.

NOTE: If i don't send an exception because the connect has failed the ABORT is ignored correctly.


Thank you very much for your help.


PS:
Sorry for my bad english.

[jsmith]

Ignoring a signal does not cause the kernel to not send it.

You are getting SIGABRT because you threw an exception that you did not catch, and the default
action is to raise SIGABRT.

[papypapa]

Hello Jsmith,

In fact, i catch the exceptions in the upper layer.

To explain better:


I have a code (lower layer) which encapsulates the calls of the primitives "socket" and which throws some exceptions in case of problems and an upper layer (more "functional") which invokes/uses this layer and which catches the exceptions and also throws some exceptions.
But for a thread given, after catching exception when the upper layer throws an exception it's
at this moment that the ABORT signal is sent. It's the lower layer which calls signal(SIGABRT,SIG_IGN);

[jsmith]

It still sounds like an exception is being thrown that you aren't catching.

Wrap main() and all thread main functions in try-catch( ... ) blocks to see
if you're not catching everything.

[chrisname]

You can't ignore or mask SIGABRT, that's why it's SIGABRT. You can ignore SIGINT and even SIGTERM, but SIGABRT means the sender really wants you to go away.

You can catch it, but as soon as your interrupt handler returns you get killed anyway. Excerpt from Wikipedia's page on SIGABRT,

Wikipedia wrote:

The SIGABRT signal can be caught, but it cannot be blocked; if the signal handler returns then all open streams are closed and flushed and the program terminates (dumping core if appropriate).

[papypapa]

Hello chrisname,

I don't understand because (imagine i don't use the exceptions, i don't send any error code or a boolean = false after connection failure).

When i cannot to connect to the server the kernel sends a SIGABORT ==> OK

But if before i run signal(SIGABRT,SIG_IGN) and after i try to connect (server not ready) it fails (OK) and the kernel does not send the SIGABRT and the program continues without problem after the "connect" call.


On the following web site it is indicated that SIGKILL and SIGSTOP cannot be blocked only:

http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_21.html#SEC332

[chrisname]

When an exception is thrown it raises SIGABRT. If the program isn't getting SIGABRT, then the exception isn't being thrown (or abort() not called or SIGABRT not raise()d).

SIGABRT cannot be blocked or ignored. It can be handled but as I said, as soon as the handler returns, the process is reaped.

[papypapa]

In fact, my problem is that the exceptions are thrown across shared librairies.


Google for "GCC exceptions across shared libraries" or look at
http://gcc.gnu.org/faq.html#dso.

[jsmith]

Are you using open source libraries that throw exceptions back to the user? It is generally a bad programming
practice to throw exceptions beyond the library boundary because the user may only be able to catch them
through ellipsis.

[papypapa]

I'm not using open source libraries but it's same. I have a library (low layer) which encapsulates the system functions (socket, thread, ....) . This library is used by the high layer. Indeed, when there is an error an exception is thrown like it's written in some open source libraries.