signal() call

[Richie]

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

 

[John Gordon]

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.

 

[Jorgen Grahn]

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

 

[Lew Pitcher]

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

 

[John Gordon]

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.

 

[Ben Bacarisse]

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

013 == 11

Hey, topical post in an off-topic thread.

 

[Lew Pitcher]

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]

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.

 

[Peter Nilsson]

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.

 

[Nobody]

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

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.