Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #24032 > unrolled thread

signal() anomaly

Back to article view | Back to comp.lang.c

Contents

  signal() anomaly hip cat <nospam@nospam.com> - 2012-07-31 20:13 +0000
    Re: signal() anomaly Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-31 16:35 -0400
      Re: signal() anomaly hip cat <nospam@nospam.com> - 2012-08-01 18:59 +0000
      Re: signal() anomaly Nick Bowler <nbowler@draconx.ca> - 2012-08-01 20:14 +0000
    Re: signal() anomaly falk@rahul.net (Edward A. Falk) - 2012-07-31 22:12 +0000
      Re: signal() anomaly hip cat <nospam@nospam.com> - 2012-08-01 18:58 +0000
        Re: signal() anomaly James Kuyper <jameskuyper@verizon.net> - 2012-08-01 15:33 -0400
          Re: signal() anomaly hip cat <nospam@nospam.com> - 2012-08-01 20:47 +0000
            Re: signal() anomaly Paul <nospam@needed.com> - 2012-08-01 17:34 -0400
              Re: signal() anomaly Johann Klammer <klammerj@NOSPAM.a1.net> - 2012-08-02 06:34 +0200
                Re: signal() anomaly Paul <nospam@needed.com> - 2012-08-02 07:10 -0400
            Re: signal() anomaly Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-01 18:07 -0400
              Re: signal() anomaly Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-02 00:15 +0100
                Re: signal() anomaly Nick Bowler <nbowler@draconx.ca> - 2012-08-02 00:05 +0000
                  Re: signal() anomaly Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-02 02:47 +0100
            Re: signal() anomaly James Kuyper <jameskuyper@verizon.net> - 2012-08-01 18:13 -0400
            Re: signal() anomaly James Kuyper <jameskuyper@verizon.net> - 2012-08-01 18:14 -0400
            Re: signal() anomaly Nobody <nobody@nowhere.com> - 2012-08-02 12:52 +0100
        Re: signal() anomaly Angel <angel+news@spamcop.net> - 2012-08-01 19:41 +0000
        Re: signal() anomaly Kenneth Brody <kenbrody@spamcop.net> - 2012-08-01 16:16 -0400
        Re: signal() anomaly Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-01 16:33 -0400
        Re: signal() anomaly Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-02 00:22 +0100
        Re: signal() anomaly Stephen Sprunk <stephen@sprunk.org> - 2012-08-02 00:55 -0500
          Re: signal() anomaly Ike Naar <ike@sverige.freeshell.org> - 2012-08-02 07:01 +0000
        Re: signal() anomaly Öö Tiib <ootiib@hot.ee> - 2012-09-08 20:53 -0700
    Re: signal() anomaly Nobody <nobody@nowhere.com> - 2012-08-01 18:06 +0100
      Re: signal() anomaly Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 13:44 -0700
    Re: signal() anomaly Kleuske <kleuske@nowhere.net> - 2012-08-02 20:52 +0000

Page 2 of 2 — ← Prev page 1 [2]

#24094

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

[toc] | [prev] | [next] | [standalone]

#24103

hip cat <nospam@nospam.com> writes:
<snip>
> 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.

From a purely practical point of view, I can't urge you strongly enough
to run your program using a memory checker like valgrind.  I'd have
swapped all other debugging tools for something like valgrind when I was
wrestling with loads of buggy C (well, non-portable C is probably more
fair), but there was no such tool available.  Don't ignore it now if it
is available on your platform.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#24111

On 01-Aug-12 13:58, 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.

Sorry, but the correct solution is to check for null before you
dereference a pointer, even if it is theoretically "impossible" for that
pointer to be null.

Ignoring a null pointer dereference is pretty much impossible, since
there are no sensible semantics for continuing execution after that
point--and trying to do so will probably just cause other "impossible"
bugs to appear and waste even more of your time.

Treat the disease, not the symptom.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

[toc] | [prev] | [next] | [standalone]

#24112

On 2012-08-02, Stephen Sprunk <stephen@sprunk.org> wrote:
> On 01-Aug-12 13:58, 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.
>
> Sorry, but the correct solution is to check for null before you
> dereference a pointer, even if it is theoretically "impossible" for that
> pointer to be null.

Following this advice would make it impossible to dereference a pointer:

/* assuming pointer is non-volatile */

if (pointer != NULL)
{
  /* at this point it's theoretically impossible for pointer
     to be null, but let's check anyway */
  if (pointer != NULL)
  {
    /* at this point it's theoretically impossible for pointer
       to be null, but let's check anyway */
    if (pointer != NULL)
    {
      /* at this point it's theoretically impossible for pointer
         to be null, but let's check anyway */
      if (pointer != NULL)
      {
        /* at this point it's theoretically impossible for pointer
           to be null, but let's check anyway */
        if (pointer != NULL)
        {
          /* at this point it's theoretically impossible for pointer
             to be null, but let's check anyway */
          if (pointer != NULL)
          {
            /* at this point it's theoretically impossible for pointer
               to be null, but let's check anyway */

                /* ... etc ad infinitum ... */
  
                        do_something_with(*pointer);

                /* ... */
          }
        }
      }
    }
  }
}

[toc] | [prev] | [next] | [standalone]

#26155

On Wednesday, August 1, 2012 9:58:08 PM UTC+3, Jase Schick 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?
> 
> My code has a certain pointer that sometimes unexpectedly becomes null. 

The defects in software are unexpected only for inexperienced. 
They are perfectly normal. 

> It would be a lot of work to find every place the pointer gets 
> dereferenced and add a null check.

Tracking the defects down and fixing them takes 60% or more of 
overall development effort in any software project worth mentioning.

> So I want to just ignore it by catching the signal.

This is an attempt of building a wheelchair for your invalid
program. If you could not write its abilities correctly then the
replacement abilities from wheelchair by you will be even worse.
Who needs software with disabilities in broken wheelchair? 
Better repair your program, it is cheaper.

[toc] | [prev] | [next] | [standalone]

#24070

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/9699919799/functions/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(). 

[toc] | [prev] | [next] | [standalone]

#26082

Nobody <nobody@nowhere.com> writes:

> 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 S2.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/9699919799/functions/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(). 

Not being a POSIX expert, I wouldn't want to disagree, but I did
find this:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/signal.html

    The functionality described on this reference page is
    aligned with the ISO C standard.  Any conflict between the
    requirements described here and the ISO C standard is
    unintentional.  This volume of POSIX.1-2008 defers to the
    ISO C standard.

Not offering any conclusions, just FYAI.

[toc] | [prev] | [next] | [standalone]

#24150

On Tue, 31 Jul 2012 20:13:34 +0000, hip cat saw fit to publish the
following:

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

RTFM (man signal). You cannot ignore SIGSEGV.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web