0

Whenever I get a Segmentation Fault error, I know that somewhere I am accessing memory that "does not belong to me".

In some nonobvious cases, I have to rely on debugging tools such as a profiler (Valgrind for example).

Unfortunately, during runtime, I only get the following error message:

Segmentation Fault

And nothing else. My question is:

Why doesn't the program give more info about the error during runtime?

Ps: This is not a question on why segmentation fault errors happen: I understand why.

ihavenoidea
  • 629
  • 1
  • 7
  • 26
  • 2
    It's because computers are blatantly dumb. It's upon you to decipher what actually went wrong. Be happy about that, because that's what's saving your job, and still needs a human to look after it. – πάντα ῥεῖ Nov 04 '18 at 01:00
  • 1
    Many compilers now include extra tools to assist in the search for leaks ([example](https://stackoverflow.com/questions/37970758/how-to-use-addresssanitizer-in-gcc))and other potentially nasty conditions. First and foremost, crank up and never ignore the compiler warnings. – user4581301 Nov 04 '18 at 01:02
  • 1
    There are tools with the os. I only know MS and that tool is Watson. It will make a record of the state of the stack, etc. It generates a file that you can take back to your development system and start the debugger on. It has save me headaches in the past. – lakeweb Nov 04 '18 at 01:03
  • Thanks for pointing that out @user2079303. Downvoters, please specify why the downvote so I can make betters questions in the future. For this one in particular, I did my research and all I could find was "why" rather than "why not more info". – ihavenoidea Nov 04 '18 at 01:12
  • 1
    FWIW, MacOS/X has a relatively helpful crash-routine -- when your program crashes, a dialog appears that gives the user the option to review a crash report (which includes useful debugging information like the stack trace showing the crash-location for the thread that crashed, and what the other threads were doing at the time). You even have the option to mail the crash report to Apple, although I've never seen any useful results from doing that :/ – Jeremy Friesner Nov 04 '18 at 01:22

1 Answers1

8

No you can't, because segfaults are not reported by your program, but by your operating system receiving a trap at the CPU level (which is kind of an exception). At this point, the CPU deems your program unrecoverable and tells the operating system to stop it. Your program cannot do anything but shutdown, because the CPU gave that order.

The Quantum Physicist
  • 24,987
  • 19
  • 103
  • 189
  • Interesting, I didn't know that. – ihavenoidea Nov 04 '18 at 01:08
  • Weeelllll, your program can catch the signals and try to survive, but it probably won't be able to. When the system tells you your program's toast, it's in your best interests to believe it. Maybe you can gather some information, but your options in a signal handler are extremely limited. – user4581301 Nov 04 '18 at 01:10
  • @user4581301 Actually been thinking about this for some time. Can the operating system try to recover my program? Because traps will just set the program counter at some point and then the OS takes over. Maybe if the OS cares, it would not shut down my program and try to do something? I don't know. I know the trap stuff because I wrote emulators and emulated MMUs. But I never wrote OS kernels. – The Quantum Physicist Nov 04 '18 at 01:12
  • @user4581301 POSIX standard says that behaviour of the process is undefined if signal handler returns normally from SIGSEGV, so if the process survives, you can't know if any output or side effect after that is useful, or will possibly corrupt your data. Even if it doesn't, that outcome is not portable to other systems. – eerorika Nov 04 '18 at 01:17
  • @TheQuantumPhysicist What exactly could the OS do? The only real options it has are (a) terminate the program, or (b) let the program continue to run. (There are OS's out there that implement option (b), but it's not generally considered a useful option since if your program is buggy, letting it continue to run will probably just result in more erroneous behavior) – Jeremy Friesner Nov 04 '18 at 01:17
  • 2
    it is possible to configure a *nix system to provide core dumps which can be extremely useful with gdb https://stackoverflow.com/questions/17965/how-to-generate-a-core-dump-in-linux-when-a-process-gets-a-segmentation-fault – newbie Nov 04 '18 at 01:19
  • @JeremyFriesner Yeah, maybe you're right. It's as simple as that. It doesn't make sense to try to recover a buggy program when the OS doesn't know how to fix it. But maybe there should be some kind of "exception handling" at that level, but it'd be OS dependent? Where cooperation between my source code, the compiler and the OS can make a decision on what to do. On the other hand, the other side of the story is that segfault should NEVER happen, besides it's more secure if it shuts down. – The Quantum Physicist Nov 04 '18 at 01:22
  • FWIW, when implementing "this functionality absolutely positively must continue working no matter what" scenarios, I have a parent process whose only job is to watch the child process, and if the child process crashes or exits, to spawn a new one to replace it. (Then all the actual functionality/logic goes into the child process, which hopefully never crashes, but if/when it ever does, its replacement will be up and running within a few hundred milliseconds) – Jeremy Friesner Nov 04 '18 at 01:25
  • @user2079303 all true, I could have worded that better. The only realistic chance you have is to do the information gathering in the signal handler, and options are extremely limited. After that you're at the whims of the gods. – user4581301 Nov 04 '18 at 01:26