This is the mail archive of the
libc-alpha@sourceware.cygnus.com
mailing list for the glibc project.
[sbachman@saveware.com] libc/1534: When a program execl()'s in a signal function, the new program no longer responds to any signals set by the user.
- To: libc-alpha Mailinglist <libc-alpha at sourceware dot cygnus dot com>
- Subject: [sbachman@saveware.com] libc/1534: When a program execl()'s in a signal function, the new program no longer responds to any signals set by the user.
- From: Andreas Jaeger <aj at suse dot de>
- Date: 14 Jan 2000 21:59:30 +0100
- Cc: sbachman at saveware dot com
Hi glibc developers & testers,
We've received the appended bug report. For me this looks like a bug
in the kernel. AFAIK Posix explicitly mentions execl as a function
which is allowed to be called from a signal handler (printf is not
signal safe but I don't think that this is the problem here).
What do you think? Should this be forwarded to linux-kernel?
Andreas
P.S. Here's the test program - name the executable `testd' and send it
kill -INT and kill -HUP.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/* 2000 (c) Scott Bachmann sbachman@saveware.com */
/* Help from: ds111@cornell.edu */
#include <signal.h>
#include <stdio.h>
#include <unistd.h>
void foo2( int sig )
{ printf("Foo 2 you too at %d\n",sig); }
void foo( int sig )
{
printf("I got signal %d\n", sig);
execl("./testd","./testd",(char *) 0);
}
int main()
{
struct sigaction newaction;
newaction.sa_handler = foo;
newaction.sa_flags = 0;
if ( sigaction( SIGINT, &newaction, NULL ) == -1)
perror("Could not install the new signal handler");
newaction.sa_handler = foo2;
if ( sigaction( SIGHUP, &newaction, NULL ) == -1)
perror("Could not install the new signal handler");
printf("Signals set, program loaded, entering while\n");
while (1) {
printf("Hello Ball!! \n");
sleep(2);
}
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Subject: libc/1534: When a program execl()'s in a signal function, the new program no longer responds to any signals set by the user.
- From: sbachman at saveware dot com
- Date: Fri Jan 14 21:57:00 2000
Topics:
libc/1534: When a program execl()'s in a signal function, the new program no longer responds to any signals set by the user.
----------------------------------------------------------------------
Date: Fri, 14 Jan 2000 15:28:07 -0500
From: sbachman@saveware.com
To: bugs@gnu.org
Subject: libc/1534: When a program execl()'s in a signal function, the new program no longer responds to any signals set by the user.
Message-Id: <200001142028.PAA30069@delysid.gnu.org>
>Number: 1534
>Category: libc
>Synopsis: When a program execl()'s in a signal function, the new program no longer responds to any signals set by the user.
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: libc-gnats
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Fri Jan 14 15:30:00 EST 2000
>Last-Modified:
>Originator: sbachman@saveware.com
>Organization:
net
>Release: 2.1.2, 2.1.1
>Environment:
Slackware 7.0, Fresh install other then 2.2.14 kernel upgrade
Redhat 6.0, Not so fresh, glibc 2.1.1, kernel 2.1.12
>Description:
After a few months of running one of our servers (client/server pair)
we released our version to a few friends, running slackware 7.0 and
redhat boxs. They noticed that when the program receives a signal,
and is to reload, it reloads, but then it can not be reloaded again
with the same signal. This worked on my slackware 4.x box, with
libc5. After upgrading my system to slackware 7.0, the same code now
fails to work properly. It no longer receives the signals sent by
the user.
>How-To-Repeat:
Please see http://www.saveware.com/~sbachman/testd.c for test code.
Program receives signal - in signal function, program execl()'s to
load itself again. In new program, program sets signals, fails to
act upon receiving signals
>Fix:
>Audit-Trail:
>Unformatted:
------------------------------
End of forwardCNGt7q Digest
***************************
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.rhein-neckar.de