Signal() problem

This is a discussion on Signal() problem within the C Programming forums, part of the General Programming Boards category; As I was compiling a simple program to try on the POSIX Signals, I encountered this error when I executed ...

  1. #1
    Registered User
    Join Date
    Mar 2005
    Posts
    54

    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.

  2. #2
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,434
    > 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
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  3. #3
    Registered User
    Join Date
    Mar 2005
    Posts
    54
    > 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.

    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

  4. #4
    Gawking at stupidity
    Join Date
    Jul 2004
    Location
    Oregon, USA
    Posts
    3,162
    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.
    Last edited by itsme86; 06-02-2006 at 11:17 AM.
    If you understand what you're doing, you're not learning anything.

  5. #5
    Gawking at stupidity
    Join Date
    Jul 2004
    Location
    Oregon, USA
    Posts
    3,162
    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.
    If you understand what you're doing, you're not learning anything.

  6. #6
    Registered User
    Join Date
    Mar 2005
    Posts
    54
    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.

  7. #7
    Gawking at stupidity
    Join Date
    Jul 2004
    Location
    Oregon, USA
    Posts
    3,162
    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
    Last edited by itsme86; 06-02-2006 at 11:41 AM.
    If you understand what you're doing, you're not learning anything.

  8. #8
    Registered User
    Join Date
    Mar 2005
    Posts
    54
    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.

  9. #9
    Gawking at stupidity
    Join Date
    Jul 2004
    Location
    Oregon, USA
    Posts
    3,162
    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:
    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.
    Last edited by itsme86; 06-02-2006 at 12:00 PM.
    If you understand what you're doing, you're not learning anything.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Problem with signals
    By kahad in forum C Programming
    Replies: 9
    Last Post: 12-07-2006, 09:42 AM
  2. Laptop Problem
    By Boomba in forum Tech Board
    Replies: 1
    Last Post: 03-07-2006, 05:24 PM
  3. NAQ: Everything you never wanted to know about CPP
    By evildave in forum C Programming
    Replies: 21
    Last Post: 12-12-2005, 09:56 AM
  4. Replies: 5
    Last Post: 11-07-2005, 10:34 PM
  5. beginner problem
    By The_Nymph in forum C Programming
    Replies: 4
    Last Post: 03-05-2002, 04:46 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21