* Regarding SIGSEGV
@ 2011-02-02 7:08 Sri Ram Vemulpali
2011-02-05 14:39 ` Corrado Zoccolo
0 siblings, 1 reply; 2+ messages in thread
From: Sri Ram Vemulpali @ 2011-02-02 7:08 UTC (permalink / raw)
To: Kernel-newbies, linux-kernel-mail
Hi all,
I know that when a thread in an application do invalid memory
reference, OS generates SIGSEGV(segmentation fault) signal and
terminates application. What if we handle this signal by defining a
signal handler to perform to terminate only the thread did invalid
memory reference. So, that the application will not be terminated.
Also, is there any way, we can find when SIGSEGV is generated to get
the invalid memory reference and thread id, who caused this fault. I
know debuggers are written in such fashion. Can anyone point me to
right direction. Thanks in advance.
--
Regards,
Sri.
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: Regarding SIGSEGV
2011-02-02 7:08 Regarding SIGSEGV Sri Ram Vemulpali
@ 2011-02-05 14:39 ` Corrado Zoccolo
0 siblings, 0 replies; 2+ messages in thread
From: Corrado Zoccolo @ 2011-02-05 14:39 UTC (permalink / raw)
To: Sri Ram Vemulpali; +Cc: Kernel-newbies, linux-kernel-mail
On Wed, Feb 2, 2011 at 8:08 AM, Sri Ram Vemulpali
<sri.ram.gmu06@gmail.com> wrote:
> Hi all,
>
> I know that when a thread in an application do invalid memory
> reference, OS generates SIGSEGV(segmentation fault) signal and
> terminates application. What if we handle this signal by defining a
> signal handler to perform to terminate only the thread did invalid
> memory reference.
The thread that performed an invalid memory reference might already
have corrupted vital data structures, so the application may not work
and/or produce incorrect results. In such cases is always better to
stop the whole process, to limit damage.
> So, that the application will not be terminated.
> Also, is there any way, we can find when SIGSEGV is generated to get
> the invalid memory reference and thread id, who caused this fault.
man sigaction.
If you use the
void (*sa_sigaction)(int, siginfo_t *, void *);
version of handler interceptor, you will get the siginfo_t with all
known information about who generated the signal.
Corrado
> I know debuggers are written in such fashion. Can anyone point me to
> right direction. Thanks in advance.
>
> --
> Regards,
> Sri.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
__________________________________________________________________________
dott. Corrado Zoccolo mailto:czoccolo@gmail.com
PhD - Department of Computer Science - University of Pisa, Italy
--------------------------------------------------------------------------
The self-confidence of a warrior is not the self-confidence of the average
man. The average man seeks certainty in the eyes of the onlooker and calls
that self-confidence. The warrior seeks impeccability in his own eyes and
calls that humbleness.
Tales of Power - C. Castaneda
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2011-02-05 14:39 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-02-02 7:08 Regarding SIGSEGV Sri Ram Vemulpali
2011-02-05 14:39 ` Corrado Zoccolo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®