Regarding SIGSEGV

Regarding SIGSEGV

[Sri Ram Vemulpali]

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.

Regarding SIGSEGV

[Mulyadi Santosa]

On Wed, Feb 2, 2011 at 14:08, 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. 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.
Perhaps phrack article in issue 58 file 03 could help you :) In case
you're lazy, here's the URL:

http://www.phrack.org/issues.html?issue=58&id=3#article

look for the section:
"Subject: Getting rid of SIGSEGV - for fun but not for profit."

A bit hackish, but I think it is worth to read. Enjoy :)

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

Regarding SIGSEGV

[Sri Ram Vemulpali]

Hi,

  Thanks for introducing me to 'phrack' magazine. I read the article.
It seems its kind of hack, which might leave process in unexpected
state. I am more of looking at which thread in the task generated the
SIGSEGV. This article is very helpful, but some more information the
direction would do for me. Thanks in advance

--Sri

On Wed, Feb 2, 2011 at 2:16 AM, Mulyadi Santosa
<mulyadi.santosa@gmail.com> wrote:
> On Wed, Feb 2, 2011 at 14:08, 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. 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.
> Perhaps phrack article in issue 58 file 03 could help you :) In case
> you're lazy, here's the URL:
>
> http://www.phrack.org/issues.html?issue=58&id=3#article
>
> look for the section:
> "Subject: Getting rid of SIGSEGV - for fun but not for profit."
>
> A bit hackish, but I think it is worth to read. Enjoy :)
>
> --
> regards,
>
> Mulyadi Santosa
> Freelance Linux trainer and consultant
>
> blog: the-hydra.blogspot.com
> training: mulyaditraining.blogspot.com
>



-- 
Regards,
Sri.

Regarding SIGSEGV

[Guillaume Knispel]

On Wed, 2 Feb 2011 16:11:41 -0500
Sri Ram Vemulpali <sri.ram.gmu06@gmail.com> wrote:

>   Thanks for introducing me to 'phrack' magazine. I read the article.
> It seems its kind of hack, which might leave process in unexpected
> state. I am more of looking at which thread in the task generated the
> SIGSEGV. This article is very helpful, but some more information the
> direction would do for me. Thanks in advance

If you don't kill the whole process on SIGSEGV, you don't have any
warranty that you won't encounter further unexpected behavior anyway
in the general case -- and achieving hypothetical requirements to
partly ignore SIGSEGV in a way that would still allow to have fully
defined behavior after the event would probably be far more harder to
achieve than doing a clean design. And just to be extra clear: stopping
thread that generated the SIGSEGV is not going to get you a completely
sane state.

Just use multiple processes or be prepared to introduce even more
problems than those supposed to be fixed by what you are trying to do
(which won't even fix them properly anyway...)

-- 
Guillaume Knispel