FD_SET читает с неверного адреса памяти? - PullRequest
Новая
       21

FD_SET читает с неверного адреса памяти?

1 голос
/ 06 марта 2012

** РЕДАКТИРОВАТЬ: Я нашел решение. **

У меня странная проблема для тех, кто осмеливается читать ниже:

Я работаюна домашнем задании, и нужно отправлять сообщения между процессами, используя каналы UNIX.

Мое намерение с этим кодом состоит в том, чтобы выбрать () в предоставленном дескрипторе файла.Если что-то доступно для чтения без блокировки, я хочу вернуть это.Если нет, я хочу вернуть NULL и продолжить без блокировки.

Вот код внутри моей функции "getMessage", где fd - дескриптор файла: 

message* getMessage(int fd){
    int messageAvailable = 0;
    struct timeval timeout;
    fd_set fd2;

    //If there's a message available, read it; if not, continue on without delay
    timeout.tv_sec = 0;
    timeout.tv_usec = 0;
    FD_ZERO(&fd2);
    FD_SET(fd,&fd2);
    messageAvailable = select(FD_SETSIZE,&fd2,NULL,NULL,&timeout);
    if(messageAvailable){
        int bytesRead = 0;
        message* m;
        m = malloc(sizeof(message));
        //Get the header
        bytesRead = read(fd,m,sizeof(message));
        //If we got the whole message
        if(bytesRead == sizeof(message)){
            return m;
        }else{
            //If a message wasn't generated, free the space we allocated for it
            free(m);
            return NULL;
        }
    }else{
        return NULL;
    }
}

Этот код находится внутрицикла, продолжающегося в течение всей программы, и точно в той же точке (при следующем вызове getMessage () после успешной передачи одного сообщения) происходит ошибка.Очевидно, строка FD_SET читает из недопустимого места в памяти.

Не публикуя весь мой код, может ли кто-нибудь догадаться, что может произойти, что вызывает ошибку в этом простом макросе?

Ниже я разместил соответствующую информацию об отладке, где строка 33 соответствует строке FD_SET выше: 

==1330== Invalid read of size 1
==1330==    at 0x804E819: getMessage (messages.c:33)
==1330==    by 0x8049123: main (messageTest.c:110)
==1330==  Address 0xde88d627 is not stack'd, malloc'd or (recently) free'd
==1330== 
==1330== 
==1330== Process terminating with default action of signal 11 (SIGSEGV)
==1330==  Access not within mapped region at address 0xDE88D627
==1330==    at 0x804E819: getMessage (messages.c:33)
==1330==    by 0x8049123: main (messageTest.c:110)
==1330==  If you believe this happened as a result of a stack
==1330==  overflow in your program's main thread (unlikely but
==1330==  possible), you can try to increase the size of the
==1330==  main thread stack using the --main-stacksize= flag.
==1330==  The main thread stack size used in this run was 8388608.
==1330== 
==1330== HEAP SUMMARY:
==1330==     in use at exit: 344 bytes in 10 blocks
==1330==   total heap usage: 25 allocs, 15 frees, 2,492 bytes allocated
==1330== 
==1330== LEAK SUMMARY:
==1330==    definitely lost: 12 bytes in 1 blocks
==1330==    indirectly lost: 0 bytes in 0 blocks
==1330==      possibly lost: 0 bytes in 0 blocks
==1330==    still reachable: 332 bytes in 9 blocks
==1330==         suppressed: 0 bytes in 0 blocks
==1330== Rerun with --leak-check=full to see details of leaked memory
==1330== 
==1330== For counts of detected and suppressed errors, rerun with: -v
==1330== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 11 from 6)
Segmentation fault

1 Ответ

0 голосов
/ 06 марта 2012

Упс ... Я случайно передал -1 в функцию в качестве FD после некоторой обработки (которая объясняет, почему это происходило в одной и той же точке при каждом запуске).

Этот вопрос, вероятно, может быть закрыт; Я не думаю, что это служит многим целям вне моего единственного случая использования.

...