Linux C++ сервер: не могу получить колстэк

Не знал куда кинуть тему, если что - перенесите куда нужно

Имеется дедик на CentOS 6, на котором бежит сервер на C++. Сервер - это онлайн-игра. Из сторонних библиотек используется только Boost. И сервер и Boost собраны в debug-режиме. Компилятор - GCC 7. Некоторое время назад я начал пользваться Boost.Stacktrace (https://www.boost.org/doc/libs/release/doc/html/stacktrace.html), и все было хорошо - при падении дампился stacktrace, после чего я получал человекопонятный колстэк, и быстренько находил источник проблемы. Но вот недавно обнаружился трудновоспроизводимый баг (краш случается раз в несколько дней при постоянной игре в 500 ботов), который по каким-то причинам не дает нормального колстека, хотя и сам сервер, и буст собраны в дебаге.

Использование Boost.Stacktrace сделано точно по примеру из https://www.boost.org/doc/libs/1_69...ting_started.handle_terminates_aborts_and_seg - и при прочих багах это все прекрасно работало. Я получал список адресов, которые сохранял в stack.txt и прогонял через такой баш-скрипт:

Код (Text):

1. while read line; do
2.     addr2line "$line" --exe="./server"
3. done <stack.txt
4.  

Скрипт выдавал список имен исходников и номера строк. Все было хорошо, и в отчете этажей было штук 15-20. Но вот с текущим багом я вижу слещующее:

Код (Text):

1. /var/www/.../stacktrace_guard.cpp:17
2. libpthread.o:0
3. ??:0
4. /var/www/.../stacktrace_guard.cpp:18
5. libpthread.o:0
6.  

Единственное место, которое распозналось - это сама функция дампа стэка (stacktrace_guard.cpp):

Код (C++):

1.  
2. void signal_handler(int signum)
3. {
4.     ::signal(signum, SIG_DFL);
5.     boost::stacktrace::safe_dump_to(filename.c_str());
6.     ::raise(SIGABRT);
7. }

Очень нужно найти хотя бы просто место падения (с причинами разберусь). Все собрано в дебаге, можно накрутить любые опции GCC, поставить любые тулзы, и т.д. Можно дождаться очередного падения сервера. Почему такой странный колстэк, и какие вообще будут идеи? Заранее спасибо.

 

может стек поломан и Stacktrace не может раскрутить адреса?
в gcc должно быть что-то, наподобие студийной "stack frame run-time error checking"

 

RedLord, сколько лет сколько зим А как он может быть поломан? Имеешь в виду что в результате бага что-то криво пишется в локальные переменные за пределы выделенного под них места, и таким образом перетираюся адреса возврата?

 

Да.
Может буфер переполняет.
Или арифметика указателей приводит к кривому адресу.
Я бы прогнал код через статический анализатор.
И если многопоточная аппликуха - просмотрел места, где потоки могут друг дружке гадить. Может быть, race condition

 

Посоветуй, какой сейчас самый кошерный?

 

На вкус и на цвет... ))
Pvs-studio - неплохой
Если дебаг сборка, может ее под отладчиком запустить )))
Или чтобы система не убивала приложение, а останавливала, чтобы отладчиком приаттачиться и посмотреть

 

RedLord, виндовая дебаг-сборка адски-медленная, там сервак 20 ботов с трудом вытягивает. А в линуксах я такое не умею. У меня голая ось с SSH, гуечков нет. Какие тут есть варианты?

 

Включи что бы кордамп создавался https://www.akadia.com/services/ora_enable_core.html и потом в нем смотри уже проблему

 

в линухах - не силен. но gdb через ssh точно работает
и можно попробовать что-нибудь такое:
https://stackoverflow.com/questions...-process-a-k-a-just-in-time-debuggin/22509089

 

да, хороший статический анализатор... из бесплатных юзал cppcheck, но он на голову слабее pvs'а...

именно, тут без gdb не разберешься...

 

можно из студии подключиться к gdb
https://blogs.msdn.microsoft.com/vcblog/2017/04/11/linux-development-with-c-in-visual-studio/

 

Запускаете ваш процесс из-под gdb в консоли и ждёте крэша.
Дальше:

Код (Text):

1.  
2. thread apply all bt
3.  

Ну и так далее.По вашему репорту сделаю предположение, что, скорее всего, портится память, поэтому вы и получаете битый стектрейс.
Думаю, было бы полезно ещё через valgrind прогнать, чтобы задетектить запись/чтение по некорректным адресам. Но всё это меееееееедленно будет работать.

 

o12047207, все сделал, получлось. Понадобилось еще вкурить вот это https://www.centos.org/forums/viewtopic.php?t=43577 , может кому пригодится. Буду ждать краша.

А если не из консоли, а из upstart php watchdog-а? А то у меня провайдер не способен работать без единого разрыва, боюсь что краша я не дождусь - SSH отвалится по дороге.

 

Ну у вас есть возможность:
1. запустить GDB как сервер.
2. запустить локальный терминал, и тогда отрубание коннекта некритично. Просто после логина подрубаетесь к этому терминалу:

Код (Text):

1.  
2. screen /bin/bash
3.  

делаете что хотите, дальше чтобы отрубиться жмёте Ctrl-A D
при этом, в процессах он остаётся:

Код (Text):

1.  
2. sadko  3249  0.0  0.0  19468  3212 ?        Ss   17:57   0:00 SCREEN /bin/bash
3. sadko  3250  0.2  0.0  17444  8108 pts/29   Ss+  17:57   0:00  \_ /bin/bash
4.  

Получаем перечень скринов:

Код (Text):

1.  
2. screen -list
3. There is a screen on:
4.         3249.pts-20.sadko (Detached)
5. 1 Socket in /run/uscreens/S-sadko.
6.  

Ну и подключаемся:

Код (Text):

1.  
2. screen -r 3249.pts-20.sadko
3.  

 

У нас так народ удалённо по спутнику с 20%-ными потерями пакетов и дикими пингами заказчикам софт на серваки закачивал и разворачивал. Так что с домашними провайдерами 100% сработает.

 

_DEN_, что за игруха?

 

_DEN_, центик весьма годная дистра.. но почему 6ка??? вроде, она ужо не поддерживается Сообществом.

 

Всем спасибо за советы. Пока что жду чтобы сервак упал с core dump-ом. Со среды пока не падал.

RedLord, ты еще спроси когда релиз - сразу тапком кину После релиза скину линк)

Мне тоже нравится 7-ку ставил, но оказалось очень непривычно, поменяли всякие штуки по непонятным для меня причинам. Работу с сервисами переделали. Upstart-скрипты переделали. Опять заново всему учиться А я вообще не люблю всю это конфигурятню, я хочу программировать, а не патчить KDE под FreeBSD Основная поддержка закончилась, критические обновления будут до ноября 2020-го.

Не совсем понял. Вижу в гугле что TSan это -fsanitize=thread, а ASan это -fsanitize=address. То есть оно либо-либо? Или как?