All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed

From: "D.J. Barrow" <barrow_dj@yahoo.com>
To: linuxppc-dev <linuxppc-dev@lists.linuxppc.org>,
	Gary Thomas <gdt@linuxppc.org>,
	Lauro Whately <whately@cos.ufrj.br>
Subject: signal handling bug demo....
Date: Thu, 25 Feb 1999 03:39:53 -0800 (PST)	[thread overview]
Message-ID: <19990225113953.9356.rocketmail@send203.yahoomail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1528 bytes --]

Here is a demonstration of the bug I described in earlier mails about signals being lost by the kernel.
I am now quite sure the bug will manifest itself in all variants of linux unless the signal dispatching has changed radically. The code is I believe posix compilant ( Thanks Lauro ).

The bug arises when (sig)longjmp gets called out of a signal handler sys_sigreturn dosen't get called & the signals queued on the user stack get trashed.


To Demo:
put parent.c child.c & testmake in the same
directory. Compile using testmake  run parent.
Note "the bug" that only one signal gets delivered per loop of the child.

This bug I believe can be fixed by simplifing the kernel. There is no reason  (I'm aware of ) to queue the signals on the user stack sys_sigreturn gets called in the kernel for every signal delivered so this queueing is fundamentally a braindamaged idea.


The bug can be fixed I believe by
1) Removeing the while loop in do signal 
2) Removing the current sys_sigreturn
3) Making do_signal also function as sys_sigreturn.
4) Remove handle_signal.
5) Unblock the signal before delivering it ( this would enable longjmp out of signal handlers to behave correctly also ) rather than leaving the signal blocked forever.

So no do_signal will get called for each signal delivered. The thing would be a lot stabiler & use less userstack & remove -200 lines of really crap code.





_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

[-- Attachment #2: child.c --]
[-- Type: application/octet-stream, Size: 284 bytes --]

#include <stdio.h>
#include <signal.h>
#include <setjmp.h>

int main(int argc,char *argv[])
{
   int cnt;
   printf("In child\n");
   for(cnt=0;cnt<30;cnt++)
   {
      printf("looping in child\n");
      kill(getppid(),SIGUSR1);
      kill(getppid(),SIGUSR2);
      sleep(1);
   }
}

[-- Attachment #3: parent.c --]
[-- Type: application/octet-stream, Size: 634 bytes --]

#include <stdio.h>
#include <signal.h>
#include <setjmp.h>

sigjmp_buf genv;

void mysignal(int sig)
{
  printf("received signal %d\n",sig);
  siglongjmp(genv,1);
}


int main(int argc,char *argv[])
{
  int childpid;

  signal(SIGUSR1,mysignal);
  signal(SIGUSR2,mysignal);
  if((childpid=fork())==-1)
  {
      printf("fork failed\n");
      exit(-1);
  }
  else if(childpid==0)
  {
      printf("execlping child pid=%d",getpid());
      if(execlp("./child","./child",(char *)0)==-1)
      {
	 printf("execlp failed");
	 exit(-1);
      }
  }
  sigsetjmp(genv,1);
  for(;;)
  {
    printf("looping in parent\n");
    sleep(1);
  }
}

[-- Attachment #4: testmake --]
[-- Type: application/octet-stream, Size: 107 bytes --]

gcc -D__USE_BSD_SIGNAL -D__USE_BSD child.c -o child
gcc -D__USE_BSD_SIGNAL -D__USE_BSD  parent.c -o parent

                 reply	other threads:[~1999-02-25 11:39 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19990225113953.9356.rocketmail@send203.yahoomail.com \
    --to=barrow_dj@yahoo.com \
    --cc=gdt@linuxppc.org \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=whately@cos.ufrj.br \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.