- Forum
- UNIX/Linux Programming
- catch SIGSEGV in a library
catch SIGSEGV in a library
I'm loading various shared libraries (think of them as small plugins) at runtime. My problem is that these "plugins" will be provided by third parties. So I don't have control over them and they could contain bugs that may lead to a SIGSEGV (segmentation fault). But I don't want the main program or the other "plugins" to crash. I know that you could try to catch such a signal in the main program (in the tread that is running the plugin) and then shut down the library (dlclose) and the associated thread.
But segmentation faults usually lead to an undefined state, which is not always recoverable. Altough I'm not 100% sure what this means in reality I think this is not the best idea.
Starting a new process that is some kind of interface seems quite ineffective to me. I'm also importing some classes from the library that may contain user implemted code (although the user isn't able to change the header).
So what are my options to prevent a crash?
But segmentation faults usually lead to an undefined state, which is not always recoverable. Altough I'm not 100% sure what this means in reality I think this is not the best idea.
Starting a new process that is some kind of interface seems quite ineffective to me. I'm also importing some classes from the library that may contain user implemted code (although the user isn't able to change the header).
So what are my options to prevent a crash?
I've noticed that a number of FreeBSD Ports use libsigsegv. I expect this might help, but I haven't really looked at it myself.
http://www.gnu.org/software/libsigsegv/
http://www.gnu.org/software/libsigsegv/
Last edited on
From my experiences it might be really difficult to write programs which may recover from crashes. Besides inconsistent object states you also may come in trouble with process/thread synchronization. F.e. a crash might occur while one of your threads, especially the crashing one, has allocated a mutual exclusive lock...
It may not be the worst idea to split a big program into several smaller ones running them as independent processes. Interprocess communication especially on real time operating systems like f.e. QNX is highly efficient. (But try avoiding shared memory for other reasons than message passing).
You may also want to periodically, persistently save your processes state to easily recover from it after a crash.
We do often use such methods for high reliable industrial applications which should run 24 hours a day and 7 days a week.
It may not be the worst idea to split a big program into several smaller ones running them as independent processes. Interprocess communication especially on real time operating systems like f.e. QNX is highly efficient. (But try avoiding shared memory for other reasons than message passing).
You may also want to periodically, persistently save your processes state to easily recover from it after a crash.
We do often use such methods for high reliable industrial applications which should run 24 hours a day and 7 days a week.
@tcs
Ok. I will see if it's possible to change my design to a multiprocess application.
I'm curious. What's the problem with shared memory? The only thing that I heard of it is that it is very efficient instead of messaging. For messages I should use the message queue from boost (Somewhere on stack overflow. Can't find the website anymore...)
@kbw
I also came across libsigsegv. But I first thought that it's only a wrapper around <signal.h>. But perhaps it is at least worth looking into it.
Ok. I will see if it's possible to change my design to a multiprocess application.
I'm curious. What's the problem with shared memory? The only thing that I heard of it is that it is very efficient instead of messaging. For messages I should use the message queue from boost (Somewhere on stack overflow. Can't find the website anymore...)
@kbw
I also came across libsigsegv. But I first thought that it's only a wrapper around <signal.h>. But perhaps it is at least worth looking into it.
Topic archived. No new replies allowed.