Сообщение Re[6]: Отладка Boost::Asio от 10.12.2019 20:44
Изменено 10.12.2019 20:46 prrt
Re[6]: Отладка Boost::Asio
Здравствуйте, netch80, Вы писали:
N>Думаю, проверить можно так: сделайте где-то переменную (достаточно bool) с логикой типа:
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()? Т.е как бы определить, после какого вызова всё на нём блокируется?
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>Тогда в отладчике можно будет проверять этот флаг; не стоит => ошибка в вашем коде; стоит => проблема в ASIO.
Сделал. Значение флага после зависания = true. Дополнительно сделал std::map, по ключу thread_id записываю туда уникальные значения при начале выполнения каждого асинхронного обработчика, и при его завершении. После зависания считываю значения всех нитей из этой map. Все значения соответствуют выходу из обработчиков, т.е. ни одна из нитей в io_service не была заблокирована при выполнении обработчика.
Recv-Q = 129
Send-Q = 0
Вскоре после зависания дискрипторы файлов процесса вообще перестают обновляться, все сокеты в состоянии CLOSE_WAIT.
strace показывает, что зависает на futex():
futex(0x13ce088, FUTEX_WAIT_PRIVATE, 0, NULL
и всё, больше никакого вывода.
пусто, больше никакого вывода.
При этом отдельные потоки демона, не связанные с io_service, продолжают работать (через них и считывал разную информацию после зависания).
Как бы получить стек вызовов futex()? Т.е как бы определить, после какого вызова всё на нём блокируется?
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()? Т.е как бы определить, после какого вызова всё на нём блокируется?