How to ignore SIGSEGV signal

[jason]

hi there,

how to ignore SIGSEGV signal, 'cause i tried to handle or ignore that
signal on the code but it keep raised signal. is this one-shot signal?
any ideas.?

i used siganl or sigaction both of'em

cheers.

[j***@invalid.address]

Post by jason
how to ignore SIGSEGV signal, 'cause i tried to handle or ignore
that signal on the code but it keep raised signal. is this one-shot
signal? any ideas.?

Don't ignore that. Once you get SIGSEGV, nothing can be relied on in
your program. Just let it core dump, and figure out the problem from
there.

Joe

[David Schwartz]

Post by jason
hi there,
how to ignore SIGSEGV signal, 'cause i tried to handle or ignore that
signal on the code but it keep raised signal. is this one-shot signal?
any ideas.?
i used siganl or sigaction both of'em

I'm puzzled why you'd want to ignore a SIGSEGV signal. If you could do
it, you would have changed nothing, so whatever generated the SIGSEGV would
just generate another one, which you'd also ignore, ad infinitum.

If your SIGSEGV handler can eliminate the cause of the SIGSEGV, you can
continue execution. But with no handler, you'd be in an infinite loop.

What are you trying to do?

DS

[Marc Rochkind]

Post by jason
hi there,
how to ignore SIGSEGV signal, 'cause i tried to handle or ignore that
signal on the code but it keep raised signal. is this one-shot signal?
any ideas.?
i used siganl or sigaction both of'em
cheers.

For this signal and a few others that can be generated by a fault detected
by hardware, if they are genuinely generated by a fault, as opposed to
being generated synthetically by, say, kill, a special rule applies: You
can catch them or ignore them, but one thing you can't do it execute the
instruction that follows the one that caused the fault. In other words,
returning from a signal handler or a direct SIG_IGN both result in program
termination.

--Marc

[Michael Kerrisk]

On Mon, 21 Jul 2003 21:15:43 -0700, "David Schwartz"

Post by Marc Rochkind
For this signal and a few others that can be generated by a fault detected
by hardware, if they are genuinely generated by a fault, as opposed to
being generated synthetically by, say, kill, a special rule applies: You
can catch them or ignore them, but one thing you can't do it execute the
instruction that follows the one that caused the fault. In other words,
returning from a signal handler or a direct SIG_IGN both result in program
termination.

Really? Even if you reset the signal handler?

I think it depends on the implementation. In some cases, if we return
from the handler, then the signal is again delivered, and so on...

My understanding about what's supposed to happen is that when you return
from the signal handler, it should resume executing exactly where it
stopped, thus generating another segmentation violation. This allows code to
'fix' the circumstances that caused the segmentation violation (if it can
and wants to) and then resume execution.

If one wants to continue execution, a more typical approach I
think would be to longjmp() somewhere else, thus side-stepping
the faulting instruction.

Obviously, that's not going to be portable.

Not necesarily unportable though - for example, if the SIGSEGV
is caused by a memory protection violation, we could use mprotect()
to repair the error and then return (though mprotect() isn't in
SUSv3's list of async-signal-safe funtions...).

Cheers,

Michael

[David Schwartz]

Post by Michael Kerrisk

My understanding about what's supposed to happen is that when you return
from the signal handler, it should resume executing exactly where it
stopped, thus generating another segmentation violation. This allows code to
'fix' the circumstances that caused the segmentation violation (if it can
and wants to) and then resume execution.

If one wants to continue execution, a more typical approach I
think would be to longjmp() somewhere else, thus side-stepping
the faulting instruction.

Unless one can repait the 'problem' by calling 'mmap' or 'mprotect' or
even by modifying the code.

Post by Michael Kerrisk

Obviously, that's not going to be portable.

Not necesarily unportable though - for example, if the SIGSEGV
is caused by a memory protection violation, we could use mprotect()
to repair the error and then return (though mprotect() isn't in
SUSv3's list of async-signal-safe funtions...).

You can even, unportably of course, build your own jmp_buf to jump past
the faulting instruction after doing whatever processing is required.

One typical application of this is optimizing spinlocks for UP machines
on x86. In the initial spinlock code, you specifically put an illegal
instruction where the LOCK prefix would go. In the SIGILL handler, you
replace the illegal instruction with either a LOCK prefix or a nop,
depending upon whether you're on a UP or SMP machine.

DS

[Marc Rochkind]

Post by Marc Rochkind
For this signal and a few others that can be generated by a fault detected
by hardware, if they are genuinely generated by a fault, as opposed to
being generated synthetically by, say, kill, a special rule applies: You
can catch them or ignore them, but one thing you can't do it execute the
instruction that follows the one that caused the fault. In other words,
returning from a signal handler or a direct SIG_IGN both result in program
termination.

Really? Even if you reset the signal handler?
My understanding about what's supposed to happen is that when you return
from the signal handler, it should resume executing exactly where it
stopped, thus generating another segmentation violation. This allows code
to
'fix' the circumstances that caused the segmentation violation (if it can
and wants to) and then resume execution.
Obviously, that's not going to be portable.
DS

I was overly specific... all the standard says is that the behavior is
undefined.

--Marc