Подружить epoll_wait с gdb

ну так у вас таймаут -1, а что вы хотели ?

Но ведь:

man epoll_wait | grep timeout | grep '\-1'

значит нужно смотреть strace

Отладка происходит при помощи аттача по pid'u?

Если так, то, это похоже известная проблема, так сделано, что блокирующие системные вызовы возвращают EINTR после SIGSTOP. И это логично, ибо ты можешь например постопать процесс, отрубить устройство, включить на его место новое и без EINTR, ты будешь тупо ждать чего-то, чего можно и не дождаться. По этому в этой точке должна быть какая то ошибка, и это - EINTR.

На самом деле всё ещё проще (man 7 signal) :

Interruption of system calls and library functions by signal handlers
       If a signal handler is invoked while a system call or library
       function call is blocked, then either:

       * the call is automatically restarted after the signal handler
         returns; or

       * the call fails with the error EINTR.

       Which of these two behaviors occurs depends on the interface and
       whether or not the signal handler was established using the
       SA_RESTART flag (see sigaction(2)).  The details vary across UNIX
       systems; below, the details for Linux.

       If a blocked call to one of the following interfaces is interrupted
       by a signal handler, then the call is automatically restarted after
       the signal handler returns if the SA_RESTART flag was used; otherwise
       the call fails with the error EINTR:

А gdb использует sigtrap как минимум для бряков.

Отладка происходит при помощи аттача по pid'u?

Просто пользуюсь фронтендом ddd или в прямо в Eclipse CDT. Не вникала в кухню, к сожалению((

А gdb использует sigtrap как минимум для бряков.

С этим что-то можно сделать?

Придумать другой механизм установки бряков и пропатчить gdb?

Сделать обработчик сигналов?

Читать мануал и обрабатывать все возможные ошибки?

В хорошем коде, ещё видимо стоит не забыть, что epoll_wait есть точка отмены.

с работой с сигналами знакома поверхностно. погружаюсь...

что за точка отмены?

Но не бери в голову, я соврал, epoll_wait не есть точка отмены (хотя это казалось бы ожидается), и что бы его прервать придётся плясать с посылкой сигналов руками.

а то я подумала что ты про «точки отказа»

за 10 лет сетевого программирования впервые вижу что бы отлаживали через gdb printf хватает с головой

не буду врать, мне надоело использовать printf и решила попробовать «что-то новое». Сразу же столкнулась с проблемой epoll. От себя добавлю что используя printf с повышением уровня абстракции приходится убирать этот мусор или добавлять его опять когда возвращаешься отладке уже написанного. Это привносит чудовищный треш с гитом когда можешь закомитить косук с printf, потом его нужно затереть и опять что-то комитить.
printf - выход для софта на тыщу-другую строк и когда работаешь один, в противном случае нужен уже какой-то настраиваемый логгер, я уже подхожу к этому, но это уже совсем другая тема...

в реалтайм приложениях дебагер не применим, поскольку везде есть таймеры итд, пока вы будете стоять на дебагере, все таймеры протухнут и код никогда не пойдет по том пути
а для тестирования отдельных частей обычно используют стесс тесты

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

От себя добавлю что используя printf с повышением уровня абстракции приходится убирать этот мусор или добавлять его опять когда возвращаешься отладке уже написанного.

Ни в коем случае не отговариваю от использования gdb, а наоборот. Но и printf можно завернуть в #ifdef DEBUG, например, или что-то вроде того, а потом просто передавать эту переменную DEBUG в make, а из него в cc через опцию -D.

в противном случае нужен уже какой-то настраиваемый логгер

В правильно заданном вопросе не меньше половины ответа)

приходится убирать этот мусор или добавлять его опять когда возвращаешься отладке уже написанного

повторная отладка логгером написанного становится редким явлением, если проект хорошо покрывать юнит тестами.