• Страница 1 из 1
  • 1
Модератор форума: Dimitro  
Краши сервера
M1sTerY
Database Developer
Доброго времени суток, совсем не давно появились краши (По непонятной причине) Нечего особого не делал, ранее аптайм сервера был более 2х суток, сейчас очень часто начал падать сервер, вот лог краша. Возможно причина в железе ? (Ну опять же повторюсь железо не менял, ранее аптайм был более 2х суток, сейчас коллапс какой-то.)

Server CRASHED !!! Start Bugreport System.
Server.log Log FILE Last 30 Lines:
2017-10-06 20:04:07 ERROR: MoveSplineInitArgs::Validate: expression 'velocity > 0.1f' failed
2017-10-06 20:04:08 ERROR: CreatureTextMgr: Could not find Text for Creature(Val'kyr Protector) Entry 38392 in 'creature_text' table. Ignoring.
2017-10-06 20:04:19 ERROR: CreatureTextMgr: Could not find Text for Creature(Val'kyr Protector) Entry 38392 in 'creature_text' table. Ignoring.
2017-10-06 20:04:29 Command: .saveall [Player: Stuff (Account: 19375) X: 10.343594 Y: -4.223463 Z: -2.428313 Map: 550 Selected none: (GUID: 0)]
2017-10-06 20:06:23 ERROR: CreatureTextMgr: Could not find Text for Creature(Val'kyr Protector) Entry 38392 in 'creature_text' table. Ignoring.
2017-10-06 20:06:24 ERROR: CreatureTextMgr: Could not find Text for Creature(Val'kyr Protector) Entry 38392 in 'creature_text' table. Ignoring.
2017-10-06 20:06:25 ERROR: CreatureTextMgr: Could not find Text for Creature(Val'kyr Protector) Entry 38392 in 'creature_text' table. Ignoring.
2017-10-06 20:06:40 ERROR: CreatureTextMgr: Could not find Text for Creature(Val'kyr Protector) Entry 38392 in 'creature_text' table. Ignoring.
2017-10-06 20:09:05 ERROR: SmartScript::ProcessAction: Entry 75150 SourceType 0, Event 29, Link Event 30 not found or invalid, skipped.
2017-10-06 20:12:13 ERROR: CreatureTextMgr: Could not find TextGroup 52 for Creature(РЎРђРўРђРќРђ) GuidLow 7290950 Entry 500162. Ignoring.
2017-10-06 20:14:36 WaypointMovementGenerator::LoadPath: creature Orgrimmar Grunt (Entry: 31416 GUID: 142622) doesn't have waypoint path id: 0
2017-10-06 20:14:36 WaypointMovementGenerator::LoadPath: creature Orgrimmar Grunt (Entry: 31416 GUID: 142621) doesn't have waypoint path id: 0
2017-10-06 20:14:36 WaypointMovementGenerator::LoadPath: creature Orgrimmar Grunt (Entry: 31416 GUID: 142619) doesn't have waypoint path id: 0
2017-10-06 20:14:36 WaypointMovementGenerator::LoadPath: creature Orgrimmar Grunt (Entry: 31416 GUID: 142620) doesn't have waypoint path id: 0
2017-10-06 20:20:53 Update time diff: 123. Players online: 4.
2017-10-06 20:25:21 WaypointMovementGenerator::LoadPath: creature Emissary of Hate (Entry: 25003 GUID: 99948) doesn't have waypoint path id: 0
2017-10-06 20:25:21 ERROR: CreatureEventAI: EventMap for Creature 500195 is empty but creature is using CreatureEventAI.
2017-10-06 20:25:21 ERROR: CreatureEventAI: EventMap for Creature 500181 is empty but creature is using CreatureEventAI.
2017-10-06 20:26:02 ERROR: Creature 8303257 (Entry: 200023) have UNIT_NPC_FLAG_VENDOR but have empty trading item list.
2017-10-06 20:33:40 Update time diff: 149. Players online: 4.
2017-10-06 20:38:28 Update time diff: 183. Players online: 4.
2017-10-06 20:41:10 Update time diff: 225. Players online: 4.

END bugtracker system.
Сообщение # 1 написано 07.10.2017 в 05:07
Ranege
Чемпион
Это не лог краша, это лог работы ядра вне зависимости был краш или не был, логи идут всегда и никаким образом с крашем не связаны в данном варианте

Добавлено (07.10.2017, 14:52)
---------------------------------------------
Т.е твой пост аналогичен вот такому тексту: "Ребята, у меня тут краш, раньше его не было, был аптайм 2 часа, может связан с железом, а может нет, но железо не менял, ничего не трогал, кто-то знает или вдруг может угадать в чём проблема?".

Сообщение # 2 написано 07.10.2017 в 14:52
M1sTerY
Database Developer


"2017-10-31 10:36:11 Update time diff: 173. Players online: 0.
2017-10-31 10:47:08 ERROR: World Thread hangs, kicking out server!
2017-10-31 10:47:09 ERROR:
/home/wow_fun/source/src/server/worldserver/Master.cpp:99 in run ASSERTION FAILED:
false
/usr/local/lib/libACE-6.0.3.so(_ZN21ACE_OS_Thread_Adapter6invokeEv+0xa6) [0x7fa024eeaf66]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8064) [0x7fa0235ea064]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fa02331f62d]"

Это с краш с другого реалма. (Стоит 4 реалма), аналогичная ошибка бывает и на других реалмах в крашах
Сообщение # 3 написано 05.11.2017 в 06:37
Ranege
Чемпион
Последний лог указывает на зацикливание(бесконечное) в ядре
Сообщение # 4 написано 05.11.2017 в 15:54
M1sTerY
Database Developer
А как исправить? есть варианты ?
Сообщение # 5 написано 06.11.2017 в 05:05
kvipka
Сержант
пожалуйста, прекрати нести чушь. Если не знаешь, что такое цикл, лучше молчи
Цитата Ranege ()
зацикливание(бесконечное)


а по теме, что за исходники, опять санвель с ACE-либой? или еще хуже, SV какой-нить древний?
Цитата
/home/wow_fun/source/src/server/worldserver/Master.cpp:99 in run ASSERTION FAILED:

смотри на эту строчку в коде, почему ассерт.
Сообщение # 6 отредактировано kvipka - Понедельник, 06.11.2017, 13:03
Ranege
Чемпион
Ты ваще безмозговый? У него фриздетектор крашит через ASSERT(false); А крашит потому, что в другом месте зацикливание. Если мозгов нету, молчал бы сам
Сообщение # 7 написано 07.11.2017 в 21:21
Stormtrooper
Командир
Assert всего лишь диагностическая процедура и она не говорит о зацикливании - она говорит о наличии или отсутствии ошибки, а уж что там за ошибка это надо код смотреть
где вы увидели зацикливание я хз

цитирую описание процедуры:
#include

void assert(expression);

Процедура assert печатает диагностическое сообщение и завершает вызванный процесс, если expression ложно, 0. Диагности-
ческое сообщение имеет форму:

Assertion failed: file , line ,

где filename - имя исходного файла, linenumber - номер строки,
которая ошибочна.
Если expression истинно (ненулевое), никакого действия не
выполняется.
Процедура assert обычно используется для обнаружения логи-
ческих ошибок в программе.
Если помог, ставь плюсик в репу :)

Сообщение # 8 написано 10.11.2017 в 22:44
Ranege
Чемпион
Ассерт то ассертом, но когда будут задействованы мозги? Как прогеру жить то без них, я не понимаю
Сообщение # 9 написано 11.11.2017 в 02:11
kvipka
Сержант
Цитата Ranege ()
Ассерт то ассертом, но когда будут задействованы мозги? Как прогеру жить то без них, я не понимаю

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

А цикл в коде только при while и for, так что иди нахуй отсюда, пока свою хотя бы одну извилину не задействуешь.

А если по теме, собирай в дебаг режиме и смотри полноценный крашлог, со списком стак-вызовов, где и увидишь реальную причину краша в 1 из потоков.
Сообщение # 10 отредактировано kvipka - Суббота, 11.11.2017, 11:30
Re3os
Скаут
Цитата M1sTerY ()
А как исправить? есть варианты ?
1-ый шаг Есть варианты,обратитесь кому нить в лс,отдайте вы каких нить 300 рублей,что б вам все сделали.
2-ой шаг,муторный пересобираем cmake с флагом RelWithDebInfo,если у вас такого нет(old code),тогда просто debug.
3-ый шаг,постим фул лог краша,желательно на pastebin.
Сообщение # 11 написано 11.11.2017 в 17:25
Ranege
Чемпион
Цитата kvipka ()
тебе уже ответили, бестолочь. Как происходит краш в 1 из потоков, фриздетектор завершает все потоки, чтобы сервер мог перезагрузиться (если есть рестартер конечно).
Цитата kvipka ()
пожалуйста, прекрати нести чушь. Если не знаешь, что такое цикл, лучше молчи
ты, тупой человек, а почему у него фриз детектор то роняет все потоки???????Мозгов нету, повторяю, не влезал бы в тему
Сообщение # 12 написано 11.11.2017 в 17:38
dimazons1233211
Скаут
UP
Сообщение # 13 написано 30.09.2019 в 19:35
p620
Маршал
Цитата dimazons1233211 ()
UP


Зачем? В теме опубликовано слишком малое количество информации, чтобы сделать какие-либо выводы, кроме тех, что уже были сделаны пользователем Ranege. Если хотите помощи - читайте здесь пятый пункт дополнительных правил и создавайте тему, содержащую всю необходимую для полноценной диагностики информацию (ревизия ядра, отладочный журнал).
Сообщение # 14 написано 01.10.2019 в 19:26
kvipka
Сержант
Цитата Ranege ()
ты, тупой человек, а почему у него фриз детектор то роняет все потоки???????Мозгов нету, повторяю, не влезал бы в тему


потому что, это единственная задача, которую выполняет фриздетектор, убивает все потоки и завершает работу ПО.

удивлен?
Сообщение # 15 отредактировано kvipka - Среда, 02.10.2019, 09:55
Ranege
Чемпион
Цитата kvipka ()
тебе уже ответили, бестолочь. Как происходит краш в 1 из потоков, фриздетектор завершает все потоки


По твоему если произошел краш(было брошено исключение, которое не ловится) в одном из потоков, то процесс не упадет? Или может ты имел в виду, что исключение обрабатывается, но фриздетектор все равно завершает потоки?

А ну ка, поподробней тут плз если можно, конечно. Интересно послушать.
Сообщение # 16 написано 04.10.2019 в 20:15
kvipka
Сержант
Запросто.
Вот пример : сделал систему гильдий и гильдварс.
Запустил константовый итератор, ну например пробежаться по конкретной гильде с бродкастом чего-то. В это же время (ошибка в алгоритме) происходит удаление кого-то из этой ги, и соответственно из итератора (не до запуска итератора, не после, а прям в нем). Что произойдет ?
Ничего не произойдёт. Поток гильдменеджера зависнет, не упадет, просто повиснет. Никаких неверных исключений не будет, но и итератор константовый не завершится.
В итоге фриздетектор, если включен maxcoretime (или как там пишется) будет ждать таймер, после чего завершит процесс сервера. Если в конфиге 0 - будет бесконечный фриз
Только для этого он и сделан. Определить проблему это не поможет, а вот дать серверу ребутнуться - да.

Добавлено (04.10.2019, 22:58)
---------------------------------------------
Это из тех ошибок, что не приводят в крашам. Но они редкость, и возникают как правило либо совсем в экстремальных условиях, либо, что вероятно в 99% случаев - при вводе новых фишек, классов, менеджеров, когда код ещё не до конца испытан.

Ниже рассматриваются обычные ошибки, двух видов :
- при долгой обработке, когда функция ждёт отклика от других менеджеров, особенно часто это при ожидании СИНХРОННОГО запроса от базы данных.Сервер тупо ждёт, пример - когда игрок кликает на почтовый ящик.
-второй тип - самый простой, обычное необработанное исключение.

В обоих типах сервер сам крашнется, и при включенном гдб будет крашдамп с указанием на причину. (Включая старые "нечитаемые" дампы, где крашили сервер при помощи символов в чат, ТК символы сервер записывает как uint число, и понять было трудно, что речь о юникоде 11+, но писал же)
Но есть одно НО :
В первом типе, когда сервер таки крашнется с задержкой, если включен coremaxtime со значением меньше, чем операция "подвисшего" потока завершится - фриздетектор принудительно его завершит, как и остальные потоки и весь процесс сервера, и как итог - крашдампа вы не получите.
Сообщение # 17 отредактировано kvipka - Пятница, 04.10.2019, 22:59
p620
Маршал
kvipka, не сочтите за оскорбление, но содержание Ваших заблуждений и рвение, с которым Вы их отстаиваете, указывают на Вашу абсолютную несовместимость с работой в какой-либо области, так или иначе связанной с точными науками. Вам следует фундаментально изменить свой подход к изучению нового материала или вовсе оставить поприще, дабы не публиковать на форумах вроде этого посты, прочтение которых у здравомыслящих людей вызывает гримасу боли и презрения.
Цитата kvipka ()
Запустил константовый итератор, ну например пробежаться по конкретной гильде с бродкастом чего-то. В это же время (ошибка в алгоритме) происходит удаление кого-то из этой ги, и соответственно из итератора (не до запуска итератора, не после, а прям в нем).


Конвенционный итератор - ни что иное как форма указателя; переменная, призванная содержать или "оборачивать" адрес некоторой области памяти. Вы его не "запускаете", Вы просто используете его в различных алгоритмах таким образом, чтобы он указывал на некоторый элемент соответствующего ему контейнера. В целях сохранения когерентности предлагаемого Вами примера рассмотрим актуальную версию имплементации гильдий в стандартном TrinityCore ветки '3.3.5'. Класс 'Guild', определяемый в рамках такой имплементации, объявляет защищенное поле 'Members m_members;', предназначенное для хранения информации о каждом ее члене (при этом отметим, что идентификатор 'Members' имеет следующее определение: 'typedef std::unordered_map<uint32, Member*> Members;').
Цитата kvipka ()
В это же время (ошибка в алгоритме) происходит удаление кого-то из этой ги, и соответственно из итератора (не до запуска итератора, не после, а прям в нем).


Если предыдущие Ваши утверждения еще можно было объяснить применением специфических метафор, с этого фрагмента начинается форменное безумие.
Удаление члена из гильдии "в это же время" возможно только из другого потока. В рамках такого удаления непременно будет вызвана какая-то из перегрузок метода 'erase' (по ключу или по итератору) относительно объекта 'm_members' ("удалить из итератора" ничего нельзя!). Для дальнейшего рассмотрения данного примера мы предположим, что пишущий (удаляющий) и читающий (итерирующийся) доступ к контейнеру надлежащим образом синхронизированы (на уровне вызова методов контейнера, что по умолчанию, кстати, не так), иначе ничто не помешает читающей стороне "увидеть" контейнер с нарушенными инвариантами, что ничем хорошим потенциально не закончится.
Цитата kvipka ()
Что произойдет ? Ничего не произойдёт. Поток гильдменеджера зависнет, не упадет, просто повиснет. Никаких неверных исключений не будет, но и итератор константовый не завершится.


Еще один пример пустого резонерства. В рамках нашей гипотетической ситуации возможны всего два варианта стечения обстоятельств, в зависимости от того, равны ли удаляемый и обрабатываемый в настоящий момент чтения итераторы. Если нет - проблем не возникнет, поскольку сохранность итераторов, не соответствующих удаляемым, гарантируется для '::std::unordered_map'. Однако, если ответ "да" - произойдет использование инвалидированного итератора (разыменовывание или инкременция), что приводит к возникновению т.н. неопределенного поведения (Undefined Behaviour, UB). Как известно, никаких предсказаний относительно поведения программы, чье исполнение приводит к возникновению такового поведения, делать просто нельзя ("conforming implementation" вольна делать все, что ей будет угодно, в т.ч. абсолютно ничего; реальное поведение, однако, будет сообразно ее внутреннему устройству и в данном случае скорее всего сходно с тем, что возникает при использовании порченного указателя). Но я даже представить не могу, что заставило Вас считать, что "не произойдет ничего, и читающий поток зависнет". Фразу "итератор константовый не завершится" я, пожалуй, комментировать просто не буду, ибо содержание ее абсурдно.
Цитата kvipka ()
Ниже рассматриваются обычные ошибки, двух видов :
- при долгой обработке, когда функция ждёт отклика от других менеджеров, особенно часто это при ожидании СИНХРОННОГО запроса от базы данных.Сервер тупо ждёт, пример - когда игрок кликает на почтовый ящик.
-второй тип - самый простой, обычное необработанное исключение.


Откуда Вы вообще взяли такую классификацию? Не удивлюсь, если самостоятельно изобрели. Спросил бы, какими рассуждениями руководствовались, но Вы ведь не сознаетесь.
В отсутствии знаний нет ничего зазорного, как и в их поиске, однако в их фальсификации и, тем более, распространении результатов такой фальсификации, определенно есть. Так что рекомендую Вам, kvipka, досрочно прервать эту сессию самоунижения и идти читать профильную литературу, если Вы действительно заинтересованы в том, чтобы разбираться в обсуждаемом (и многих других) вопросе.
Сообщение # 18 написано 06.10.2019 в 02:08
kvipka
Сержант
я боюсь вы в корне не читали содержимое моего поста, и решили брать инфу "из водуха"

вот пример подробный :
Код
void GuildMgr::StopAllGuildWarsFor(ObjectGuid::LowType guildId)
{
    for (GuildWarsHistoryContainer::const_iterator itr = _guildWarHistoryStore.begin(); itr != _guildWarHistoryStore.end(); ++itr)
    {
        bool firstGIsAttacker = itr->second.attackerGuildId == guildId && itr->second.winnerGuild == "";
        if (firstGIsAttacker)
            StopWarBetween(guildId, itr->second.defenderGuildId, itr->second.defenderGuildId);

        bool secondGIsAttacker = itr->second.defenderGuildId == guildId && itr->second.winnerGuild == "";
        if (secondGIsAttacker)
            StopWarBetween(guildId, itr->second.attackerGuildId, itr->second.attackerGuildId);
    }
}


Вот константовый итератор, и внутри его идет остановка войны между 2 конкретными гильдиями.
С чего вы решили взять вообще, что речь о "typedef std::unordered_map" ?

Про самую важную уязвимость эмулей с прямой зависимостью от синхронного запроса к бд вы вообще умолчали, и спросили про мою классификацию.
Я был лучшего о Вас мнения, статью целую расписали против меня, только даже не удосужились прочесть мой пост. Зато словечки модные разучили и впихиваете их везде. Ну вовжопка, чего еще стоило ожидать.
Сообщение # 19 отредактировано kvipka - Воскресенье, 06.10.2019, 10:44
p620
Маршал
Цитата kvipka ()
Вот константовый итератор, и внутри его идет остановка войны между 2 конкретными гильдиями.


Вы вменяемы вообще, или где? Что по-Вашему значит "внутри итератора идет остановка"? Вы решили не читать то, что я Вам написал?
Цитата kvipka ()
С чего вы решили взять вообще, что речь о "typedef std::unordered_map" ?


Я объяснил, "с чего решил взять", опять же, читайте пожалуйста внимательней. Как я могу рассматривать Ваш пример, если у меня к нему нет доступа? Хотя в данном случае это роли не играет: он, по всей видимости, так же основывается на какой-то STL map'е, а потому все написанное имеет силу, поскольку применимо для любых ассоциативных контейнеров стандартной библиотеки.
Цитата kvipka ()
Про самую важную уязвимость эмулей с прямой зависимостью от синхронного запроса к бд вы вообще умолчали, и спросили про мою классификацию.


Потому что комментировал только то, что имело отношение к теме обсуждения.
Так или иначе, спор наш продуктивным не будет, поскольку Вы, очевидно, заинтересованы лишь в поддержании собственного "экспертного" вида, а потому продолжите соскальзывать с темы обсуждения, опускаться до пассивно-агрессивных выпадов в адрес всех с Вами несогласных и фанатично отстаивать собственные заблуждения, вместо того, чтобы потратить несколько минут на проверку подлежащей информации.
Сообщение # 20 отредактировано p620 - Воскресенье, 06.10.2019, 19:23
  • Страница 1 из 1
  • 1
Поиск: