Unix Programming - Catch SIGSEGV and longjmp(3) to Safety?

Author

Catch SIGSEGV and longjmp(3) to Safety?

Michael B Allen

2005-06-25, 7:48 am

I have always thought of SIGSEGV as the Kiss of Death and that one
should just let a faulting process exit. But is it possible/reasonable
to try to recover from a memory access fault by trying to longjmp out
of the signal handler for SIGSEGV? Or does the process always exit after
SIGSEGV regardless?

I have a single process doing I/O on a potentially large number of
sockets. Unlike the traditional Unix 1 to 1 process per client model,
if this process dies all clients die, not just the client that
caused the fault.

Hopefully the server would never need to dodge a fault but if the
alternative is to simply exit it might be worth a shot to try to
recover.

What do you think?

Mike

Maxim Yegorushkin

2005-06-25, 7:48 am

On Sat, 25 Jun 2005 12:37:35 +0400, Michael B Allen <mba2000@ioplex.com>
wrote:

> I have always thought of SIGSEGV as the Kiss of Death and that one
> should just let a faulting process exit. But is it possible/reasonable
> to try to recover from a memory access fault by trying to longjmp out
> of the signal handler for SIGSEGV? Or does the process always exit after
> SIGSEGV regardless?

How would you know what caused SIGSEGV? How would you decide how much
damage have already been made, what have been corrupted and what not, and
whether it's possible to recover? You may only have an offending
instruction address and that's it.

--
Maxim Yegorushkin
<firstname.lastname@gmail.com>

Paul Pluzhnikov

2005-06-25, 5:50 pm

Michael B Allen <mba2000@ioplex.com> writes:

> I have always thought of SIGSEGV as the Kiss of Death and that one
> should just let a faulting process exit.

One should let the process die with the signal (which is different
from exiting).

> But is it possible/reasonable
> to try to recover from a memory access fault by trying to longjmp out
> of the signal handler for SIGSEGV?

Possible: yes, reasonable: yes under _very_ limited conditions.

One example: there OO-databases which mmap/munmap various parts of
data. I've been told, that the client code simply accesses that
data trough regular pointers. If the data has not been mapped in,
the client code generates an *expected* SIGSEGV, to which the
OODB code reacts by mmap()ing the missing page and restarting the
client (i.e. OODB install SIGSEGV handler, which simply returns
after having "fixed" the problem).

> Hopefully the server would never need to dodge a fault but if the
> alternative is to simply exit it might be worth a shot to try to
> recover.

You can't reliably recover from *unexpected* SIGSEGV. If you try,
you are quite likely to end up with a deadlocked server, or server
providing garbage answers to the clients.

Which would you rather have: a client receiving "server closed
connection" or a client receiving "garbage" with no indication that
something may have gone wrong on the server side?

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

Maxim Yegorushkin

2005-06-25, 5:50 pm

On Sat, 25 Jun 2005 19:39:00 +0400, Paul Pluzhnikov
<ppluzhnikov-nsp@charter.net> wrote:

[]

> One example: there OO-databases which mmap/munmap various parts of
> data. I've been told, that the client code simply accesses that
> data trough regular pointers. If the data has not been mapped in,
> the client code generates an *expected* SIGSEGV, to which the
> OODB code reacts by mmap()ing the missing page and restarting the
> client (i.e. OODB install SIGSEGV handler, which simply returns
> after having "fixed" the problem).

How do you know that the client code have touched unmapped memory rather
that it has overflowed its stack?

--
Maxim Yegorushkin
<firstname.lastname@gmail.com>

Paul Pluzhnikov

2005-06-25, 5:50 pm

"Maxim Yegorushkin" <firstname.lastname@gmail.com> writes:

> On Sat, 25 Jun 2005 19:39:00 +0400, Paul Pluzhnikov
>
>
> How do you know

I don't. I didn't write the OODB, and my knowledge of its operation
comes from reading a white-paper about it (and that was several
years ago).

> that the client code have touched unmapped memory
> rather that it has overflowed its stack?

The faulting address is available to the signal handler.
The OODB code can tell whether that address corresponds to a "window"
into the VM that it manages, to stack, or to something else.

I don't know how well (if at all) this scheme works with threads
(thread stacks could appear just about anywhere an mmap()ed region
may appear).

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

Artie Gold

2005-06-26, 2:48 am

Paul Pluzhnikov wrote:
> "Maxim Yegorushkin" <firstname.lastname@gmail.com> writes:
>
>
> I don't. I didn't write the OODB, and my knowledge of its operation
> comes from reading a white-paper about it (and that was several
> years ago).
>
>
> The faulting address is available to the signal handler.
> The OODB code can tell whether that address corresponds to a "window"
> into the VM that it manages, to stack, or to something else.
>
> I don't know how well (if at all) this scheme works with threads
> (thread stacks could appear just about anywhere an mmap()ed region
> may appear).
>

It's pretty much orthogonal to threads (modulo appropriate
synchronization); effectively you can look at it as a virtualization of
virtual memory. But you *do* have to know what your virtualized VM looks
like.

Googling for `pointer swizzling at page fault time' will provide a
series of references. (ISTR a commercial persistent object system that
used the same basic mechanism -- but any details completely escape me at
the moment).

Also note, longjmp() was not part of this mechanism; rather, pages were
remapped as needed, `fixing' the SIGSEGV.

HTH,
--ag

--
Artie Gold -- Austin, Texas
http://it-matters.blogspot.com (new post 12/5)
http://www.cafepress.com/goldsays