From: Frank Jas <hidden> Date: 2000-08-16 19:25:36
Under certain circumstances, a signal blocked while a
signal handler is executing will not be restored.
This is my kernel info:
Linux 2.2.6-15apmac #1 Mon May 31 03:54:09 EDT 1999 ppc unknown
The behavior does not occur under Intel versions (2.2.5-15smp).
Below is a program that tests out the use of signal masks
with sigaction(). It sets up a handler for SIGINT and
SIGTSTP. The handler for SIGTSTP adds SIGINT to
the signal mask for that handler. So while the SIGTSTP
handler is executing, occurences of SIGINT will be
blocked until the handler returns. SIGTSTP will also
be blocked.
#define _POSIX_SOURCE 1
#define _GNU_SOURCE 1
#include <signal.h>
#include <errno.h>
#include <stdio.h>
void on_intr (signum)
int signum ;
{
printf("\n Interrupted with signal %d. \n", signum) ;
}
void on_tstp (signum)
int signum;
{
printf ("\n Handler for SIGTSTP wants text or ^C or ^Z: ") ;
getchar () ;
}
void main ()
{
struct sigaction new_intr_action;
struct sigaction new_tstp_action;
int c ;
sigemptyset (&new_intr_action.sa_mask);
new_intr_action.sa_handler = on_intr;
new_intr_action.sa_flags = SA_RESTART;
sigaction (SIGINT, &new_intr_action, 0);
sigemptyset (&new_tstp_action.sa_mask);
sigaddset (&new_tstp_action.sa_mask, SIGINT);
new_tstp_action.sa_handler = on_tstp;
new_tstp_action.sa_flags = SA_RESTART;
sigaction (SIGTSTP, &new_tstp_action, 0);
printf("Starting main input loop enter text or ^Z or ^C:\n") ;
while ((c = getchar ()) != EOF) {
putchar (c);
}
}
The following execution sequence leads to the anomalous behavior.
Trigger the SIGTSTP handler with a ^Z
While executing the handler, deliver a ^Z and ^C
Hit return to return from the handler.
Another instance of the SIGTSTP handler should execute.
Hit return to return from that instance of the handler.
Notice that the SIGINT handler does not execute and should have.
Any subsequent SIGINT are apparently blocked.
Apparently the nested occurence of SIGTSTP effected the restore
of the SIGINT mask, and the handling of the pending SIGINT.
The same behavior will result using 'kill' from another window
to send the signals.
Please let me know if this is not the appropriate venue for this
post.
Frank Jas
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: David A. Gatwood <hidden> Date: 2000-08-17 03:11:01
On Wed, 16 Aug 2000, Frank Jas wrote:
Under certain circumstances, a signal blocked while a
signal handler is executing will not be restored.
Hmm... I think I may be seeing something similar to this as well. It
could explain some very strange behaviour I'm seeing in my alarm handler.
The following execution sequence leads to the anomalous behavior.
Trigger the SIGTSTP handler with a ^Z
While executing the handler, deliver a ^Z and ^C
Hit return to return from the handler.
Another instance of the SIGTSTP handler should execute.
Hit return to return from that instance of the handler.
Notice that the SIGINT handler does not execute and should have.
Any subsequent SIGINT are apparently blocked.
I'm almost sure I'm seeing this. Except for me, it's a 10/sec. alarm
handler and a SIGUSR2 that only occurs occasionally. Major hair rippage.
Let me know if anybody sees what's up. Until then, I may stop blocking
SIGUSR2 and see if that helps one of my two problems. :-)
Later,
David
---------------------------------------------------------------------
A brief Haiku:
Microsoft is bad.
It seems secure at first glance.
Then you read your mail.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Frank,
I am able to reproduce the same failures on a 2.2.13
PPC Kernel, with GCC 2.95.3-2c and GLIBC 2.1.3-15d.
Ran same test code on Solaris with correct operation.
The failure is definitely a MASK restoration problem.
Since, one can recover from the problem by UNBLOCKING
the SIGINT.
I believe the problem may be an interaction between the
Terminal I/O related SIGNALS being used (SIGTSTP and
SIGINT) and the use of the STDIO Library calls (printf
and getch). By replacing the SIGTSTP and SIGINT signals
with SIGUSR1 and SIGUSR2, everything worked correctly
(tested via "kill" command from a separate terminal
window).
Looking at the GLIBC Bug Database, I didn't see any bugs
which seem to correspond to this failure mechanism. Most
of the SIGNALS bugs seem to be related THREADS.
Looks like it is time submit a bug report to GNU....
Jeff
Frank Jas wrote:
Under certain circumstances, a signal blocked while a
signal handler is executing will not be restored.
This is my kernel info:
Linux 2.2.6-15apmac #1 Mon May 31 03:54:09 EDT 1999 ppc unknown
The behavior does not occur under Intel versions (2.2.5-15smp).
Below is a program that tests out the use of signal masks
with sigaction(). It sets up a handler for SIGINT and
SIGTSTP. The handler for SIGTSTP adds SIGINT to
the signal mask for that handler. So while the SIGTSTP
handler is executing, occurences of SIGINT will be
blocked until the handler returns. SIGTSTP will also
be blocked.
#define _POSIX_SOURCE 1
#define _GNU_SOURCE 1
#include <signal.h>
#include <errno.h>
#include <stdio.h>
void on_intr (signum)
int signum ;
{
printf("\n Interrupted with signal %d. \n", signum) ;
}
void on_tstp (signum)
int signum;
{
printf ("\n Handler for SIGTSTP wants text or ^C or ^Z: ") ;
getchar () ;
}
void main ()
{
struct sigaction new_intr_action;
struct sigaction new_tstp_action;
int c ;
sigemptyset (&new_intr_action.sa_mask);
new_intr_action.sa_handler = on_intr;
new_intr_action.sa_flags = SA_RESTART;
sigaction (SIGINT, &new_intr_action, 0);
sigemptyset (&new_tstp_action.sa_mask);
sigaddset (&new_tstp_action.sa_mask, SIGINT);
new_tstp_action.sa_handler = on_tstp;
new_tstp_action.sa_flags = SA_RESTART;
sigaction (SIGTSTP, &new_tstp_action, 0);
printf("Starting main input loop enter text or ^Z or ^C:\n") ;
while ((c = getchar ()) != EOF) {
putchar (c);
}
}
The following execution sequence leads to the anomalous behavior.
Trigger the SIGTSTP handler with a ^Z
While executing the handler, deliver a ^Z and ^C
Hit return to return from the handler.
Another instance of the SIGTSTP handler should execute.
Hit return to return from that instance of the handler.
Notice that the SIGINT handler does not execute and should have.
Any subsequent SIGINT are apparently blocked.
Apparently the nested occurence of SIGTSTP effected the restore
of the SIGINT mask, and the handling of the pending SIGINT.
The same behavior will result using 'kill' from another window
to send the signals.
Please let me know if this is not the appropriate venue for this
post.
Frank Jas
--
********************************************************
Jeffrey Hawkins
Senior Staff Software Engineer
Motorola Wireless Data Solutions Engineering
Address: DEPT: DQ525
MS: IL-02-1055A
1301 East Algonquin Road
Schaumburg, IL 60196
Phone: (847)576-7463
FAX: (847)576-7737
********************************************************
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Hendricks, Kevin <hidden> Date: 2000-08-17 12:43:19
Hi,
This bug was fixed in 2.2.14pre9 and later kernels. Please upgrade or diff
/arch/ppc/kernel/signal.c to see the fix.
Kevin
At 00:05 -0400 8/17/00, Jeffrey Hawkins wrote:
Frank,
I am able to reproduce the same failures on a 2.2.13
PPC Kernel, with GCC 2.95.3-2c and GLIBC 2.1.3-15d.
Ran same test code on Solaris with correct operation.
The failure is definitely a MASK restoration problem.
Since, one can recover from the problem by UNBLOCKING
the SIGINT.
I believe the problem may be an interaction between the
Terminal I/O related SIGNALS being used (SIGTSTP and
SIGINT) and the use of the STDIO Library calls (printf
and getch). By replacing the SIGTSTP and SIGINT signals
with SIGUSR1 and SIGUSR2, everything worked correctly
(tested via "kill" command from a separate terminal
window).
Looking at the GLIBC Bug Database, I didn't see any bugs
which seem to correspond to this failure mechanism. Most
of the SIGNALS bugs seem to be related THREADS.
Looks like it is time submit a bug report to GNU....
Jeff
Frank Jas wrote:
quoted
Under certain circumstances, a signal blocked while a
signal handler is executing will not be restored.
This is my kernel info:
Linux 2.2.6-15apmac #1 Mon May 31 03:54:09 EDT 1999 ppc unknown
The behavior does not occur under Intel versions (2.2.5-15smp).
Below is a program that tests out the use of signal masks
with sigaction(). It sets up a handler for SIGINT and
SIGTSTP. The handler for SIGTSTP adds SIGINT to
the signal mask for that handler. So while the SIGTSTP
handler is executing, occurences of SIGINT will be
blocked until the handler returns. SIGTSTP will also
be blocked.
#define _POSIX_SOURCE 1
#define _GNU_SOURCE 1
#include <signal.h>
#include <errno.h>
#include <stdio.h>
void on_intr (signum)
int signum ;
{
printf("\n Interrupted with signal %d. \n", signum) ;
}
void on_tstp (signum)
int signum;
{
printf ("\n Handler for SIGTSTP wants text or ^C or ^Z: ") ;
getchar () ;
}
void main ()
{
struct sigaction new_intr_action;
struct sigaction new_tstp_action;
int c ;
sigemptyset (&new_intr_action.sa_mask);
new_intr_action.sa_handler = on_intr;
new_intr_action.sa_flags = SA_RESTART;
sigaction (SIGINT, &new_intr_action, 0);
sigemptyset (&new_tstp_action.sa_mask);
sigaddset (&new_tstp_action.sa_mask, SIGINT);
new_tstp_action.sa_handler = on_tstp;
new_tstp_action.sa_flags = SA_RESTART;
sigaction (SIGTSTP, &new_tstp_action, 0);
printf("Starting main input loop enter text or ^Z or ^C:\n") ;
while ((c = getchar ()) != EOF) {
putchar (c);
}
}
The following execution sequence leads to the anomalous behavior.
Trigger the SIGTSTP handler with a ^Z
While executing the handler, deliver a ^Z and ^C
Hit return to return from the handler.
Another instance of the SIGTSTP handler should execute.
Hit return to return from that instance of the handler.
Notice that the SIGINT handler does not execute and should have.
Any subsequent SIGINT are apparently blocked.
Apparently the nested occurence of SIGTSTP effected the restore
of the SIGINT mask, and the handling of the pending SIGINT.
The same behavior will result using 'kill' from another window
to send the signals.
Please let me know if this is not the appropriate venue for this
post.
Frank Jas
--
********************************************************
Jeffrey Hawkins
Senior Staff Software Engineer
Motorola Wireless Data Solutions Engineering
Address: DEPT: DQ525
MS: IL-02-1055A
1301 East Algonquin Road
Schaumburg, IL 60196
Phone: (847)576-7463
FAX: (847)576-7737
********************************************************
--
Kevin B. Hendricks, Associate Professor of Operations and Information
Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario N6A-3K7 CANADA
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Hendricks, Kevin <hidden> Date: 2000-08-17 13:05:44
Check you kernel source in arch/ppc/kernel/signal.c and in do_signal() make
sure there is a break after the call to handle_signal() as shown in the
code snippet below.
/* Whee! Actually deliver the signal. */
handle_signal(signr, ka, &info, oldset, regs, &newsp, frame);
break;
If the break exists, then the problem is someplace else. If not, add it
and your troubles should go away (he said hopefully!).
Kevin
At 08:43 -0400 8/17/00, Hendricks, Kevin wrote:
Hi,
This bug was fixed in 2.2.14pre9 and later kernels. Please upgrade or diff
/arch/ppc/kernel/signal.c to see the fix.
Kevin
At 00:05 -0400 8/17/00, Jeffrey Hawkins wrote:
quoted
Frank,
I am able to reproduce the same failures on a 2.2.13
PPC Kernel, with GCC 2.95.3-2c and GLIBC 2.1.3-15d.
Ran same test code on Solaris with correct operation.
The failure is definitely a MASK restoration problem.
Since, one can recover from the problem by UNBLOCKING
the SIGINT.
I believe the problem may be an interaction between the
Terminal I/O related SIGNALS being used (SIGTSTP and
SIGINT) and the use of the STDIO Library calls (printf
and getch). By replacing the SIGTSTP and SIGINT signals
with SIGUSR1 and SIGUSR2, everything worked correctly
(tested via "kill" command from a separate terminal
window).
Looking at the GLIBC Bug Database, I didn't see any bugs
which seem to correspond to this failure mechanism. Most
of the SIGNALS bugs seem to be related THREADS.
Looks like it is time submit a bug report to GNU....
Jeff
Frank Jas wrote:
quoted
Under certain circumstances, a signal blocked while a
signal handler is executing will not be restored.
This is my kernel info:
Linux 2.2.6-15apmac #1 Mon May 31 03:54:09 EDT 1999 ppc unknown
The behavior does not occur under Intel versions (2.2.5-15smp).
Below is a program that tests out the use of signal masks
with sigaction(). It sets up a handler for SIGINT and
SIGTSTP. The handler for SIGTSTP adds SIGINT to
the signal mask for that handler. So while the SIGTSTP
handler is executing, occurences of SIGINT will be
blocked until the handler returns. SIGTSTP will also
be blocked.
#define _POSIX_SOURCE 1
#define _GNU_SOURCE 1
#include <signal.h>
#include <errno.h>
#include <stdio.h>
void on_intr (signum)
int signum ;
{
printf("\n Interrupted with signal %d. \n", signum) ;
}
void on_tstp (signum)
int signum;
{
printf ("\n Handler for SIGTSTP wants text or ^C or ^Z: ") ;
getchar () ;
}
void main ()
{
struct sigaction new_intr_action;
struct sigaction new_tstp_action;
int c ;
sigemptyset (&new_intr_action.sa_mask);
new_intr_action.sa_handler = on_intr;
new_intr_action.sa_flags = SA_RESTART;
sigaction (SIGINT, &new_intr_action, 0);
sigemptyset (&new_tstp_action.sa_mask);
sigaddset (&new_tstp_action.sa_mask, SIGINT);
new_tstp_action.sa_handler = on_tstp;
new_tstp_action.sa_flags = SA_RESTART;
sigaction (SIGTSTP, &new_tstp_action, 0);
printf("Starting main input loop enter text or ^Z or ^C:\n") ;
while ((c = getchar ()) != EOF) {
putchar (c);
}
}
The following execution sequence leads to the anomalous behavior.
Trigger the SIGTSTP handler with a ^Z
While executing the handler, deliver a ^Z and ^C
Hit return to return from the handler.
Another instance of the SIGTSTP handler should execute.
Hit return to return from that instance of the handler.
Notice that the SIGINT handler does not execute and should have.
Any subsequent SIGINT are apparently blocked.
Apparently the nested occurence of SIGTSTP effected the restore
of the SIGINT mask, and the handling of the pending SIGINT.
The same behavior will result using 'kill' from another window
to send the signals.
Please let me know if this is not the appropriate venue for this
post.
Frank Jas
--
********************************************************
Jeffrey Hawkins
Senior Staff Software Engineer
Motorola Wireless Data Solutions Engineering
Address: DEPT: DQ525
MS: IL-02-1055A
1301 East Algonquin Road
Schaumburg, IL 60196
Phone: (847)576-7463
FAX: (847)576-7737
********************************************************
--
Kevin B. Hendricks, Associate Professor of Operations and Information
Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario N6A-3K7 CANADA
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959
--
Kevin B. Hendricks, Associate Professor of Operations and Information
Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario N6A-3K7 CANADA
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/