| Topic: |
DEVELOP > c-Plus-Plus |
| User: |
"Vasileios Zografos" |
| Date: |
30 Jun 2003 12:34:09 PM |
| Object: |
Re: segmentation fault exception handling |
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 ;)
.
|
|
| User: "Vasileios Zografos" |
|
| Title: Re: segmentation fault exception handling |
30 Jun 2003 05:51:01 PM |
|
|
As hard as I try, I really can't believe you... sorry ;-))
I said "trust" not "believe" :D.
You cant get people to believe in anything these days
.
|
|
|
| User: "Bob Bell" |
|
| Title: Re: segmentation fault exception handling |
30 Jun 2003 08:33:39 PM |
|
|
Vasileios Zografos <vzografos@bcs.org.uk> wrote in message news:<bdqesn$dbc$1@news6.svr.pol.co.uk>...
As hard as I try, I really can't believe you... sorry ;-))
I said "trust" not "believe" :D.
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
.
|
|
|
|
|
| User: "Shane Beasley" |
|
| Title: Re: segmentation fault exception handling |
30 Jun 2003 07:50:28 PM |
|
|
Vasileios Zografos <vzografos@bcs.org.uk> wrote in message news:<bdpsaj$77o$1@newsg4.svr.pol.co.uk>...
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
.
|
|
|
| User: "Pete Becker" |
|
| Title: Re: segmentation fault exception handling |
01 Jul 2003 09:10:52 AM |
|
|
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)
.
|
|
|
|
|
| User: "Rolf Magnus" |
|
| Title: Re: segmentation fault exception handling |
01 Jul 2003 06:31:15 AM |
|
|
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 :-)
.
|
|
|
|
|
Related Articles |
|
|
