Thread: 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

Originally Posted by bithub

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?

Originally Posted by jeffcobb

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....

Originally Posted by brewbuck

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)

Originally Posted by brewbuck

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?

Originally Posted by brewbuck

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

Originally Posted by brewbuck

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?