Re: Re: Re: [LCP]SIGFPE

["devraj sanyal" <devraj_sanyal@rediffmail.com>]

It might be messed up but that is how things are.
Though I only tested this in the Linux environment
may be in other Unix flavours it will work differently.
If anyone has tried this under any other enivronment
please let me know.

-devraj

On Fri, 12 Jul 2002 Jack Lloyd wrote :
>I find that odd, since SIGILL and SIGFPE are both in the class of 
>signals
>sent where something is wrong with the hardware itself, and it 
>does work
>for SIGILL.
>
>So the kernel re-executes the instruction until it works? That's 
>messed up.
>  -J
>
>On 12 Jul 2002, devraj  sanyal wrote:
>
> > setjmp lngjmp doesnot help since the kernel
> > dispatches the signal again and again until
> > the condition of fpe is removed.
> >
> > e.g.
> > int i = 0;
> > SigHandler(int sig)
> > {
> > 	i = 5;
> > }
> >
> > int main ()
> > {
> > 	int j;
> > 	signal (SIGFPE, SigHandler);
> > 	j = 10/i;
> > 	printf ("here i am");
> > 	return 0;
> > }
> >
> >
> > this program works fine and here i am is printed
> > but without changing i the loop is infinite.
> >
> > devraj
> >
> >
> >
> > On Thu, 11 Jul 2002 Jack Lloyd wrote :
> > >Well, it actually only says that ignoring this signal can 
>result in an
> > >infinte loop. I would presume this means using SIG_IGN, 
>rather than
> > >requiring that the signal handler must abort.
> > >
> > >There is a workaround to this. Basically, use setjmp and 
>longjmp. Do a
> > >setjmp right before you do the potentially bad instruction, 
>and do a
> > >longjmp out of the signal handler.
> > >
> > >I'm not totally sure that you're allowed to do longjmp inside 
>a signal
> > >handler (actually, I'm pretty sure it's undefined by POSIX). 
>But I've seen
> > >it done in several pieces of reasonable portable pieces of 
>software. I've
> > >never done this for SIGFPE but I've seen it for SIGILL and 
>done it myself
> > >for SIGPIPE.
> > >
> > >-Jack
> > >
> > >On 11 Jul 2002, devraj  sanyal wrote:
> > >
> > > > This is the default behaviour of the kernel.
> > > > on sigfpe the kernel loops on the signal
> > > > again and again. check out the man page
> > > > for signal.
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, 11 Jul 2002 madhav morje wrote :
> > > > >Hello,
> > > > >
> > > > >I'm a novice in signal field. I was trying to out a 
>simple
> > > > >program (which I've pasted below). When the binary was 
>executed,
> > > > >signal handler for SIGFPE was executed continuously even 
>though
> > > > >I've written a signal handler for it.
> > > > >
> > > > >My query is, why kernel continuously gives this signal to 
>my
> > > > >program Or Am I missing something in my code??
> > > > >
> > > > >If I reset signal handler for SIGFPE to defualt one in 
>the signal
> > > > >handler function, then my program gets terminated.
> > > > >
> > > > >Regards,
> > > > >Madhav.
> > > > >
> > > > >======================================================
> > > > >#include <signal.h>
> > > > >#include <stdio.h>
> > > > >#include <unistd.h>
> > > > >
> > > > >void sighand(int sig)
> > > > >{
> > > > >  printf("\nSig Recd %d", sig);
> > > > >  /*
> > > > >  ** Should signal handler be reset here for SIGFPE to 
>default
> > > > >here ????
> > > > >  */
> > > > >}
> > > > >
> > > > >int main()
> > > > >{
> > > > >
> > > > >struct sigaction act;
> > > > >int j=10,k;
> > > > >
> > > > >act.sa_handler = sighand;
> > > > >sigemptyset(&act.sa_mask);
> > > > >act.sa_flags = 0;
> > > > >
> > > > >sigaddset(&act.sa_mask, SIGFPE);
> > > > >
> > > > >(void) sigaction(SIGFPE, &act, 0);
> > > > >
> > > > >k=j/0;
> > > > >
> > > > >printf("\ndone!!\n");
> > > > >
> > > > >return 0;
> > > > >
> > > > >}
> > > > >======================================================
> > > > 
> >_________________________________________________________
> > > > >There is always a better job for you at 
>Monsterindia.com.
> > > > >Go now http://monsterindia.rediff.com/jobs
> > > > >
> > > > >
> > > > >_______________________________________________
> > > > >This is the Linux C Programming List
> > > > >:  http://lists.linux.org.au/listinfo/linuxcprogramming 
>List
> > > >
> > > > 
>_________________________________________________________
> > > > There is always a better job for you at 
>Monsterindia.com.
> > > > Go now http://monsterindia.rediff.com/jobs
> > > >
> > > >
> > > > _______________________________________________
> > > > This is the Linux C Programming List
> > > > :  http://lists.linux.org.au/listinfo/linuxcprogramming 
>List
> > > >
> > >
> > >
> > >_______________________________________________
> > >This is the Linux C Programming List
> > >:  http://lists.linux.org.au/listinfo/linuxcprogramming 
>List
> >
> > _________________________________________________________
> > There is always a better job for you at Monsterindia.com.
> > Go now http://monsterindia.rediff.com/jobs
> >
> >
> > _______________________________________________
> > This is the Linux C Programming List
> > :  http://lists.linux.org.au/listinfo/linuxcprogramming List
> >
>
>
>
>_______________________________________________
>This is the Linux C Programming List
>:  http://lists.linux.org.au/listinfo/linuxcprogramming List