[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c

signal() call

unknown

2/9/2011 8:54:00 PM

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
12 Answers

John Gordon

2/9/2011 9:31:00 PM

0

In <iiuuto$ure$1@speranza.aioe.org> Richie <nospam@nospam.com> 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
gordon@panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

Jorgen Grahn

2/9/2011 9:33:00 PM

0

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 .

Lew Pitcher

2/9/2011 9:51:00 PM

0

On February 9, 2011 16:30, in comp.lang.c, gordon@panix.com wrote:

> In <iiuuto$ure$1@speranza.aioe.org> Richie <nospam@nospam.com> 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.digitalfr... | Just Linux: http://jus...
---------- Slackware - Because I know what I'm doing. ------

John Gordon

2/9/2011 9:52:00 PM

0

In <iiv12h$ptg$1@reader1.panix.com> John Gordon <gordon@panix.com> 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
gordon@panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

Ben Bacarisse

2/9/2011 9:56:00 PM

0

John Gordon <gordon@panix.com> writes:

> In <iiuuto$ure$1@speranza.aioe.org> Richie <nospam@nospam.com> 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.

Lew Pitcher

2/9/2011 9:59:00 PM

0

On February 9, 2011 16:55, in comp.lang.c, ben.usenet@bsb.me.uk wrote:

> John Gordon <gordon@panix.com> writes:
>
>> In <iiuuto$ure$1@speranza.aioe.org> Richie <nospam@nospam.com> 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.digitalfr... | Just Linux: http://jus...
---------- Slackware - Because I know what I'm doing. ------

Lew Pitcher

2/9/2011 10:24:00 PM

0

On February 9, 2011 16:33, in comp.lang.c, grahn+nntp@snipabacken.se 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.digitalfr... | Just Linux: http://jus...
---------- Slackware - Because I know what I'm doing. ------

Peter Nilsson

2/9/2011 10:33:00 PM

0

Lew Pitcher <lpitc...@teksavvy.com> wrote:
> ben.use...@bsb.me.uk wrote:
> > John Gordon <gor...@panix.com> writes:
> > > Richie <nos...@nospam.com> 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

John Doe

2/10/2011 1:58:00 AM

0

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.

Ben Bacarisse

2/10/2011 3:35:00 AM

0

Lew Pitcher <lpitcher@teksavvy.com> writes:

> On February 9, 2011 16:55, in comp.lang.c, ben.usenet@bsb.me.uk wrote:
>
>> John Gordon <gordon@panix.com> writes:
>>
>>> In <iiuuto$ure$1@speranza.aioe.org> Richie <nospam@nospam.com> 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.