Re: segmentation fault exception handling

Discussion in 'C++' started by Vasileios Zografos, Jun 30, 2003.

  1. 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 ;)
     
    Vasileios Zografos, Jun 30, 2003
    #1
    1. Advertising

  2. > 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
     
    Vasileios Zografos, Jun 30, 2003
    #2
    1. Advertising

  3. Vasileios Zografos <> wrote in message news:<bdpsaj$77o$>...

    > 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
     
    Shane Beasley, Jul 1, 2003
    #3
  4. Vasileios Zografos

    Bob Bell Guest

    Vasileios Zografos <> wrote in message news:<bdqesn$dbc$>...
    > > 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
     
    Bob Bell, Jul 1, 2003
    #4
  5. Vasileios Zografos

    Rolf Magnus Guest

    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 :)
     
    Rolf Magnus, Jul 1, 2003
    #5
  6. Vasileios Zografos

    Pete Becker Guest

    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)
     
    Pete Becker, Jul 1, 2003
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Alex Hunsley
    Replies:
    17
    Views:
    893
  2. Pud
    Replies:
    0
    Views:
    605
  3. Ivan Vecerina
    Replies:
    0
    Views:
    506
    Ivan Vecerina
    Jun 29, 2003
  4. eric
    Replies:
    9
    Views:
    835
    red floyd
    Jun 2, 2011
  5. O01eg Oleg
    Replies:
    6
    Views:
    247
    O01eg Oleg
    Apr 24, 2010
Loading...

Share This Page