What are non-catchable exceptions

Question

gcc (GCC) 4.5.3

GNU gdb (GDB) 7.5.50.20130309-cvs (cygwin-special)

Netbeans 7.3

I have some trouble catching a SIGSEGV, Segment Fault Exception, in my code. A try-catch does not catch it (code below). Is this a non-catchable exception? Is there any way to catch it? (And of Course) What have I done wrong?

art

string SlipStringOp::dump(const SlipCell& X) const {
   stringstream pretty;
   PTR ptr = *getPtr(X);

   pretty << "[string   ] " << dumpLink(X)  << " = " 
           << setfill('0') << setw(8) << hex << ptr
           << " -> ";
   try {
      pretty << ptr->dump();
   } catch(exception& e) {
      pretty << e.what();
      postError(SlipErr::E3023, "SlipStringOp::dump", "", "Deletion of cell deleted the pointer.");
   } catch(...) {
      postError(SlipErr::E3023, "SlipStringOp::dump", "", "Deletion of cell deleted the pointer.");   
   }
   return pretty.str();
}; // string SlipStringOp::dump(const SlipCell& X) const

If you really want to know what you have done wrong, start by providing a [SSCCE](http://meta.stackexchange.com/questions/22754/) — Nemo, Mar 15 '13 at 23:37
Yes you can catch a signal, but you should not catch this one. It represents a bug in your code that you should fix instead. — Nemo, Mar 15 '13 at 23:37
There is a way ... but If I were you , I'd use handlers see http://stackoverflow.com/questions/4747934/c-catch-a-divide-by-zero-error — Shmil The Cat, Mar 15 '13 at 23:38
Sigh. I know what happened. The object pointed to by pointer has gone the way of the wooly mammoth. As a result when I execute ptr->dump() I don't have a viable object, and so, a segment fault signal is generated (thanks for clarifying that this is not an exception). And so, a fault is generated. I would like to gracefully go where no one h as gone before. Any way to do this? — lostbits, Mar 15 '13 at 23:40
@ArthurSchwarez Fix the bug. You shouldn't be dereferencing an invalid pointer. — Joseph Mansfield, Mar 15 '13 at 23:46
man signal: http://linux.die.net/man/2/signal That will tell you what you need to know. — Edward Strange, Mar 15 '13 at 23:37
Crazy Eddie: Your the man. What is going on under the covers is that I have a list processor in which some cells contain pointers to wrappers. The cells are of uniform size are persistent, either being actively used or available for future. When availabe for use sometimes the pointers are deleted. Under some circumstances I want to dump data in the available space list. It would be convenient if I didn't need to create a mechanism to identify active pointers for inactive pointers. But now that I know the answer I will modify my code or construct a signal handler, whichever is easier. Thanks. — lostbits, Mar 15 '13 at 23:50

score 7 · Answer 1 · answered Mar 15 '13 at 23:42

SIGSEGV is not an exception; it's a signal. Accessing an invalid memory address is known as a segmentation fault. When your program does this, the operating system will send your process the SIGSEGV signal. The default handler for this signal will immediately terminate the process.

You can intercept a signal, but this is not a signal you should be handling yourself. If your program is causing a segmentation fault, it has a bug, no doubt about it.

If you've isolated the segmentation fault to the pretty << ptr->dump(); line, I would guess that the problem is probably that ptr isn't pointing to a valid object. Alternatively, the dump function is doing something bad.

Do not attempt to fix this by handling the signal. Do fix this by making sure your program doesn't cause a segmentation fault.

score 1 · Answer 2 · answered Mar 15 '13 at 23:45

1

There are two questions here. Firstly, why are you getting a SIGSEGV? There probably isn't enough code here for us to tell, but is your call to ptr->dump() calling the same function recursively? IF so, you have infinite recursion, and that is causing the seg fault.

Second question is how you trap the signal, and that's been answered by previous responders.

answered Mar 15 '13 at 23:45

Muscles

471
4
12

The SIGSEGV is being raised because ptr points to a deleted object. I was hoping to make handling automatic by catching the signal, posting an appropriate diagnostic message, and exiting the program. But I can (probably) just fix the problem so it doesn't happen 'normally' but then the software user will be perplexed when it does happen. Oh well. Another day, another adventure, another ad hoc error handler. – lostbits Mar 16 '13 at 04:43

score 0 · Answer 3 · answered Mar 16 '13 at 00:22

You throw an exception with a throw expression. You catch an exception in a catch clause.

You raise a signal by calling raise. You handle a signal by installing a handler before the exception is raised.

Any other actions and interactions are system-specific (i.e., not portable).

What are non-catchable exceptions

3 Answers3