Краш при присоединении к базе данных

[Alexeyt89]

Если соединение с базой данных не удаётся установить, то сервер уходит в бутлуп до момента, когда сервер с БД снова пингуется. Проблема решается скидыванием materialadmin.smx в disabled на время устранения проблем. В моём случае сервер с БД расположен в другой стране и разовые краши происходят 1-2 раза в день из-за теряющихся пакетов. Бывает что игровой сервер подвисает секунд на ~5- ~15, но не крашит. Судя по крашстеку, на момент краша идёт установление соединения с базой данных (Thread 16, dbi.mysql.ext.so + 0x53276), при этом сервер зависает секунд на 20+ и затем Watchdog убивает игровой поток (SIGABRT) и сервер уходит в перезагрузку.

Можно ли устранить блокирующий фактор, который приводит к крашу или добавить таймаут на выполнение запроса для предотвращения краша сервера?

620de445-2ce2-40b9-9b6f819f-a1c25795.dmp.zip

Для воспроизведения проблемы достаточно отключить сервер базы данных.

Версия плагина: "Material Admin" (0.8.3) by Material Admin Dev Team Server: Linux 5.4.0-72-generic #80-Ubuntu SMP Mon Apr 12 17:35:00 UTC 2021 x86_64 CSGO version Protocol version 13794 [1289/1289] Exe version 1.37.9.4 (csgo) Exe build: 22:52:57 May 24 2021 (8234) (730)

[megoRU]

Точно всё обновлено SM и т.д Я бы лучше перекомпилировал под последний SM у меня была проблема с БД мне помогла это команда: apt-get install lib32z1

P. S. А вообще желательно чтобы БД была как можно ближе к серверу...

[Alexeyt89]

Сейчас эта версия: SourceMod Version: 1.11.0.6692 SourcePawn Engine: 1.11.0.6692, jit-x86 (build 1.11.0.6692) SourcePawn API: v1 = 5, v2 = 13 Compiled on: Jun 3 2021 09:29:00 Built from: https://github.com/alliedmodders/sourcemod/commit/d01c72f Build ID: 6692:d01c72f http://www.sourcemod.net/ Проблема тянется примерно с ноября, только сейчас дошли руки с ней поразбираться. А так за это время уже полностью комп под CSGO сервер сменили и несколько раз обновили все плагины. Установка БД на тот-же компьютер могла бы частично решить эту проблему, но такой возможности нет. Либы установлены.

[megoRU]

Я конечно любитель dev версии, и всего и вся. На stable SM так же?

[megoRU]

а не проще ли держать в дата хостинге?

[Alexeyt89]

Да, увы на старых версиях и на stable проблема тоже присутствует.

[BlackYuzia]

P. S. А вообще желательно чтобы БД была как можно ближе к серверу...

Это не решение, это ебаный костыль.

Просто мимокрокодил

[CrazyHackGUT]

Пишу в первый и последний раз здесь, на Гите. Много раз писал на форуме, пора продублировать и тут. SourceMod не даёт никакого контроля при работе с БД. Даётся лишь небольшой интерфейс с ручками "выполнить запрос" и "сменить кодировку". 99% крашей происходят из-за самого SourceMod и/или MySQL-драйвера. Этого даже не отрицают сами разработчики SourceMod сейчас, и у них уже год висит Issue https://github.com/alliedmodders/sourcemod/issues/1207

Мы со своей стороны это никак исправить - не можем, если краш не по нашей вине. Я Issue это пока оставляю открытым, дабы пересмотреть весь наш код, дабы убедиться, что мы нигде сами не накосячили, но, скорее всего, это уже именно Сурсмодовское. Всё основное, что находилось, давно исправлялось.

Мучать Вам нужно разработчиков SM. У меня эти краши ни разу лично не удавалось даже воспроизвести хоть в каком-то виде, к сожалению.

[Alexeyt89]

Этот баг воспроизводится если выгрузить плагин руками или закинуть плагин reloader, который при каждой смене карты выгружает и загружает все плагины. Проблема возникает даже с плагинами в которых используются только асинхронные вызовы. Дело в том, что при выгрузке плагина стек асинхронных запросов может быть не пустой. В сорсмоде все асинхронные запросы переводятся в синхронные для выгрузки плагина без ожидания. Если в этот момент нет связи с MySQL сервером, поток намертво зависает и через 20 секунд его убивает вочдог.

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

/* Mark the plugin as being unloaded so future database calls will ignore threading... */
plugin->SetProperty("DisallowDBThreads", NULL);

/* Run all of the think operations.
* Unlike the driver unloading example, we'll let these calls go through,
* since a plugin unloading is far more normal.
*/

[xMaZax]

Попробуй версию 0.8.6, скомпилируй и проверь. Так же поиграйся с параметром UseDatabaseFix