2

I'm using an external library (xqilla) for c++ that ends with a segmentation fault for some uri's, and some not. I'm a bit new to the whole C world, I'm guessing it's not possible to catch this as if it was an exception, but I need to ask if it's possible. Any other solution would of course also be welcomed.

So is there an alternative to try catch for a "Segmentation fault" error?

superhero
  • 6,281
  • 11
  • 59
  • 91
  • 1
    http://stackoverflow.com/questions/10202941/segmentation-fault-handling – chris Dec 09 '14 at 23:01
  • 2
    No. If the library is broken, you have few alternatives other than to report the error and hope they fix it, write your own, or perhaps write a wrapper around it that protects it from inputs it fails on (assuming you can predict ahead of time what those are). – Lee Daniel Crocker Dec 09 '14 at 23:02
  • 2
    More likely than not, your memory is no longer in a consistent state after such event, which would prohibit normal continuation of the program even if you somehow ignore the error itself. – Branko Dimitrijevic Dec 09 '14 at 23:02

3 Answers3

7

If you run your program in a debugger, it will tell you what instruction caused the bad memory access in question, so that you can fix it.

Alternatively, you can add a signal handler via signal(2) or sigaction(2), but your ability to debug in that way will probably be pretty difficult. The state of your program after such a fault is probably unpredictable.

Carl Norum
  • 219,201
  • 40
  • 422
  • 469
  • 1
    You think someone knew to C can fix a 3rd party DLL? I bet most long time professionals would find such a task quite challenging. – Mooing Duck Dec 09 '14 at 23:07
  • I debugged it now and noticed that the error was caused in a different part of the library then I first thought. The code is just a dummy example for me to understand the library before implementing it in the application where it will be used. Running linux, so it's an `.so` file ;) Anyway could you give an example of how to add a handler through `signal(2)` or `sigaction(2)`? I like to attach a logger when the error occurs. The code is server sided and is running on a lot of different servers. Logging witch one had the problem would be essential for future implementation. – superhero Dec 09 '14 at 23:55
  • @MooingDuck, xqilla appears to be open source, I kind of assumed OP had built it himself. That would make the debugging pretty straighforward. And for the record, linker options will usually allow you to insert a shim function if you really need to for a closed source case, letting you log or modify the inputs as necessary to end up with success. – Carl Norum Dec 10 '14 at 00:00
3

If you are receiving a segmentation fault with a third party library, you should first narrow the scope of the problem and make sure that the bug is in your program and not the library. In the event of it being the fault of the library, you could save a lot of wasted effort by reporting the bug to the maintainer or searching the mailing list, documentation, etc.

Once you've gotten past this and decide to debug your program, capturing the "segmentation fault" is not what you want to do. The behavior is undefined at this point1. You should compile with -g (if on GCC or Clang) to generate debugging information and run it with a debugger. There are several tools that can help you catch and fix bugs:

  • GCC and Clang's warning options, -Wall -Wextra -pedantic
  • LLVM's sanitizer, which exist in both GCC and Clang. In particular, you can try out -fsanitize=undefined,address,leak2
  • GNU's debugger, gdb
  • Valgrind

You will save a lot of effort by following the normal route of fixing your program instead of a backhanded way.

1) Source: Segmentation fault handling

2) Don't run valgrind and the sanitizer at the same time. Some sanitizers are mutually exclusive as well.

2

I'm not familiar with xquilla specifically, but a "Segmentation fault" formally indicates that the program attempted to access a memory address that hasn't been allocated to it. With extremely rare exceptions (e.g. emulation of a different computer altogether) this indicates a catastrophic bug in the program. It is likely that, by careful manipulation of the input, the program can be made to misbehave in an arbitrarily malicious fashion rather than just crashing.

Your best option is to scrap this library and find one that does the same job but with fewer bugs.

If that's not an option, your second-best bet is to isolate the library in a separate process, running in a "sandbox" which prevents it from damaging anything when it crashes or is taken over by malware. The rest of your application would then detect the crash, clean up, and move on. Unfortunately, writing such a sandbox is Hard, and I don't know of any off-the-shelf code you can use. Good luck!

zwol
  • 135,547
  • 38
  • 252
  • 361