Как gdb влияет на sem_post / sem_wait? - PullRequest
0 голосов
/ 20 февраля 2019

Backgound

Процесс "перехват"

  1. процесс является процессом-демоном, работающим на сетевом устройстве, устройство работает под управлением Linux 2.6.39-gentoo

  2. процесс содержит n + 1 потоков, поток (1-n) получает пакеты от ядра, а thread0 отправляет пакеты другому процессу.

  3. когда пользователь хочет перехватить пакеты, они сообщают номер пакета для «перехвата», затем thread1-n выполняет захват пакетов, когда он перехватывает один пакет, он помещает пакет в очередь.а затем sem_post (& sync_sem) ;

  4. thread0 sem_wait (& sync_sem) , и выгрузка пакета из очереди, а затем отправка в Process "recv "by socket.

Проблема

  1. Процесс" захват "работает нормально в большинстве случаев.но один клиент сообщает, что программа через некоторое время ничего не захватывает.и с этого времени ничего не может перехватить.
  2. Я вошел в систему на устройстве, кажется, процесс "recv" ничего не получает.GDB прикрепить к процессу "recv", все выглядит хорошо.после убитого процесса "recv" и перезапустите его, все еще не работает.поэтому нет ничего общего с процессом "recv".
  3. при копировании процесса "capture". Чтобы увидеть некоторые глобальные параметры без остановки процесса, я набираю [gdb -p {capture_pid} -q-n -ex 'p {g_paramer}' -batch] , что удивительно, процесс "recv" сразу же получил номер пакета (1000).
  4. Поскольку число pps устройства составляет всего около 10.это означает, что путь к сокету от «capture» до «recv» хорош, а 1000 пакетов уже помещены в очередь. Ни thread1-n не уведомляет thread0 (что означает, что sem_post что-то не так), ни thread0 не получает уведомление (что означает, что sem_wait что-то не так)

Вопрос

Итак, мой вопрос: что сделал GDB, чтобы восстановить все?

не может воспроизвести проблему вообще, любой совет приветствуется.

...