GhostOne Крашик

Имееься GHostone + Boost 1.40.
Дело в том, что в боте куча кода но переодически (раз в 15-30 часов) он вылетает, что касается логов то на каждом краше они разные.
Я уверен что в ходе модификации бота на начальных стадиях, в коде была допущена ошибочка, что теперь приводит к его крашу.
Возможности пересматривать последний код нету, так как его слишком много.
Входе компиляции (Release MYSQL) варнов/ошибок вообще нет, сборка бота проходит гладко.

Вопрос наверно больше к Миру, чем ты пользуешся (каким дебагером или я хз) для отлова такого рода ошибок?
(ответ жду не в двух словах )

Во вкладки отладка нажми присоединится к процессу
выбери бот
должно быть вот так примерно


зы заранее лучше откомпилировать в дебаг мускул
При вылете бота, в окне получишь инфу о вылете, а точнее его причину

компилирую ботов я на win а уже готовый исходный код я переношу на линукс и там пересобираю и запускаю бота (ну и дальше он там хостит).
возможно есть еще способы.

Ну собственно варианта 2 всего, либо ты у себя на win дебажишь через Visual Studio( меня 3 раза выручало ), либо осваиваешь дебаггер в unix ( gdb ). Попробую предположишь что ошибка по идее мелкая, то если есть желание, запускаешь VS, устанавливаешь в свойствах проекта правильную директорию отладки, и запускаешь через отладку, в момент краша получишь всю необходимую инфу, либо тоже самое проворачиваешь с gcb. По gcb инструкцию не дам, т.к. все ++ боты у меня не крашились, либо я знал где косяк. А One я собирал в виртуалках с WinXP, через VS.

Если та бага про которую я думаю... Ибо так же 15-30 часов летало. Я выяснил при каких случаях вылетает, а при каких месяц стоит и хоть бы хны. Моя проблема была связана с прерыванием запросов к MySQL, если была парочка потерей соединений, то всё норм, а если 15-20, то через н-ый промежуток времени жди вылета. Где в коде проблема я не знаю, такое ощущение что где-то буфер переполняется. В общем, избавился я от вылетов, тем образом что организовал стабильное соединение между ботом и БД, костыль грубо говоря воткнул. Глюк на сборке с начальным кодом от ghostbrt.

Есть реальный случай, суть такая, бот же получается админов и доступ их в разные векторы. Если происходит сбой мускуля, на какой то момент может упасть список админов, а списка их доступов нет. Тогда при проверке админа и его доступа, найдется элемент в списке админов, а при обращениии к списку доступа - выпадет краш, как обращение к несуществующему элементу массива

Вышесказанное вспыло как раз при дебаге и является по сути косяком архитектуры.

Т.к. с++ хреного знаю, и вообще не программист. Но как понял вставить костыль можно, организовав кеш, который подсовывается моментом боту если проблемы при соединении с БД. Если как вы говорите это косяк архитектуры.

Если я не прав, прошу прощения.

если ты "Гон евей" то я посмотрел в конфиге до момента краша никаких ошибок с mysql не было (но я понял о чем ты так как тоже стыкался с крашем после таких ошибок, но мне хватало и 20 минут).

а можешь скринами или подробней (проект=>свойства ghost).

и вот еще такой вопрос.
на пк установлено малое к-во оперативной памяти (2gb), при запуске гхоста он жрет ~50mb, но при длительной работе обьем увеличивается, ето нормально? последний раз когда смотрел максимум доходило до 340мб (возможно было бы и больше но так как краши то максимальное значение не удалось посмотреть).
мефикс, сколько у тебя было на брт?

Ну да.. У меня последнее прерывание с бд было 14 часов назад. И потом отвалился. Было как-то так. Темболее не все запросы выдают в лог эту ошибку, т.к. при добавлении новых запросов в базе кое где вывод в лог файл закомментирован.

2 gb мало? Пффф... У тебя там кучу глюков, модифицируй по ghost++ все критичные ошибки.
2 сервера - 130 мегов 7 дней.
6 серверов - 180 мегов. 2 недели
9 серверов - 250 мегов онлайн 25 игр одновременно, аптайм 2 месяца

Написанное немного завысил, но больше 220 мегов оперативы занятой я никогда не видел. Это при том что у меня пишутся абсолютно все репы, и включён лог файлов. + я из брт кое что не выдернул. Оптимизацию по памяти вообще не производил.

Сейчас аптайм небольшой, т.к. при ддосах иногда вырубаю бота, на минут 5, чтобы потом базу от дисконов не чистить. А так стояло раньше и по 2 месяца, при стабильной соединении с БД. И это на винде кстати...

PS: Предвидя следующий вопрос. Что я делал. Ничего... от начала создания ghostbrt и отхода от ghost++, прошёлся по всем фиксам ghost++ (правда пока не до последней ревизии) и поправил код предлагаемый в фиксах ghost++, учитывая только те исправления которые считаю нужными, и которые надо внести в ghostbrt, т.к. некоторые исправления применённые в ghost++, в брт реализованы совершенно по другому. Попробуй у себя в бота впилить профайлер, должен показать, где выполняются долго процессы, и там же скорее всего оператива жрётся, т.к. образуется цикличность.(не забудь перед использованем профайлера код забекапить, а то потом заманаешься чистить от логов профайлера.)

наверно сначало есть смысл занятся крашем, потом посмотреть сколько продержится бот и к-во оперативной памяти.
если она со временем будет увеличиватся то нужно что-то делать.

К примеру, вчера при 11 играх одновременно у меня было 132 мега оперативы, сейчас при одной 60 мегов... конечно многовато. Я не смотрел где у меня сколько памяти съедается.

Попробуй определить у тебя оператива возвращается к исходному или нет. Запусти бота, посмотри сколько оперативы жрёт. Доведи его чтобы было 5-10 игр одновременно, и выключи хост игр. Подожди пока все доиграют, и опять посмотри сколько хавает оперативы, если ощутимо больше, значит где-то задница. Опять же вносил ли фиксы к mysql коннектам, которые не закрываются? а то в One как и в brt, был этот глюк, который требовал фикса. У меня обычно к БД ломятся 26-32 запроса. не больше.

ТАк и сделаю сегодне/завтра отпишусь.

Краш и утечка памяти могут быть не связаны вообще, вариантов и того и другого выше крыши. Как Mefix отметил там легко допустить утечку при работе с мускулем. Но опять же, краш и утечка вещи не обязательно связные.

Я учитываю до сих пор, что вылетает из-за проблем коннекта с мускулем, в т.ч попытка добавления несуществующих колонок, или по длинне вносимого в поле, мускуль реджектит это, а в боте из-за недоработок этот ответ некорректно обрабатывается, и остаётся зависшим. Так же легко посмотреть, закрываются ли запросы, если подключения к мускулю, стоят больше 2-х часов, значит 100% какие-то сессии, или рвутся, и мускуль их не завершает(это относительно нормально, ибо могли не настраивать параметр завершения долгих сеансов), и ещё второе, если опять стоят больше 2-х часов, то бот не закрывает свои открытые сессии, это уже критично, из-за этого у меня в 70% случаев тоже был краш, пока не поправил 3-4 запроса, которые грешили тем что после окончания сессии она не закрывалась.

В итоге если у вас есть сессии которые не закрываются, в итоге получаем, при настройках мускуля по умолчанию(ограничение 150 сессий), бот работает 15-30 часов, было много игр, через 5 часов стало 90 сессий, через 10 часов, стало 130-140 сессий, через 13- часов уже 150, всё! Мускуль не принимает новые сессии, получаются запросы на которые мускуль боту отвечает полной пофигистикой, в следствии просиходит краш бота. А почему 30 часов стоит? Или было мало игр, возможно часть запросов вы ручками убили, или мускуль сбросил коннекты эти, т.к. вроде сбрасывает автоматом раз в 24 часа. Кстати боту тоже не нравится, если его запросы идущие к мускулю и с которыми он работает убить вручную, бот потом опять вылетает.

PS: Опять же повторюсь я не программист, это то как я примерно понимаю работу в боте С++ с Mysql(причём понимаю что эта теория где-то близко, но ой какая ламерская)

И ещё я сторонник того мнения, если не понимаешь где глюк, попытайся устранить все узкие места, чтобы связки работали как отче наш, и другие сервисы которые не отлаживаешь, работали так же. В итоге тут уже можно адекватно отследить где, что глючит. Опять же на этом моменте, попробуйте не юзать в ghostOne оболочку если это возможно(вроде да), опять же исключаются глюки оболочки. Только cmd, только хардкор


Закрасил чтобы за рекламу не посчитали.

сессия - коннект ?
в базе я выставил сразу 600сек - и обрыв, потому что там столько слипов появляется.
+ нашел тему на коделайне по-поводу открытых коннектов, с каждой игрой они увеличивались на 10, так до ходило до 140 и я получал надпись "сервер ушел в запой", после чего добавил строкук в бнет и теперь значение не выше 40 ("dbstatus").
оболочкой тоже не пользуюсь.

мир напиши подробней по-поводу дебага.

Да сессия-коннект, просто где то забыл исправить.

Там в bnet.cpp вроде в нескольких местах надо было править. Сейчас уже не вспомню. Хм... Сейчас только заметил что у меня сессии больше 3-х минут не держатся... Хм... Пофиксил то не знама что. Кстати 6 игр 116 мегов.

Rob, если ты уже правленную версию GhostOne юзаешь, но не сильно. Выкинь, что там у тебя, может я выявлю какую закономерность. Мне токо экзешники надо. Запушу на хост какой-нито TD-шки, или ещё чего, может чего нарою.

Вот мои сессии если что:




ЗЫ: школьников с попыткой взлома прошу не беспокоить, мускуль в инет не смотрит .

но тебе придется добавлять / редачить таблицы.
днем брошу тогда с таблицами (

Ок.. Главное чтобы не получилось случаем что у меня не падает ))). А то бывает.... Вчера роутер который валялся 3 года, и последний раз был в жёском ребуте с dd-wrt, включился, без работающего веб-интерфейса, но раздавая инет по вайфай! Пффф.