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.

[joe@invalid.address]

[email]iryna7@yahoo.com[/email] (jason) writes:

> 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
--
There are 10 kinds of engineers, those who understand binary and those
who don't.

[David Schwartz]

"jason" <iryna7@yahoo.com> wrote in message
news:7247d407.0307211636.386f8d8e@posting.google.c om...

> 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]

On 21 Jul 2003 17:36:00 -0700, jason <iryna7@yahoo.com> wrote:

> 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"
<davids@webmaster.com> wrote:

>
>"Marc Rochkind" <rochkind@basepath.com> wrote in message
>news:oprsoyjezvojfyi9@den.news.speakeasy.net...
>

>> 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]

"Michael Kerrisk" <michael.kerrisk@freenet.de> wrote in message
news:r5kphvok3ucgkmr4l0evcr7j99474kophb@4ax.com...

> > 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.

> > 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]

On Mon, 21 Jul 2003 21:15:43 -0700, David Schwartz <davids@webmaster.com>
wrote:

>
> "Marc Rochkind" <rochkind@basepath.com> wrote in message
> news:oprsoyjezvojfyi9@den.news.speakeasy.net...
>

>> 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