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

https://github.com/google/sanitizers/wiki

--- Сообщение объединено, 15 фев 2019 ---

кстати, с этой санацией может быть даже больше трабл, чем пользы == лучше уж в проге покидать меток и логировать их: если падуха в самой проге, то по меткам чётко можно место определить; а если во внешней либе, то определить в акой именно.

 

TermoSINteZ, если в задаче имеет место быть минимальная терпимость к лагам, то отладка становится весьма Весёлой

 

Любая система без логов - выстрел себе в ногу. Иногда некоторые процессы только с помощью логов отладить и удаётся.

 

С точки зрения теории управления, отсутствие информации для сверки с контрольными параметрами это отсутствие управления со стороны субъекта, который объектом пытается управлять. В нормальных системах есть логи, и есть протоколы поддающиеся автоматической обработке и анализу. Система построенная без этого слабо поддается развитию, поэтому мы здесь и видим ТС с его вопросом.

 

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

 

а что ты имеешь в виду под "автоматической обработкой и анализом"?

 

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

Так что:
1. Структурированные логи для возможности навигации.
2. Протоколирование ключевых действий, переходов состояний, команд. Здесь можно будет найти отклонения и сопоставить с логами. Тонны логов для анализа читать нереально, поэтому нужны протоколы - время, тип события, параметры. В основном это все цифры, которые можно с чем-то сопоставлять, ожидаемые контрольные значения.

 

im., по пункту 2. Подскажи пожалуйста маршрут ссылок, слов для гугла, всё что угодно для самообразования.

 

im., Вопрос по-большей части упирается не столько в автоматику и тоннаж логов, сколько в правильном выборе критериев оценки заданной системы.. именно эти критерии и определяют коэффициент сужения области поиска ошибки на итерацию.

 

q2e74, https://storage.googleapis.com/dotu-154621.appspot.com/20040623-DOTU.pdf
Вот старенькая бесплатная версия, сейчас книжки поновее есть.
Там достаточно странно подается материал, часто встречается уход от темы, на это нужно забить.
С теориями управления дела туго обстоят, так как людей воспитывают так, будто это рассказы про муравьев у Вербера, никому не нужны люди способные мыслить со знаниями управления, всем дают знания как рабочей единице в будущей социальной системе. Поэтому литературы мало, вот эта собраны из советских работ, там даются знания абстрактного мышления в области управления. Достаточно прочитать 30-50 страниц, для базового понимания, это уже позволит проектировать предсказуемые системы.

--- Сообщение объединено, 18 фев 2019 ---

Нет.

 

im., кстати, как ты решаешь вопрос безопасности при большом потоке логов?

 

UbIvItS, легко решаю, безопасность обеспечивает отдельной слой абстракции не пересекающийся с полезной логикой

 

а подробней, пожалуйста.

как это возможно?

 

Ну как-то не знаю. По мне это как-то не убедительно. Через край избыточно и натянуто.

а вот это убедительно и интересно.

 

q2e74,

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

 

Кароч посоны, ситуация конечно дурная, но сервер сцуко так и не падает, так что возможно имевшийся дефект я случайно и починил. Но всем спасибо за советы, я их взял на вооружение. Если проблема воспроизведется - отпишусь в этом треде.

 

в глобальном плане верно сказано. но с линем имеет место быть весьма чудовищная ситюёвина: он склёпан из проектов весьма различного качества + различной скорости развития == подавляющее число дистр в сущности не могут дотянуть даже до бетки иль имеют старую и довольно скудную оснастку (взять тот же центик, на дедик его пакетов хватает, а вот ставить его десктопом требует поднимать кучу вещЁвЪ из сорцев). на куче легаси машин успешно продолжает пахать хрюн, для линя же такое долгожительство дистры практически не имеет смысла в силу чрезмерной муторности обновления. короче, пока десктоп из линя весьма не-ахти