0

So, this question might sound quite strange, but let me explain: I have written a code in C++ to analyze some data, and this data is separated in files. I pass names of these files (there are many of them) as an argument to the program. Maybe I've made some mistake in my code or maybe the data in some of these files ain't "good" and that doesn't matter for now. But for some files the program stops and returns me a segfault message. There is a way to even with the segfault jump to the next file in the argument list using only C++?

Maybe I could use some shell script to run it for each of the files and then, if I get a segfault it'll continue running one by one. But that is not what I want for now, if I can't solve this I will try this way.

Thank you guys in advance.

bartop
  • 9,971
  • 1
  • 23
  • 54
Leonardo
  • 1
  • 1
    The problem is a segfault (or its cause) could leave either your program, the runtime support library or both in an inconsistent state. If you continue, ignoring the segfault, you can not trust any subsequent results. – Richard Critten May 28 '18 at 17:20
  • Either edit your program to fix the segfaults, or use a shell script to invoke the command with different parameters. – Paul Belanger May 28 '18 at 17:23
  • operating system? This really can't be done in an OS-independant way. But your idea of starting a seperate process is the cleanest solution. It provides the OS with a way to encapsulate and isolate failure. Whether you start the other process via a shell, CreateProcess() or fork() depends on your specifics. – PeterT May 28 '18 at 17:23
  • *Maybe I've made some mistake in my code* -- Note that a failure may have originated in the code you think is ok, and the segmentation fault is just a symptom of previous bad code. So how reliable is your program if it has seg faults like this? Isolate the bad file or bad data, *reproduce the seg fault* (which should have been the first thing done), and fix the error. As to starting new processes -- what if it is discovered that you're seg faulting hundreds of times a day or a week? At some point, the temporary work around of starting new processes may not be viable. – PaulMcKenzie May 28 '18 at 17:37

1 Answers1

3

You can in fact install a signal handler for SIGSEGV (on most Unix like operating systems) that will be called when your program runs into a segfault, and if you wish you can handle that in whatever way seems appropriate (including ignoring it). Doing so is quite esoteric (java does it, but that's the only semi-sane usage I've ever seen) and rarely the right thing to do, and dealing with the fault correctly in such a handler is difficult as you can't really be sure what caused the fault and what the state of your program is after you return from the signal handler.

So, while you can "handle" SIGSEGV I'd advice you instead look into other ways of sanitizing your input data so that you instead avoid the segfault in the first place.

Jesper Juhl
  • 30,449
  • 3
  • 47
  • 70
  • 1
    For more detail on why catching sigsegv isn't viable, see [Why is a segmentation fault not recoverable?](https://stackoverflow.com/q/70258418) - the buggy code that crashed might have corrupted some variables before hitting the "guard rails" (a load or store that actually faulted, thanks to CPU hardware memory protection). – Peter Cordes Nov 04 '22 at 20:19