Signal() problem

As I was compiling a simple program to try on the POSIX Signals, I encountered this error when I executed the program.

I was trying this out during lab session.

From what I understand is that I would send a kill with a pid to wake up the sleeping process and terminating it.

I'm pretty new at this topic so here's the code...

Code:

---

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>
#include <errno.h>

typedef void Sigfunc(int);

int sigaction(int signum, const struct sigaction *newAction,
              struct sigaction *oldAction);

Sigfunc *Signal(int signum, Sigfunc *signalHandler){

  struct sigaction newAction, oldAction;
  newAction.sa_handler = signalHandler;
  sigemptyset(&newAction.sa_mask);
  newAction.sa_flags = 0;

  if(sigaction(signum, &newAction, &oldAction) < 0){
    return(SIG_ERR);
  }
  else{
    return(oldAction.sa_handler);
  }
}

static void sigusr1_handler(int);
void mySIGUSR1Handler(int);

int main(void)
{
  if(Signal(SIGUSR1, mySIGUSR1Handler) != SIG_IGN){
    perror("ERROR");
  }

  if(Signal(SIGUSR1, SIG_IGN) != SIG_IGN){
      if(Signal(SIGUSR1, mySIGUSR1Handler) != SIG_IGN){
        perror("ERROR");
      }
  }
  while(1)
    pause();
}

void mySIGUSR1Handler(int signum){
  fprintf(stderr, "Received signal SIGUSR1\n");
}

---

/****My Output
test: syntax error at line 1: `^?ELF^A^B^A^A^B^A^E\2144' unexpected
*************/
After the error is displayed, the program terminates after hitting the 'Enter' key.

> test: syntax error at line 1: `^?ELF^A^B^A^A^B^A^E\2144' unexpected
Call it something else, test is also the name of a program in /usr/bin

> int sigaction(int signum, const struct sigaction *newAction,
> struct sigaction *oldAction);
It's already prototyped isn't it?
In a header file

Quote:

---

> int sigaction(int signum, const struct sigaction *newAction,
> struct sigaction *oldAction);
It's already prototyped isn't it?
In a header file

---

Sorry, I must've misread the notes wrongly,I've removed the line from the program.
However the problem still persist.

Quote:

---

From what I understand is that I would send a kill with a pid to wake up the sleeping process and terminating it.

---

Just to be a little specific, I would input a kill manually

Quote:

---

Originally Posted by Salem

> test: syntax error at line 1: `^?ELF^A^B^A^A^B^A^E\2144' unexpected
Call it something else, test is also the name of a program in /usr/bin

---

Try to get in the habit of running programs in the current directory by preceding the program name with ./ (e.g. ./test)

That will avoid further confusion from this type of thing. I don't even have . in my path.

You're not catching the normal term signal. Try this instead:

Code:

---

$ kill -s USR1 <whatever the PID is>

---

Without specifying the right signal it will just kill the program without triggering your handler.

Thanks, instead of naming the program "test", I tried with the "./a.out" , it seems to catch the signal with "kill -USR1 <PID>"

While running the program, it printed

Code:

---

ERROR: Error 0

---

Regarding the error above, is it related to the syntax error
I mentioned in the earlier post?
Other than that, the signal was received.

Code:

---

$ kill -s USR1 <whatever the PID is>

---

It gave a complain saying its a bad signal.

I'm guessing perror() on your system doesn't understand error code 0. When I run your program I see:

Code:

---

ERROR: Success

---

...as soon as I run it.

The reason it's showing up is because if Signal() doesn't return SIG_IGN it's not necessarily an error, but you seem to be treating it as such. It just means the previous action wasn't to ignore the signal.

According to man 7 signal on my machine the default action for SIGUSR1 is to terminate the program.

Code:

---

      The entries in the "Action" column of  the  table  specify
      the default action for the signal, as follows:

      Term  Default action is to terminate the process.



      Signal    Value    Action  Comment
      -------------------------------------------------------------------------
      SIGUSR1  30,10,16    Term    User-defined signal 1

---

Is there by any chance that ERROR : 0 was meant for success and 1 or -1 is failure?

Thanks for the info. I've checked with my man on my campus's machine. The default action of SIGUSR1 is to Exit.

Just to let you know, my campus's machine is running SunOS 5.6, I'm trying to adapt to programming in the Unix Env.

Quote:

---

Originally Posted by DarrenY

Is there by any chance that ERROR : 0 was meant for success and 1 or -1 is failure?

---

No.

Library functions set a global variable errno to some value, indicating what error was encountered inside that function. If there was an error, errno will always be something other than 0 (but if the function succeeds it doesn't necessarily set errno to 0). Check man errno for more information.

On my system, most of the error codes are defined in /usr/include/asm/errno.h

Here's an excerpt:

Code:

---

#define EPERM            1      /* Operation not permitted */
#define ENOENT          2      /* No such file or directory */
#define ESRCH            3      /* No such process */
#define EINTR            4      /* Interrupted system call */
#define EIO              5      /* I/O error */
#define ENXIO            6      /* No such device or address */
#define E2BIG            7      /* Argument list too long */
#define ENOEXEC          8      /* Exec format error */
#define EBADF            9      /* Bad file number */
#define ECHILD          10      /* No child processes */
#define EAGAIN          11      /* Try again */

---

There is a lookup table somewhere (in a library probably) that lets functions like perror() get the string associated with an error code. perror() takes the current value of errno and finds the string associated with it. Then it prints the string you pass to it followed by ": " and the string that it looked up.

According to man perror:

Quote:

---

The global error list sys_errlist[] indexed by errno can
be used to obtain the error message without the newline.
The largest message number provided in the table is
sys_nerr -1. Be careful when directly accessing this list
because new error values may not have been added to
sys_errlist[].

When a system call fails, it usually returns -1 and sets
the variable errno to a value describing what went wrong.
(These values can be found in <errno.h>.) Many library
functions do likewise. The function perror() serves to
translate this error code into human-readable form. Note
that errno is undefined after a successful library call:
this call may well change this variable, even though it
succeeds, for example because it internally used some
other library function that failed. Thus, if a failing
call is not immediately followed by a call to perror, the
value of errno should be saved.

---