0

Or in another words: How do you throw a kernel fault through to a C++ exception?

Because C++ is able to throw most of the programming errors as an exception. But why not also the divide-by-zero fault? The segmentation fault? And the other kernel faults?

I understand how those faults are raised in kernel and handled by kernel. I also understand how an exception is created and handled in C++ with aid from the compiler. How do you see the dots between the two can be connected? Are there any solid work with this regard?

Thanks in advance for any ideas or hints.

Edit in response to possible-duplicate flag: As a similar question How to catch segmentation already asked about the capture part of a segv, the recovery is still missing. Moreover I'm looking for a systematic approach to recover from all kinds of kernel exceptions, not just the segv.

Edit again: I have explained why this question is different than the other question. Still 5 people voted to close.

Community
  • 1
  • 1
minghua
  • 5,981
  • 6
  • 45
  • 71
  • 3
    It depends on your platform. On some Unixes, returning from some signals (including SIGSEGV, SIGFPE, and SIGILL) causes undefined behaviour. – Brian Bi Aug 30 '14 at 04:50
  • Right, I thought about signals but forgot to mention it when writing up the question. Specifically I have not figured out how to convert a signal into an C++ throwable exception. If you can convert sigsegv it would solve half the problem. Still I'd like to be able to throw all the kernel faults if the fault is caused by your program. – minghua Aug 30 '14 at 04:53
  • 1
    @Brian: Throwing an exception, or using `longjmp`, doesn't count as the forbidden returning from a signal handler. – Ben Voigt Aug 30 '14 at 04:56
  • 1
    In Windows&VC++, you can [translate SEH exception into C++ exception.](http://msdn.microsoft.com/en-us/library/de5awhsw.aspx) – ikh Aug 30 '14 at 05:04
  • @ikh: thanks that means it it doable. I can't wait to see a complete solution on Linux. – minghua Aug 30 '14 at 05:16
  • @minghua check this one http://stackoverflow.com/questions/5860999/why-doesnt-my-signal-handler-which-throws-an-exception-trigger-more-than-once – Iłya Bursov Aug 30 '14 at 06:29
  • 1
    Consider the `SIGSEGV`, which has corrupted your heap, stack and critical *libc/libstdc++* variables. There are very few things that will work in this situation. – artless noise Aug 31 '14 at 00:44
  • @artless: That's just one case that needs to be sorted out. How about divided by zero? In that case it does not corrupt anything. – minghua Sep 01 '14 at 06:55
  • 1
    On Linux you cannot do that reliably. – Basile Starynkevitch Sep 01 '14 at 07:35
  • 3
    You cannot do this reliably ever. While you *can* cause a C++ exception to be thrown on both systems, it will not have the standard C++ semantics. In particular it may not rewind the stack properly in the presence of aggressive optimizations. – avakar Sep 01 '14 at 07:38
  • 1
    ... in other words, don't do it. Use system-specific handlers (SEH or signals) and only in functions that require no cleanup. – avakar Sep 01 '14 at 07:39

1 Answers1

2

"kernel fault" is not a standard term. There are "kernel panic" events. Those are catastrophic failures in the kernel itself caused by bugs in the kernel code. Your application has nothing to do with them.

If we are talking about user space programs written in C++, signals such as SIGSEGV (but not signals such as SIGUSR1) are events caused by undefined behaviour in C++ code. It may or may not be handled by the kernel, depending on what kind of OS and what kind of program you have. Either way it is not called a kernel fault. As far as C++ is concerned, this is the end of the world. You never try to handle such signals, except probably to attempt to print a farewell message and exit. There is no recovery.

In some very rare and implementation-dependent cases catching signals like SIGSEGV may make sense, but a systematic approach does not and cannot exist.

Edit in response to possible-duplicate flag: As a similar question How to catch segmentation already asked about the capture part of a segv, the recovery is still missing. Moreover I'm looking for a systematic approach to recover from all kinds of kernel exceptions, not just the segv.

Recovery is not possible in a generic way, therefore the question is similar to,

At first glance this seems possible. However, many of the exceptions can indicate a corrupt environment where there is no possible way to recover, yet alone resume normal execution.

Community
  • 1
  • 1
n. m. could be an AI
  • 112,515
  • 14
  • 128
  • 243