10

I wrote a Linux program based on a buggy open source library. This library sometimes triggers segfaults that I cannot control. And of course once the library has segfaults, the entire program dies. However, I have to make sure my program keeps running even if the library has segfaults. This is because my program sort of serves as a "server" and it needs to at least tell the clients something bad happened and recover from the errors, rather than chicken out... Is there any way to do that?

I understand in Java one just needs to catch an exception. But how does C++ handle this?

[UPDATE]I understand there is also exception handling in C++, but Segfault is not an exception, is it? I don't think anything is thrown when segfault happens. You have to explicitly "throw" something to use try.... catch.... as far as I know.

Thanks so much, I am quite new to C++.

CuriousMind
  • 15,168
  • 20
  • 82
  • 120
  • Google is your friend -> http://www.cplusplus.com/doc/tutorial/exceptions/ : ) – Carlos Daniel Gadea Omelchenko May 15 '11 at 12:54
  • Hi Carlos. I understand this part, but Segfault is not an exception, is it? I don't think anything is thrown when segfault happens. You have to explicitly "throw" something to use try.... catch.... as far as I know. – CuriousMind May 15 '11 at 12:55
  • Someone wrote open source library for common good. You are one who needs it for your program to work. Unfortunately it contains a defect (or couple) that make your program to crash. So why to search ways around defects? Can't you track down and fix the defects? Working around defects is always harder than fixing them. Also you can send patch of fixes to author of the library and so make our world little bit better place as result. – Öö Tiib May 15 '11 at 13:33

5 Answers5

15

You cannot reliably resume execution after a segmentation violation. If your program must remain running, fence off the offending library in a separate process and communicate with it over a pipe. When it takes a segmentation violation, your program will notice the closed pipe.

Sam Miller
  • 23,808
  • 4
  • 67
  • 87
4

Unfortunately, you cannot make the program continue. The buggy code that resulted in SIGSEGV usually triggers undefined behaviour like dereferencing a null pointer or reading garbage memory. You cannot possibly continue if your code operates on invalid data.

You can handle the signal, but the most you can do is dump the stack trace and die.

C and C++ are inherently unsafe, you cannot handle errors triggered by undefined behaviour and let the program continue.

Alex B
  • 82,554
  • 44
  • 203
  • 280
3

You can use signal handlers. It's not really recommended though because you can't guarantee that you've eliminated the cause of the problem. The best thing to do would be to isolate it in a separate process- this is the approach Google Chrome takes.

If it's FOSS, the easiest thing to do would be to just debug it.

Puppy
  • 144,682
  • 38
  • 256
  • 465
2

If you have access to the source, it might be useful to run the programmer in a debugger like GDB. GDB stops at the line which causes the segfault.

If you really want to catch the signal though, you need to hook up a signal handler, using the signal system call. I would probably just stick to the debugger though.

EDIT: Since you write that the library segfaults, I would just like to point out the first rule of programming: It's always your fault. Especially if you are a new to C++, the segfault probably happens because you have used the library incorrectly in some way. C++ is a very subtle language and it is easy to do things you don't intend.

Jørgen Fogh
  • 7,516
  • 2
  • 36
  • 46
  • Thanks for your reply. Is there any reason that singal handler is not recommended? I just want to keep my program running since it is a server side program that needs to be immunized. I would totally love to hack around the underlying libraries, except that I am not good enough to do so. =( How do people handle this kind of situation (when server needs to keep running). – CuriousMind May 15 '11 at 13:03
  • The reason is that you would normally want to find the error and fix it, in which case writing a signal handler is probably more trouble than it's worth. The library probably segfaults because of invalid input, so you should find out what happens and avoid it instead of trying to fix it at runtime. – Jørgen Fogh May 15 '11 at 16:57
  • A good answer (+1), but `sigaction` is preferred over `signal`. – Mawg says reinstate Monica Jun 30 '16 at 15:48
0

As mentioned over here you can’t catch segfault signals with try blocks or “map” segment violations to anything. It’s really bad idea to handle SIGSEGV yourself. SEGV from C++ code is a severe error. You can use gdb to figure it out why and solve it.

Ashish Khandelwal
  • 611
  • 8
  • 6