Thread: connecttoserer() leading to SIGKILL

  1. #1
    Registered User
    Join Date
    Dec 2009
    Posts
    42

    connecttoserer() leading to SIGKILL

    Hi,

    My application is irregularly receiving a SIGKILL from the system and i haven't been able to figure out how or where but I have a suspecion that my function connecttoserver() is responsible for this but i couldn't figure out why or what...
    the function looks as pasted below. Can anyone see what may be leading to that kind of behaviour or should i be looking at something else?
    Code:
    int connecttoserver(char *hostname,int port)
    {  
      struct hostent     *he;
      struct sockaddr_in  server;  
      struct protoent    *pr;
      int MySocket=-1;
      static int old_port=0;
      //static char *old_hostname;
    
    /* resolve localhost to an IP (should be 127.0.0.1) */
      if ((he = gethostbyname(hostname)) == NULL) {
        printf("error resolving hostname..\n");
        syslog(LOG_NOTICE,"nlog: error resolving hostname..");
        return -1;
      }  
    /*
     * copy the network address part of the structure to the 
     * sockaddr_in structure which is passed to connect() 
     */
      memcpy(&server.sin_addr, he->h_addr_list[0], he->h_length);
      server.sin_family = AF_INET;
      server.sin_port = htons(port);
    
      pr = getprotobyname("tcp");
      if (!pr) {
        printf("getpotobyname() failed...!\n");
        syslog(LOG_NOTICE,"nlog: getpotobyname() failed...");
        MySocket=-1;
        return -1;
      }
      
      /* create socket */
      if ( (MySocket = socket(PF_INET, SOCK_STREAM, pr->p_proto)) == -1) {
        syslog(LOG_NOTICE,"nlog: error creating socket...,errno: %s!\n", strerror( errno ));
        printf("error creating socket...,errno: %s!\n", strerror( errno ));
        MySocket=-1;
        return -1; 
      }
    
    /* connect */
      if (connect(MySocket, (struct sockaddr *)&server, sizeof(server))) {
        if (old_port!=port){
          syslog(LOG_NOTICE,"nlog: error connecting to %s on port %d...,errno: %s!\n", hostname, port, strerror( errno ));
          old_port=port;
        }
        MySocket=-1;    
        return -1;
      }
        
      return MySocket;
    }
    Thank you!

    roN

  2. #2
    Registered User
    Join Date
    Sep 2004
    Location
    California
    Posts
    3,268
    Nothing jumps out at me as being incorrect. Can you run this through a debugger like GDB to determine what exactly is generating the signal?
    bit∙hub [bit-huhb] n. A source and destination for information.

  3. #3
    Registered User jeffcobb's Avatar
    Join Date
    Dec 2009
    Location
    Henderson, NV
    Posts
    875
    What hardware platform is this? I know what the assumption is but if you are working on prototypical hardware, sometimes the C/C++ runtime just isn't complete. I was working on a project for the PS3 that GCC would happily compile socket code but gethostbyname() would just fall off the end of the world because it was not fully implemented. I know, it stinks but that is the wild-n-crazy world of working on new hardware.

    Stupid question but have you checked the validity/contents of hostname?
    C/C++ Environment: GNU CC/Emacs
    Make system: CMake
    Debuggers: Valgrind/GDB

  4. #4
    Registered User
    Join Date
    Dec 2009
    Posts
    42
    Quote Originally Posted by bithub View Post
    Nothing jumps out at me as being incorrect. Can you run this through a debugger like GDB to determine what exactly is generating the signal?
    I am running it in GDB but how am i be able to determine what generated the signal?

  5. #5
    Registered User
    Join Date
    Sep 2004
    Location
    California
    Posts
    3,268
    Step through the connecttoserver function line by line. When the signal is generated, gdb should tell you.
    bit∙hub [bit-huhb] n. A source and destination for information.

  6. #6
    Registered User jeffcobb's Avatar
    Join Date
    Dec 2009
    Location
    Henderson, NV
    Posts
    875
    Quote Originally Posted by cerr View Post
    I am running it in GDB but how am i be able to determine what generated the signal?
    Well, when it jumps out, what does the 'where' command reveal?
    C/C++ Environment: GNU CC/Emacs
    Make system: CMake
    Debuggers: Valgrind/GDB

  7. #7
    Registered User
    Join Date
    Dec 2009
    Posts
    42
    Quote Originally Posted by jeffcobb View Post
    What hardware platform is this? I know what the assumption is but if you are working on prototypical hardware, sometimes the C/C++ runtime just isn't complete. I was working on a project for the PS3 that GCC would happily compile socket code but gethostbyname() would just fall off the end of the world because it was not fully implemented. I know, it stinks but that is the wild-n-crazy world of working on new hardware.

    Stupid question but have you checked the validity/contents of hostname?
    yes, /etc/hostname is correct (ping MyHostname) is working fine too. To my platform, I'm running on a x86 AMD Geode that is running a minimized BusyBox Linux distribution with kernel 2.6.15.1 on ulibC. Not sure if that makes any kind of difference. But it's interesting that you ran into problems with gethostbyname() - that's pretty scary actually....

  8. #8
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Are you sure the signal is SIGKILL? The OS never automatically generates SIGKILL. Some process must be deliberately sending you this signal to kill you off.

    EDIT: If it really is SIGKILL, then I suspect you might have some sort of firewall software installed which is blowing you away when it detects your "unauthorized" connection attempt.
    Last edited by brewbuck; 01-11-2010 at 04:36 PM.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  9. #9
    Registered User
    Join Date
    Dec 2009
    Posts
    42
    Quote Originally Posted by brewbuck View Post
    Are you sure the signal is SIGKILL? The OS never automatically generates SIGKILL. Some process must be deliberately sending you this signal to kill you off.
    GDB says:
    Program terminated with signal SIGKILL, Killed.
    The program no longer exists.
    (gdb)

    and ayou say
    The OS never automatically generates SIGKILL - how sure are you about that I'm wondering...? The process list on my system looks like this:
    Code:
      PID  Uid     VmSize Stat Command
        1 root        364 S   init
        2 root            SWN [ksoftirqd/0]
        3 root            SW< [events/0]
        4 root            SW< [khelper]
        5 root            SW< [kthread]
        7 root            SW< [kblockd/0]
        8 root            SW< [kacpid]
       70 root            SW< [khubd]
      137 root            SW  [pdflush]
      138 root            SW  [pdflush]
      140 root            SW< [aio/0]
      139 root            SW  [kswapd0]
      731 root            SW< [kseriod]
      877 root        308 S   /usr/sbin/dropbear
      885 root        252 S   /usr/sbin/cron
      912 nobody      420 S   /usr/sbin/thttpd -C /etc/thttpd.conf
      926 root        508 S   -ash
      929 root        504 S   -ash
      932 root        504 S   -ash
      949 root        144 S   ./KeepAliveForever
     4865 root        320 S   watch -n 1 ps ax
     5668 root        316 S   /usr/sbin/syslog-ng
     5677 root        292 S   tail -f /var/log/messages
    15256 root        476 R   /usr/sbin/dropbear
    15259 root        436 S   -ash
    15263 root        348 R   ps ax
    ~ #
    Where ./KeepAliveForever is my little "debug" binary that's generating a heartbeat on the GPIO in order to tell the power supply that my binary is still working (even if it's dead like in this snapshot)

  10. #10
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by cerr View Post
    The OS never automatically generates SIGKILL - how sure are you about that I'm wondering...?
    There are probably some obscure cases where it can happen, like the OOM killer, but for everyday situations the OS will never send you this signal.

    Normally, you could use sigaction() to register a signal handler, get the siginfo_t, and examine the si_pid field to figure out which process sent the signal. But SIGKILL is one of the few signals that are uncatchable so there is no way to know who sent the signal.

    After the SIGKILL, does "info signals" in gdb tell you anything?

    Also, you could try running your program under strace to see if that tells you anything. Just "strace ./YourProgram"
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  11. #11
    Registered User
    Join Date
    Dec 2009
    Posts
    42
    Quote Originally Posted by brewbuck View Post
    There are probably some obscure cases where it can happen, like the OOM killer, but for everyday situations the OS will never send you this signal.

    Normally, you could use sigaction() to register a signal handler, get the siginfo_t, and examine the si_pid field to figure out which process sent the signal. But SIGKILL is one of the few signals that are uncatchable so there is no way to know who sent the signal.

    After the SIGKILL, does "info signals" in gdb tell you anything?

    Also, you could try running your program under strace to see if that tells you anything. Just "strace ./YourProgram"
    info signals
    Doesn't really tell me anything. It prints a list of signals and SIGKILL shows up like:
    SIGKILL Yes Yes Yes Killed
    which doesn't really help either, eh?
    Man, any other ideas?
    Also would OOM be a stand alone process or is it part of the kernel?

  12. #12
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by cerr View Post
    info signals
    Doesn't really tell me anything. It prints a list of signals and SIGKILL shows up like:
    SIGKILL Yes Yes Yes Killed
    which doesn't really help either, eh?
    Man, any other ideas?
    Also would OOM be a stand alone process or is it part of the kernel?
    OOM is a part of the kernel. Basically, when the kernel thinks it is critically low on memory, it runs an algorithm to choose the "worst" offenders and starts killing them off. I believe, but am not certain, that it uses SIGKILL to do the actual killing.

    Other than that possible case I don't think the kernel ever sends a SIGKILL. They come from other processes.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  13. #13
    Registered User
    Join Date
    Sep 2004
    Location
    California
    Posts
    3,268
    Quote Originally Posted by brewbuck View Post
    OOM is a part of the kernel. Basically, when the kernel thinks it is critically low on memory, it runs an algorithm to choose the "worst" offenders and starts killing them off. I believe, but am not certain, that it uses SIGKILL to do the actual killing.

    Other than that possible case I don't think the kernel ever sends a SIGKILL. They come from other processes.
    OOM killer does send SIGKILL. It should leave a message in the system log when it kills a process, so you should be able to check and see if that was the source of the signal.
    bit∙hub [bit-huhb] n. A source and destination for information.

  14. #14
    Registered User
    Join Date
    Dec 2009
    Posts
    42
    Quote Originally Posted by brewbuck View Post
    OOM is a part of the kernel. Basically, when the kernel thinks it is critically low on memory, it runs an algorithm to choose the "worst" offenders and starts killing them off. I believe, but am not certain, that it uses SIGKILL to do the actual killing.

    Other than that possible case I don't think the kernel ever sends a SIGKILL. They come from other processes.
    Now I just realized that (at least) one thread in my application terminated like before witha SIGKILL but i didn't see anything in gdb... How would that be? I'm using gdb to connect to the remote target on my target platform with target remote IP:Port

  15. #15
    Registered User
    Join Date
    Dec 2009
    Posts
    42
    Quote Originally Posted by brewbuck View Post
    There are probably some obscure cases where it can happen, like the OOM killer, but for everyday situations the OS will never send you this signal.

    Normally, you could use sigaction() to register a signal handler, get the siginfo_t, and examine the si_pid field to figure out which process sent the signal. But SIGKILL is one of the few signals that are uncatchable so there is no way to know who sent the signal.

    After the SIGKILL, does "info signals" in gdb tell you anything?

    Also, you could try running your program under strace to see if that tells you anything. Just "strace ./YourProgram"
    Also i have downloaded and compiled strace onto my target platform but when i start it with ./strace ./prs I just get a bunch of information before it throws me back to the shell saying
    getppid() = 20506
    fork() = 20508
    _exit(0) = ?
    I assume this is cause my app is "forking"... how can i get the information from a forked process?

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. compare function ignoring leading white space
    By mc72 in forum C Programming
    Replies: 5
    Last Post: 11-23-2008, 01:33 PM
  2. Fix sprintf removing leading 0's
    By k2712 in forum C Programming
    Replies: 2
    Last Post: 09-10-2007, 10:58 AM
  3. leading zero's..... ( reading int )
    By sh4k3 in forum C Programming
    Replies: 4
    Last Post: 06-12-2007, 09:03 AM
  4. Removing Leading & Trailing Whitespace
    By EvilGuru in forum C Programming
    Replies: 11
    Last Post: 12-01-2005, 02:59 PM
  5. Leading Underscores
    By laserlight in forum C++ Programming
    Replies: 19
    Last Post: 09-04-2005, 02:16 AM