Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)
-   -   signal() anomaly (http://www.velocityreviews.com/forums/t948889-signal-anomaly.html)

hip cat 07-31-2012 08:13 PM

signal() anomaly
 
What up

I've used signal to set SIGSEGV to SIG_IGN. But when I later dereference
a null pointer my program still crashes out with segfault SIGSEGV. What
gives?

Communicate laterz ++

Eric Sosman 07-31-2012 08:35 PM

Re: signal() anomaly
 
On 7/31/2012 4:13 PM, hip cat wrote:
> What up
>
> I've used signal to set SIGSEGV to SIG_IGN. But when I later dereference
> a null pointer my program still crashes out with segfault SIGSEGV. What
> gives?


Did you check that the signal() call succeeded? That is,
was the returned value SIG_ERR or something else?

On POSIX systems, ignoring SIGSEGV produces undefined behavior.
The C Standard isn't quite so clear to me: It's U.B. if a signal
handler for SIGSEGV returns (7.14.1.1p3), but SIG_IGN is not a
"signal handler" under the definition of 7.14.1.1p2.

--
Eric Sosman
esosman@ieee-dot-org.invalid

Edward A. Falk 07-31-2012 10:12 PM

Re: signal() anomaly
 
In article <jv9e9e$bj3$1@speranza.aioe.org>,
hip cat <nospam@nospam.com> wrote:
>What up
>
>I've used signal to set SIGSEGV to SIG_IGN. But when I later dereference
>a null pointer my program still crashes out with segfault SIGSEGV. What
>gives?


I am amused and curious -- what did you *want* to happen on a null
pointer dereference?

--
-Ed Falk, falk@despams.r.us.com
http://thespamdiaries.blogspot.com/

Nobody 08-01-2012 05:06 PM

Re: signal() anomaly
 
On Tue, 31 Jul 2012 20:13:34 +0000, hip cat wrote:

> I've used signal to set SIGSEGV to SIG_IGN. But when I later dereference a
> null pointer my program still crashes out with segfault SIGSEGV. What
> gives?


POSIX-2008 ยง2.4.3 says:

SIG_IGN

Ignore signal.

Delivery of the signal shall have no effect on the process. The behavior
of a process is undefined after it ignores a SIGFPE, SIGILL, SIGSEGV, or
SIGBUS signal that was not generated by kill(), sigqueue(), or raise().

http://pubs.opengroup.org/onlinepubs...V2_chap02.html

And also:

The behavior of a process is undefined after it returns normally from a
signal-catching function for a SIGBUS, SIGFPE, SIGILL, or SIGSEGV signal
that was not generated by kill(), sigqueue(), or raise().


hip cat 08-01-2012 06:58 PM

Re: signal() anomaly
 
On Tue, 31 Jul 2012 22:12:41 +0000, Edward A. Falk wrote:
> In article <jv9e9e$bj3$1@speranza.aioe.org>, hip cat
> <nospam@nospam.com> wrote:
>>What up
>>
>>I've used signal to set SIGSEGV to SIG_IGN. But when I later dereference
>>a null pointer my program still crashes out with segfault SIGSEGV. What
>>gives?

>
> I am amused and curious -- what did you *want* to happen on a null
> pointer dereference?


Word Ed,

My code has a certain pointer that sometimes unexpectedly becomes null.
It would be a lot of work to find every place the pointer gets
dereferenced and add a null check. So I want to just ignore it by
catching the signal.

Communicate laterz ++

hip cat 08-01-2012 06:59 PM

Re: signal() anomaly
 
On Tue, 31 Jul 2012 16:35:41 -0400, Eric Sosman wrote:

> On 7/31/2012 4:13 PM, hip cat wrote:
>> What up
>>
>> I've used signal to set SIGSEGV to SIG_IGN. But when I later
>> dereference a null pointer my program still crashes out with segfault
>> SIGSEGV. What gives?

>
> Did you check that the signal() call succeeded? That is,
> was the returned value SIG_ERR or something else?
>
> On POSIX systems, ignoring SIGSEGV produces undefined behavior.
> The C Standard isn't quite so clear to me: It's U.B. if a signal handler
> for SIGSEGV returns (7.14.1.1p3), but SIG_IGN is not a "signal handler"
> under the definition of 7.14.1.1p2.


Word Eric,

The return value is 0.

Communicate laterz ++

James Kuyper 08-01-2012 07:33 PM

Re: signal() anomaly
 
On 08/01/2012 02:58 PM, hip cat wrote:
> On Tue, 31 Jul 2012 22:12:41 +0000, Edward A. Falk wrote:
>> In article <jv9e9e$bj3$1@speranza.aioe.org>, hip cat
>> <nospam@nospam.com> wrote:
>>> What up
>>>
>>> I've used signal to set SIGSEGV to SIG_IGN. But when I later dereference
>>> a null pointer my program still crashes out with segfault SIGSEGV. What
>>> gives?

>>
>> I am amused and curious -- what did you *want* to happen on a null
>> pointer dereference?

>
> Word Ed,
>
> My code has a certain pointer that sometimes unexpectedly becomes null.


Rather than trying to make this work, you should be trying to find out
why the pointer is becoming null.

> It would be a lot of work to find every place the pointer gets
> dereferenced and add a null check. So I want to just ignore it by
> catching the signal.


Well, as "Nobody" has already pointed out, that's not an option. Using
SIG_IGN for this has undefined behavior. So does registering your own
SIGSEGV "handler" that doesn't bother to actually do anything, and
simply returns. Therefore, you're going to have to either insert the
null checks, or let the program abort() - your choice.

Angel 08-01-2012 07:41 PM

Re: signal() anomaly
 
On 2012-08-01, hip cat <nospam@nospam.com> wrote:
>
> My code has a certain pointer that sometimes unexpectedly becomes null.
> It would be a lot of work to find every place the pointer gets
> dereferenced and add a null check. So I want to just ignore it by
> catching the signal.


And you expect the program will work correctly and produce meaningful
output if you ignore what is normally a very fatal error condition?

I do hope you're not writing code that will be used in any important
production environment.


--
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c

Nick Bowler 08-01-2012 08:14 PM

Re: signal() anomaly
 
On Tue, 31 Jul 2012 16:35:41 -0400, Eric Sosman wrote:

> On 7/31/2012 4:13 PM, hip cat wrote:
>> What up
>>
>> I've used signal to set SIGSEGV to SIG_IGN. But when I later dereference
>> a null pointer my program still crashes out with segfault SIGSEGV. What
>> gives?

>
> Did you check that the signal() call succeeded? That is,
> was the returned value SIG_ERR or something else?
>
> On POSIX systems, ignoring SIGSEGV produces undefined behavior.


POSIX is a bit more specific than that. But regardless...

> The C Standard isn't quite so clear to me: It's U.B. if a signal
> handler for SIGSEGV returns (7.14.1.1p3), but SIG_IGN is not a
> "signal handler" under the definition of 7.14.1.1p2.


....the C standard doesn't need to be any more explicit on this matter.
The behaviour is undefined because the program has dereferenced an
invalid (null) pointer. The handling of SIGSEGV is irrelevant.

Eric Sosman 08-01-2012 08:33 PM

Re: signal() anomaly
 
On 8/1/2012 2:58 PM, hip cat wrote:
> On Tue, 31 Jul 2012 22:12:41 +0000, Edward A. Falk wrote:
>> In article <jv9e9e$bj3$1@speranza.aioe.org>, hip cat
>> <nospam@nospam.com> wrote:
>>> What up
>>>
>>> I've used signal to set SIGSEGV to SIG_IGN. But when I later dereference
>>> a null pointer my program still crashes out with segfault SIGSEGV. What
>>> gives?

>>
>> I am amused and curious -- what did you *want* to happen on a null
>> pointer dereference?

>
> Word Ed,
>
> My code has a certain pointer that sometimes unexpectedly becomes null.
> It would be a lot of work to find every place the pointer gets
> dereferenced and add a null check. So I want to just ignore it by
> catching the signal.


That's not going to work. As I wrote earlier, the C Standard
doesn't seem entirely clear on this matter, but the fact that you
get undefined behavior if a SIGSEGV handler returns suggests that
there's no way to recover. That's explicit under POSIX: If you
ignore SIGSEGV, there's no telling what might happen.

But, back to your problem: What do you *expect* should happen
if you could somehow continue after dereferencing your null pointer?
Somewhere, your program did `*ptr = 42' and ptr was null: Where do
expect the 42 to go? Or somewhere you did `x = *ptr' and ptr was
null: What value should x now have? Or, here's a good one:

for (ptr = accidentally_null; *ptr != 0; ++ptr) {
putchar(*ptr);
}

How many times should the loop execute, what output should it
produce, and what value should ptr have when (if) it finishes?

SIGSEGV means your car's motor has thrown a rod. You can't
just ignore the broken engine and keep on driving.

--
Eric Sosman
esosman@ieee-dot-org.invalid


All times are GMT. The time now is 01:31 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.