signal() call

Discussion in 'C Programming' started by Richie, Feb 9, 2011.

  1. Richie

    Richie Guest

    Howdee,

    I've inherited some early 90s code from an unknown Unix-type platform
    that I need to get running. There are lots of problems, but one that's
    bugging me is the following line, which shows up as the first line in main
    () for every executable I've got:

    signal(013,1); /* handle memory problems */

    I find the programs still regularly coredump and segfault, so whatever
    "handling" this line is doing, it aint working out for me.

    Anyone had to deal with this problem before?

    -r
     
    Richie, Feb 9, 2011
    #1
    1. Advertising

  2. Richie

    John Gordon Guest

    In <iiuuto$ure$> Richie <> writes:

    > signal(013,1); /* handle memory problems */


    > I find the programs still regularly coredump and segfault, so whatever
    > "handling" this line is doing, it aint working out for me.


    That call ignores SIGPIPE signals. Not sure what the comment is supposed
    to mean.

    --
    John Gordon A is for Amy, who fell down the stairs
    B is for Basil, assaulted by bears
    -- Edward Gorey, "The Gashlycrumb Tinies"
     
    John Gordon, Feb 9, 2011
    #2
    1. Advertising

  3. Richie

    Jorgen Grahn Guest

    On Wed, 2011-02-09, Richie wrote:
    > Howdee,
    >
    > I've inherited some early 90s code from an unknown Unix-type platform
    > that I need to get running. There are lots of problems, but one that's
    > bugging me is the following line, which shows up as the first line in main
    > () for every executable I've got:
    >
    > signal(013,1); /* handle memory problems */
    >
    > I find the programs still regularly coredump and segfault, so whatever
    > "handling" this line is doing, it aint working out for me.
    >
    > Anyone had to deal with this problem before?


    Yes, in the sense that I've had to maintain code by long-gone people
    who didn't really know what they were doing, but who wouldn't admit
    it ;-)

    This is probably offtopic because the details of signal(2) here are
    Unix-specific, but:

    - I suspect this call is more "cargo-cult programming" than something
    which actually /helped/ against the "memory problems" (whatever that
    means).

    - On modern Linux, signal(013,1) is the same as signal(SIGSEGV,
    SIG_IGN). I think you'll find these numbers have been stable over
    most Unixes. So it's an attempt to ignore segmentation violations ...

    - I frankly have no idea what happens if you try something like that,
    or what used to happen 20 years ago. Signal handling has varied a bit
    between the Unixes.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Feb 9, 2011
    #3
  4. Richie

    Lew Pitcher Guest

    On February 9, 2011 16:30, in comp.lang.c, wrote:

    > In <iiuuto$ure$> Richie <> writes:
    >
    >> signal(013,1); /* handle memory problems */

    >
    >> I find the programs still regularly coredump and segfault, so whatever
    >> "handling" this line is doing, it aint working out for me.

    >
    > That call ignores SIGPIPE signals.


    ITYM SIGSEGV. That first argument is 013; an octal value. In decimal it is
    (0*64) + (1*8) + 3, or 11.

    OTOH, SIGPIPE is signal decimal 13 or octal 015

    > Not sure what the comment is supposed to mean.


    It seems appropriate for a SIGSEGV handler.

    OTOH, the use of the constant 1 as the signal handler bothers me. While 1
    might be the appropriate value for some platform, the generic (some might
    say, "proper") way to specify an "ignore" handler is to use the SIG_IGN
    #defined constant.

    HTH
    --
    Lew Pitcher
    Master Codewright & JOAT-in-training | Registered Linux User #112576
    Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
    ---------- Slackware - Because I know what I'm doing. ------
     
    Lew Pitcher, Feb 9, 2011
    #4
  5. Richie

    John Gordon Guest

    In <iiv12h$ptg$> John Gordon <> writes:

    > > signal(013,1); /* handle memory problems */


    > That call ignores SIGPIPE signals. Not sure what the comment is supposed
    > to mean.


    O0ps, as Jorgen pointed out it's SIGSEGV, not SIGPIPE. Darn octal
    notation.

    --
    John Gordon A is for Amy, who fell down the stairs
    B is for Basil, assaulted by bears
    -- Edward Gorey, "The Gashlycrumb Tinies"
     
    John Gordon, Feb 9, 2011
    #5
  6. John Gordon <> writes:

    > In <iiuuto$ure$> Richie <> writes:
    >
    >> signal(013,1); /* handle memory problems */

    >
    >> I find the programs still regularly coredump and segfault, so whatever
    >> "handling" this line is doing, it aint working out for me.

    >
    > That call ignores SIGPIPE signals. Not sure what the comment is supposed
    > to mean.


    013 == 11

    Hey, topical post in an off-topic thread.

    --
    Ben.
     
    Ben Bacarisse, Feb 9, 2011
    #6
  7. Richie

    Lew Pitcher Guest

    On February 9, 2011 16:55, in comp.lang.c, wrote:

    > John Gordon <> writes:
    >
    >> In <iiuuto$ure$> Richie <> writes:
    >>
    >>> signal(013,1); /* handle memory problems */

    >>
    >>> I find the programs still regularly coredump and segfault, so whatever
    >>> "handling" this line is doing, it aint working out for me.

    >>
    >> That call ignores SIGPIPE signals. Not sure what the comment is supposed
    >> to mean.

    >
    > 013 == 11
    >
    > Hey, topical post in an off-topic thread.


    Ben, I agree that your post is topical.

    But, how is a discussion on the signal() call off-topic for CLC?
    IIRC, signal() and friends are part of (at least) the C90 standard.

    --
    Lew Pitcher
    Master Codewright & JOAT-in-training | Registered Linux User #112576
    Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
    ---------- Slackware - Because I know what I'm doing. ------
     
    Lew Pitcher, Feb 9, 2011
    #7
  8. Richie

    Lew Pitcher Guest

    On February 9, 2011 16:33, in comp.lang.c, wrote:

    > On Wed, 2011-02-09, Richie wrote:
    >> Howdee,
    >>
    >> I've inherited some early 90s code from an unknown Unix-type platform
    >> that I need to get running. There are lots of problems, but one that's
    >> bugging me is the following line, which shows up as the first line in
    >> main () for every executable I've got:
    >>
    >> signal(013,1); /* handle memory problems */
    >>
    >> I find the programs still regularly coredump and segfault, so whatever
    >> "handling" this line is doing, it aint working out for me.
    >>
    >> Anyone had to deal with this problem before?

    >
    > Yes, in the sense that I've had to maintain code by long-gone people
    > who didn't really know what they were doing, but who wouldn't admit
    > it ;-)
    >
    > This is probably offtopic because the details of signal(2) here are
    > Unix-specific, but:


    The functions signal() and raise(), along with macros SIGABRT, SIGFPR,
    SIGILL, SIGINT, SIGSEGV, SIGTERM, SIG_DFL, SIG_ERR, and SIG_IGN are all
    defined in the C90 standard. Within that scope, this question is within the
    pervue of CLC.

    > - I suspect this call is more "cargo-cult programming" than something
    > which actually /helped/ against the "memory problems" (whatever that
    > means).


    I concur. No good can come of that line of code. And, it indicates that the
    other lines of code have serious flaws that need visiting before the code
    should be used.

    > - On modern Linux, signal(013,1) is the same as signal(SIGSEGV,
    > SIG_IGN). I think you'll find these numbers have been stable over
    > most Unixes. So it's an attempt to ignore segmentation violations ...


    Which is dangerous in and of itself. It means that
    a) the code has paths that invoke segmentation violations, which are
    serious flaws in the implementation and/or design of the program, and
    b) these flaws are now hidden so that, instead of a predictable result
    (abend with core dump), the program will behave in a completely
    unpredictable manner.

    > - I frankly have no idea what happens if you try something like that,
    > or what used to happen 20 years ago. Signal handling has varied a bit
    > between the Unixes.


    I think that the OP has some serious debugging/refactoring to do on this
    code.

    I wish him the best of luck with it.
    --
    Lew Pitcher
    Master Codewright & JOAT-in-training | Registered Linux User #112576
    Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
    ---------- Slackware - Because I know what I'm doing. ------
     
    Lew Pitcher, Feb 9, 2011
    #8
  9. Lew Pitcher <> wrote:
    > wrote:
    > > John Gordon <> writes:
    > > > Richie <> writes:
    > > > > signal(013,1); /* handle memory problems */
    > > > >
    > > > > I find the programs still regularly coredump and
    > > > > segfault, so whatever "handling" this line is doing,
    > > > > it aint working out for me.
    > > >
    > > > That call ignores SIGPIPE signals.  Not sure what the
    > > > comment is supposed to mean.

    > >
    > > 013 == 11
    > >
    > > Hey, topical post in an off-topic thread.
    > >

    > Ben, I agree that your post is topical.
    >
    > But, how is a discussion on the signal() call off-topic for
    > CLC? IIRC, signal() and friends are part of (at least) the
    > C90 standard.


    True, but SIGPIPE is POSIX and the C standard doesn't define
    what the SIG* macro expansions evaluate to. The second
    argument is UB and a constraint violation if a prototype for
    signal() exists.

    Perhaps the OP is interested in more conforming code, but so
    far the discussions have barely touched on that.

    --
    Peter
     
    Peter Nilsson, Feb 9, 2011
    #9
  10. Richie

    Nobody Guest

    On Wed, 09 Feb 2011 21:33:01 +0000, Jorgen Grahn wrote:

    > - On modern Linux, signal(013,1) is the same as signal(SIGSEGV,
    > SIG_IGN). I think you'll find these numbers have been stable over
    > most Unixes. So it's an attempt to ignore segmentation violations ...
    >
    > - I frankly have no idea what happens if you try something like that,
    > or what used to happen 20 years ago. Signal handling has varied a bit
    > between the Unixes.


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


    On a current Linux/x86 system, ignoring SIGSEGV has no effect; the process
    will still receive it and terminate.
     
    Nobody, Feb 10, 2011
    #10
  11. Lew Pitcher <> writes:

    > On February 9, 2011 16:55, in comp.lang.c, wrote:
    >
    >> John Gordon <> writes:
    >>
    >>> In <iiuuto$ure$> Richie <> writes:
    >>>
    >>>> signal(013,1); /* handle memory problems */
    >>>
    >>>> I find the programs still regularly coredump and segfault, so whatever
    >>>> "handling" this line is doing, it aint working out for me.
    >>>
    >>> That call ignores SIGPIPE signals. Not sure what the comment is supposed
    >>> to mean.

    >>
    >> 013 == 11
    >>
    >> Hey, topical post in an off-topic thread.

    >
    > Ben, I agree that your post is topical.
    >
    > But, how is a discussion on the signal() call off-topic for CLC?
    > IIRC, signal() and friends are part of (at least) the C90 standard.


    Just because the OP's question is highly system specific. The function
    is standard, but what the OP needs to know to port the program almost
    certainly won't be. Even determining what 013 and 1 mean is system
    specific as far as C is concerned. comp.unix.programmer is probably the
    best place to find out what's needed to port code like this.

    --
    Ben.
     
    Ben Bacarisse, Feb 10, 2011
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Michael Pronath
    Replies:
    1
    Views:
    1,172
    Diez B. Roggisch
    Jan 3, 2005
  2. Jack Orenstein

    threading.Thread vs. signal.signal

    Jack Orenstein, Sep 18, 2005, in forum: Python
    Replies:
    0
    Views:
    468
    Jack Orenstein
    Sep 18, 2005
  3. Weng Tianxiang
    Replies:
    2
    Views:
    661
    Jonathan Bromley
    Jan 30, 2007
  4. Nicolas Moreau
    Replies:
    9
    Views:
    3,177
  5. dibacco73
    Replies:
    1
    Views:
    653
    joris
    Feb 12, 2009
Loading...

Share This Page