Programmempfangssignal SIGPIPE, Rohrbruch

Ich schreibe ein Client-Programm, das auf Posix-Sockets basiert. Das Programm erstellt mehrere Threads und wird den Server sperren. Aber während des Debuggens in gdb-Zeit gibt das Programm eine Info (Fehler)

(gdb) n
Program received signal SIGPIPE, Broken pipe. [Switching to Thread 0xb74c0b40 (LWP 4864)] 0xb7fdd424 in __kernel_vsyscall () 
(gdb) 

Hier ist der Code:

#include <arpa/inet.h>
#include <netdb.h>
#include <netinet/in.h>
#include <pthread.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <unistd.h>

int get_hostname_by_ip(char* h , char* ip)
{
    struct hostent *he;
    struct in_addr **addr_list;
    int i;

    if ((he = gethostbyname(h)) == NULL) 
    {
        perror("gethostbyname");
        return 1;
    }
    addr_list = (struct in_addr **) he->h_addr_list;
    for(i = 0; addr_list[i] != NULL; i++) 
    {
        strcpy(ip , inet_ntoa(*addr_list[i]) );
        return 0;
    }

    return 1;
}

void client(char* h, int s)
{
    int fd;
    struct sockaddr_in addr;
    char ch[]="aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
    fd = socket(AF_INET, SOCK_STREAM, 0);
    addr.sin_family=AF_INET;
    char* ip = new char[20];
    get_hostname_by_ip(h, ip);
    addr.sin_addr.s_addr=inet_addr(ip);
    int port = 80;
    addr.sin_port=htons(port);
    if(connect(fd, (struct sockaddr*)&addr, sizeof(addr)) < 0) 
    {
        perror("connect error");
        return;
    }
    while(1)
    {
        if(send(fd, ch, sizeof(ch), 0) < 0)
        {   
            perror("send");
        }
    }
    //char buffer[1024];
    //if(recv(fd, &buffer, sizeof(buffer), 0) < 0)
    //{ 
    //  perror("recive");
    //}

    //printf("nReply from Server: %s\n", buffer);
    close(fd);
}

struct info
{
    char* h;
    int c;
};


void* thread_entry_point(void* i)
{
    info* in = (info*)i;
    client(in->h, in->c);
}

int main(int argc, char** argv)
{
    int s = atoi(argv[2]);
    pthread_t t[s];
    info in = {argv[1], s};
    for(int i = 0; i < s; ++i)
    {
        pthread_create(&t[i], NULL, thread_entry_point, (void*)&in);
    }
    pthread_join(t[0], NULL);

    return 0;
}

Was ist das und was ist zu tun?

Der Prozess erhielt a SIGPIPE. Das Standardverhalten für dieses Signal ist das Beenden des Prozesses.

EIN SIGPIPE wird an einen Prozess gesendet, wenn er versucht hat, auf einen Socket zu schreiben, der zum Schreiben heruntergefahren wurde oder nicht (mehr) verbunden ist.

Um zu vermeiden, dass das Programm in diesem Fall beendet wird, können Sie beides tun

• Lassen Sie den Prozess ignorieren SIGPIPE

  #include <signal.h>
  
  int main(void)
  {
    sigaction(SIGPIPE, &(struct sigaction){SIG_IGN}, NULL);
  
    ...
  

  oder

• Installieren Sie einen expliziten Handler für SIGPIPE (normalerweise nichts tun):

  #include <signal.h>
  
  void sigpipe_handler(int unused)
  {
  }
  
  int main(void)
  {
    sigaction(SIGPIPE, &(struct sigaction){sigpipe_handler}, NULL);
  
    ...
  

In beiden Fällen send*()/write() würde zurückkehren -1 und einstellen errno zu EPIPE.

Beim Debuggen mit ‘gdb’ ist es möglich, SIGPIPE wie folgt manuell zu deaktivieren:

(gdb) behandelt SIGPIPE nostop

Eine Problemumgehung für SIGPIPE, Sie können dieses Signal mit diesem Code ignorieren:

#include <signal.h>

/* Catch Signal Handler functio */
void signal_callback_handler(int signum){

        printf("Caught signal SIGPIPE %d\n",signum);
}

in Ihrem Code (Haupt oder global)

/* Catch Signal Handler SIGPIPE */
signal(SIGPIPE, signal_callback_handler);

Sie haben auf eine bereits vom Peer geschlossene Verbindung geschrieben.

Ich hatte irgendwie das gleiche Problem und es hat mich zu diesem SO-Post geführt. Ich habe sporadische SIGPIPE-Signale erhalten, die zu Abstürzen meines Fastcgi-C-Programms führten, das von nginx ausgeführt wird. Ich versuchte zu signal(SIGPIPE, SIG_IGN); ohne Glück, es stürzte immer wieder ab.

Der Grund war, dass das temporäre Verzeichnis von nginx ein Berechtigungsproblem hatte. Das Korrigieren der Berechtigungen löste das SIGPIPE-Problem. Details zur Behebung hier und mehr hier.