Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Re: segmentation fault exception handling

Reply
Thread Tools

Re: segmentation fault exception handling

 
 
Vasileios Zografos
Guest
Posts: n/a
 
      06-30-2003
So, in standard c++ there is no way you can catch a seg. fault?

is there any good way of checking if pointer/variable is initialized or
not? (apart from using if (this==0) that someone suggested is not very
good)?


V.Z.

P.S.
The reason why the variables sometime stay unitialised comes from a
geometrical problem and is nothing much I can do about it. Trust me on
this

 
Reply With Quote
 
 
 
 
Vasileios Zografos
Guest
Posts: n/a
 
      06-30-2003
> As hard as I try, I really can't believe you... sorry )
>


I said "trust" not "believe" .
You cant get people to believe in anything these days



 
Reply With Quote
 
 
 
 
Shane Beasley
Guest
Posts: n/a
 
      07-01-2003
Vasileios Zografos <(E-Mail Removed)> wrote in message news:<bdpsaj$77o$(E-Mail Removed)>...

> So, in standard c++ there is no way you can catch a seg. fault?


ISO C (and thus also C++) allows you to catch and handle the SIGSEGV
signal (SEGV is short for "segmentation violation"). However, the only
sane reason to do so is to save work before aborting the program; the
behavior of a program which ignores SIGSEGV (i.e., one which continues
running after SIGSEGV) is undefined. For example:

#include <iostream>
#include <csignal>
#include <cstdlib>

void say_hi (int) {
// prevent infinite recursion if say_hi() causes another segfault
std::signal(SIGSEGV, SIG_DFL);

std::cout << "hi" << std::endl;
std::abort();
}

int main () { std::signal(SIGSEGV, say_hi); int *p = 0; *p = 0; }

See <http://www.dinkumware.com/htm_cpl/signal.html> for info on
signals.

That said, segfaults come from programming errors. Fix them; don't
ignore them.

> is there any good way of checking if pointer/variable is initialized or
> not? (apart from using if (this==0) that someone suggested is not very
> good)?


Make sure it's always initialized; then you don't have to check.

- Shane
 
Reply With Quote
 
Bob Bell
Guest
Posts: n/a
 
      07-01-2003
Vasileios Zografos <(E-Mail Removed)> wrote in message news:<bdqesn$dbc$(E-Mail Removed)>...
> > As hard as I try, I really can't believe you... sorry )
> >

>
> I said "trust" not "believe" .
> You cant get people to believe in anything these days


Even so, this "sometimes it's uninitialized" thing is the source of
your problem. C++ goes to great lengths to guarantee that objects are
constructed properly. Perhaps you can say a little more about why your
problem circumvents these guarantees. At the very least, it would
satisfy the curiosity of the readers of this thread.

As far at catching segmentation faults, C++ doesn't even recognize
"segmentation fault" in the first place, much less define and
exception for it. The only things standard C++ recognizes as an
exception is something that originates with a throw statement.
Segmentation faults don't do this.

Another way to look at it is that exceptions are meant for conditions
to which your program can meaningfully respond. A segmentation fault
is likely to be something which can't be handled meaningfully, except
in very rare, controlled circumstances, and even then it's really a
matter of luck if it works. Thus, exceptions are really the wrong way
to deal with segmentation faults.

Bob Bell
 
Reply With Quote
 
Rolf Magnus
Guest
Posts: n/a
 
      07-01-2003
Vasileios Zografos wrote:

> So, in standard c++ there is no way you can catch a seg. fault?


Right. Again, note that your program is in an indeterminate state after
a segfault. The best thing you might be able to do to react to it would
be to try write unsaved data to disk (it might work or it might not)
and then immediately terminate.
A practical example of what could happen:
If e.g. you write beyond the bounds of an array, some of the OSs (or
standard library's) memory management data could be overwritten,
resulting in a segfault on the next allocation. Then your program can't
allocate or deallocate any memory, and if it tries, it could easily
corrupt other parts of the memory or segfault again.
A segfault is not something that is part of a regular program execution.
It means your program crashed due to an invalid access, and trying to
recover after a crash is not likely to work.

> is there any good way of checking if pointer/variable is initialized
> or not? (apart from using if (this==0) that someone suggested is not
> very good)?
>
>
> V.Z.
>
> P.S.
> The reason why the variables sometime stay unitialised comes from a
> geometrical problem and is nothing much I can do about it. Trust me on
> this


I won't trust you on this. Dereferencing uninitialized pointers is _not_
a geometrical problem, no matter what your program is supposed to do.
It's a logical problem in your program code. Now trust me


 
Reply With Quote
 
Pete Becker
Guest
Posts: n/a
 
      07-01-2003
Shane Beasley wrote:
>
> Q: Why is <signal.h> in ISO C anyway, then, if it's not portably useful?
>


Portable code can handle a signal that's raised by a call to raise.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
like to know why it is segmentation fault on simple throw-exception program eric C++ 9 06-02-2011 06:20 PM
Segmentation fault at raise exception. O01eg Oleg Ruby 6 04-24-2010 06:33 PM
signal handling and (structured) exception handling Peter C++ 34 10-17-2009 10:03 AM
SoapExtension for Global Exception handling; but prevent exception from propagating!! VSK ASP .Net Web Services 0 07-29-2003 05:39 PM
Re: segmentation fault exception handling Ivan Vecerina C++ 0 06-29-2003 10:56 PM



Advertisments