Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > signal() anomaly

Reply
Thread Tools

signal() anomaly

 
 
hip cat
Guest
Posts: n/a
 
      07-31-2012
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 ++
 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      07-31-2012
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
http://www.velocityreviews.com/forums/(E-Mail Removed)d
 
Reply With Quote
 
 
 
 
Edward A. Falk
Guest
Posts: n/a
 
      07-31-2012
In article <jv9e9e$bj3$(E-Mail Removed)>,
hip cat <(E-Mail Removed)> 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, (E-Mail Removed)
http://thespamdiaries.blogspot.com/
 
Reply With Quote
 
Nobody
Guest
Posts: n/a
 
      08-01-2012
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().

 
Reply With Quote
 
hip cat
Guest
Posts: n/a
 
      08-01-2012
On Tue, 31 Jul 2012 22:12:41 +0000, Edward A. Falk wrote:
> In article <jv9e9e$bj3$(E-Mail Removed)>, hip cat
> <(E-Mail Removed)> 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 ++
 
Reply With Quote
 
hip cat
Guest
Posts: n/a
 
      08-01-2012
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 ++
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      08-01-2012
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$(E-Mail Removed)>, hip cat
>> <(E-Mail Removed)> 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.
 
Reply With Quote
 
Angel
Guest
Posts: n/a
 
      08-01-2012
On 2012-08-01, hip cat <(E-Mail Removed)> 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
 
Reply With Quote
 
Nick Bowler
Guest
Posts: n/a
 
      08-01-2012
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.
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      08-01-2012
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$(E-Mail Removed)>, hip cat
>> <(E-Mail Removed)> 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
(E-Mail Removed)d
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Weird anomaly when printing datagrids? Dan ASP .Net 0 02-01-2006 03:08 PM
What's this 2.0 compilation anomaly? clintonG ASP .Net 16 01-05-2006 02:58 AM
Cisco 2650 Nat anomaly nashweber@gmail.com Cisco 0 10-13-2005 12:58 AM
Vlan Hopping Anomaly Jos_Cit Cisco 15 08-15-2005 05:35 AM
Cookie Anomaly Ash ASP .Net 0 02-26-2004 02:46 PM



Advertisments