«

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

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
d

In article <jv9e9e$bj3$>,
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?

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

--
-Ed Falk,
http://thespamdiaries.blogspot.com/

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

On Tue, 31 Jul 2012 22:12:41 +0000, Edward A. Falk wrote:
> In article <jv9e9e$bj3$>, 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?
>
> 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 ++

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

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$>, 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?
>>
>> 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.

On 2012-08-01, hip cat <> 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

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.

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$>, 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?
>>
>> 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
d