Подтвердить что ты не робот

Программа получила сигнал SIGPIPE, Разбитая труба

Я пишу клиентскую программу на основе posix сокетов. Программа создает несколько потоков и собирается заблокировать сервер. Но во время отладки во время GDB программа выдает информацию (ошибка)

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

Вот код:

#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;
}

Что это и что делать?

4b9b3361

Ответ 1

Процесс получил SIGPIPE. Поведение по умолчанию для этого сигнала - завершить процесс.

SIGPIPE отправляется процессу, если он пытался записать данные в сокет, который был отключен для записи или больше не подключен.

Чтобы избежать завершения программы в этом случае, вы можете либо

  • заставить процесс игнорировать SIGPIPE

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

    или же

  • установить явный обработчик для SIGPIPE (обычно ничего не делая):

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

В обоих случаях send*()/write() вернет -1 и установит errno в EPIPE.

Ответ 2

При отладке с помощью "gdb" можно вручную отключить SIGPIPE следующим образом:

(gdb) handle SIGPIPE nostop

Ответ 3

Обходной путь для SIGPIPE, вы можете игнорировать этот сигнал с помощью этого кода:

#include <signal.h>

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

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

в вашем коде (основной или глобальный)

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

Ответ 4

Вы записали соединение, которое уже было закрыто одноранговым узлом.

Ответ 5

У меня возникла такая же проблема, и это позволило мне перейти на эту должность. Я получил спорадические сигналы SIGPIPE, вызывающие сбои моей программы fastcgi C, выполняемой nginx. Я старался signal(SIGPIPE, SIG_IGN); без везения, он продолжал сбой.

Причина заключалась в том, что у nginx temp dir была проблема с разрешением. При фиксации разрешений была решена проблема SIGPIPE. Подробнее здесь о том, как исправить и подробнее здесь.