Signal mask restore anomaly

Signal mask restore anomaly

[Frank Jas]

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/

Re: Signal mask restore anomaly

[David A. Gatwood]

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/

Re: Signal mask restore anomaly

[Jeffrey Hawkins]

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/

Re: Signal mask restore anomaly

[Hendricks, Kevin]

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:
>>
>> 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/

Re: Signal mask restore anomaly

[Hendricks, Kevin]

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:
>>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
>>
>>********************************************************
>>
>
>
>--
>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/