Writing Signal handlers for Shared libraries or DLL?

Question

I have a Application A(by some company X). This application allows me to extend the functionality by allowing me to write my own functions.

I tell the Application A to call my user functions in the Applications A's configuration file (this is how it knows that Appl A must call user written Functions). The appl A uses Function pointers which I must register with Application A prior to calling my user written functions.

If there is a bug or fault in my user written functions in production, the Appl A will stop functioning. For example, if I have a segmentation fault in my User written functions.

So Application A will load my user written function from a shared DLL file. This means that my user written functions will be running in Application A' Process address space.

I wish to handle certain signals like Segmentation fault, divide by zero and stack overflow, but applications A has its own signal handlers written for this,

How can I write my own signal handlers to catch the exceptions in my user written functions, so that I can clean up gracefully w/o affecting much of Application A? Since my user functions will be called in Applications A's process, the OS will call signal handlers written in Application A and not my user functions.

How can I change this? I want OS to call signal handlers written in my functions but only for signal raised by my functions, which is asynchronous in nature.

Note: I do not have the source code of Application A and I cannot make any changes to it, because it's controlled by a different company.

I will be using C , and only C on a Linux, solaris and probably windows platforms.

Answer 1

You do not specify which platform you're working with, so I'll answer for Linux, and it should be valid for Windows as well.

When you set your signal handlers, the system call that you use returns the previous handler. It does it so that you can return it once you are no longer interested in handling that signal.

Linux man page for signal
MSDN entry on signal

Since you are a shared library loaded into the application you should have no problems manipulating the signals handlers. Just make sure to override the minimum you need in order to reduce the chances of disrupting the application itself (some applications use signals for async notifications).

Answer 2

The cleanest way to do this would be run your application code in a separate process that communicates with the embedded shared DLL code via some IPC mechanism. You could handle whatever signals you wanted in your process without affecting the other process. Typically the conditions you mention (seg fault, divide by zero, stack overflow) indicate bugs in the program and will result in termination. There isn't much you can do to "handle" these beyond fixing the root cause of the bug.

Answer 3

in C++, you can catch these by putting your code in a try-catch:

try
{
   // here goes your code
}
catch ( ... )
{
   // handle segfaults
}