Информация об изменениях

Сообщение Re[6]: Отладка Boost::Asio от 10.12.2019 20:44

Изменено 10.12.2019 20:47 prrt

Re[6]: Отладка Boost::Asio
Здравствуйте, netch80, Вы писали:

N>Думаю, проверить можно так: сделайте где-то переменную (достаточно bool) с логикой типа:


N>
N>void Zuka::requestAccept() {
N>  if (mAcceptRequested) { return; }
N>  mIOService.async_accept(..., [this](const boost::system::error_code &ec) { cbAccept(ec); });
N>  mAcceptRequested = true;
N>}
N>void Zuka::cbAccept(const boost::system::error_code &ec) {
N>  if (ec) { разберётесь сами; }
N>  mAcceptRequested = false;
N>  ... обработка ...
N>  if (!mShutdownRequested) { requestAccept(); }
N>}
N>


N>Тогда в отладчике можно будет проверять этот флаг; не стоит => ошибка в вашем коде; стоит => проблема в ASIO.


Сделал. Значение флага после зависания = true. Дополнительно сделал std::map, по ключу thread_id записываю туда уникальные значения при начале выполнения каждого асинхронного обработчика, и при его завершении. После зависания считываю значения всех нитей из этой map. Все значения соответствуют выходу из обработчиков, т.е. ни одна из нитей в io_service не была заблокирована при выполнении обработчика.
Recv-Q = 129
Send-Q = 0
Вскоре после зависания дискрипторы файлов процесса вообще перестают обновляться, все сокеты в состоянии CLOSE_WAIT.
strace показывает, что зависает на futex():
# strace -p 26096
strace: Process 26096 attached

futex(0x13ce088, FUTEX_WAIT_PRIVATE, 0, NULL
и всё, больше никакого вывода.
# strace -e trace=read,write,network,signal,ipc,desc,memory -p 26096
strace: Process 26096 attached

пусто, больше никакого вывода.
При этом отдельные потоки демона, не связанные с io_service, продолжают работать (через них и считывал разную информацию после зависания).

Как бы получить стек вызовов futex()? Т.е как бы определить, после какого вызова всё на нём блокируется?
Re[6]: Отладка Boost::Asio
Здравствуйте, netch80, Вы писали:

N>Думаю, проверить можно так: сделайте где-то переменную (достаточно bool) с логикой типа:


N>
N>void Zuka::requestAccept() {
N>  if (mAcceptRequested) { return; }
N>  mIOService.async_accept(..., [this](const boost::system::error_code &ec) { cbAccept(ec); });
N>  mAcceptRequested = true;
N>}
N>void Zuka::cbAccept(const boost::system::error_code &ec) {
N>  if (ec) { разберётесь сами; }
N>  mAcceptRequested = false;
N>  ... обработка ...
N>  if (!mShutdownRequested) { requestAccept(); }
N>}
N>


N>Тогда в отладчике можно будет проверять этот флаг; не стоит => ошибка в вашем коде; стоит => проблема в ASIO.


Сделал. Значение флага после зависания = true. Дополнительно сделал std::map, по ключу thread_id записываю туда уникальные значения при начале выполнения каждого асинхронного обработчика, и при его завершении. После зависания считываю значения всех нитей из этой map. Все значения соответствуют выходу из обработчиков, т.е. ни одна из нитей в io_service не была заблокирована при выполнении обработчика.
Recv-Q = 129
Send-Q = 0
Вскоре после зависания дискрипторы файлов процесса вообще перестают обновляться, все сокеты в состоянии CLOSE_WAIT.
strace показывает, что зависает на futex():
# strace -p 26096
strace: Process 26096 attached
futex(0x13ce088, FUTEX_WAIT_PRIVATE, 0, NULL

и всё, больше никакого вывода.
# strace -e trace=read,write,network,signal,ipc,desc,memory -p 26096
strace: Process 26096 attached

пусто, больше никакого вывода.
При этом отдельные потоки демона, не связанные с io_service, продолжают работать (через них и считывал разную информацию после зависания).

Как бы получить стек вызовов futex()? Т.е как бы определить, после какого вызова всё на нём блокируется?