|
|
Модератор форума: Dimitro |
Форум TrinityCore [TrinityCore] Help Краши сервера (Непонятки, хелпаните) |
Краши сервера |
Доброго времени суток, совсем не давно появились краши (По непонятной причине) Нечего особого не делал, ранее аптайм сервера был более 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.
EvolutiON-WoW 3.3.5 - Тык
Видео сервера EvolutiON-WoW.Ru Часть 1. Видео сервера EvolutiON-WoW.Ru Часть 2.
Сообщение # 1 написано 07.10.2017 в 05:07
|
Это не лог краша, это лог работы ядра вне зависимости был краш или не был, логи идут всегда и никаким образом с крашем не связаны в данном варианте
Добавлено (07.10.2017, 14:52)
Сообщение # 2 написано 07.10.2017 в 14:52
|
"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 реалма), аналогичная ошибка бывает и на других реалмах в крашах
EvolutiON-WoW 3.3.5 - Тык
Видео сервера EvolutiON-WoW.Ru Часть 1. Видео сервера EvolutiON-WoW.Ru Часть 2.
Сообщение # 3 написано 05.11.2017 в 06:37
|
Последний лог указывает на зацикливание(бесконечное) в ядре
Сообщение # 4 написано 05.11.2017 в 15:54
|
А как исправить? есть варианты ?
EvolutiON-WoW 3.3.5 - Тык
Видео сервера EvolutiON-WoW.Ru Часть 1. Видео сервера EvolutiON-WoW.Ru Часть 2.
Сообщение # 5 написано 06.11.2017 в 05:05
|
пожалуйста, прекрати нести чушь. Если не знаешь, что такое цикл, лучше молчи
а по теме, что за исходники, опять санвель с ACE-либой? или еще хуже, SV какой-нить древний? Цитата /home/wow_fun/source/src/server/worldserver/Master.cpp:99 in run ASSERTION FAILED: смотри на эту строчку в коде, почему ассерт. |
Ты ваще безмозговый? У него фриздетектор крашит через ASSERT(false); А крашит потому, что в другом месте зацикливание. Если мозгов нету, молчал бы сам
Сообщение # 7 написано 07.11.2017 в 21:21
|
Assert всего лишь диагностическая процедура и она не говорит о зацикливании - она говорит о наличии или отсутствии ошибки, а уж что там за ошибка это надо код смотреть
где вы увидели зацикливание я хз цитирую описание процедуры: #include void assert(expression); Процедура assert печатает диагностическое сообщение и завершает вызванный процесс, если expression ложно, 0. Диагности- ческое сообщение имеет форму: Assertion failed: file , line , где filename - имя исходного файла, linenumber - номер строки, которая ошибочна. Если expression истинно (ненулевое), никакого действия не выполняется. Процедура assert обычно используется для обнаружения логи- ческих ошибок в программе.
Если помог, ставь плюсик в репу :)
Сообщение # 8 написано 10.11.2017 в 22:44
|
Ассерт то ассертом, но когда будут задействованы мозги? Как прогеру жить то без них, я не понимаю
Сообщение # 9 написано 11.11.2017 в 02:11
|
Ассерт то ассертом, но когда будут задействованы мозги? Как прогеру жить то без них, я не понимаю тебе уже ответили, бестолочь. Как происходит краш в 1 из потоков, фриздетектор завершает все потоки, чтобы сервер мог перезагрузиться (если есть рестартер конечно). А цикл в коде только при while и for, так что иди нахуй отсюда, пока свою хотя бы одну извилину не задействуешь. А если по теме, собирай в дебаг режиме и смотри полноценный крашлог, со списком стак-вызовов, где и увидишь реальную причину краша в 1 из потоков. |
1-ый шаг Есть варианты,обратитесь кому нить в лс,отдайте вы каких нить 300 рублей,что б вам все сделали.
2-ой шаг,муторный пересобираем cmake с флагом RelWithDebInfo,если у вас такого нет(old code),тогда просто debug. 3-ый шаг,постим фул лог краша,желательно на pastebin.
Сообщение # 11 написано 11.11.2017 в 17:25
|
тебе уже ответили, бестолочь. Как происходит краш в 1 из потоков, фриздетектор завершает все потоки, чтобы сервер мог перезагрузиться (если есть рестартер конечно).
Сообщение # 12 написано 11.11.2017 в 17:38
|
Зачем? В теме опубликовано слишком малое количество информации, чтобы сделать какие-либо выводы, кроме тех, что уже были сделаны пользователем Ranege. Если хотите помощи - читайте здесь пятый пункт дополнительных правил и создавайте тему, содержащую всю необходимую для полноценной диагностики информацию (ревизия ядра, отладочный журнал).
Сообщение # 14 написано 01.10.2019 в 19:26
|
тебе уже ответили, бестолочь. Как происходит краш в 1 из потоков, фриздетектор завершает все потоки По твоему если произошел краш(было брошено исключение, которое не ловится) в одном из потоков, то процесс не упадет? Или может ты имел в виду, что исключение обрабатывается, но фриздетектор все равно завершает потоки? А ну ка, поподробней тут плз если можно, конечно. Интересно послушать.
Сообщение # 16 написано 04.10.2019 в 20:15
|
Запросто.
Вот пример : сделал систему гильдий и гильдварс. Запустил константовый итератор, ну например пробежаться по конкретной гильде с бродкастом чего-то. В это же время (ошибка в алгоритме) происходит удаление кого-то из этой ги, и соответственно из итератора (не до запуска итератора, не после, а прям в нем). Что произойдет ? Ничего не произойдёт. Поток гильдменеджера зависнет, не упадет, просто повиснет. Никаких неверных исключений не будет, но и итератор константовый не завершится. В итоге фриздетектор, если включен maxcoretime (или как там пишется) будет ждать таймер, после чего завершит процесс сервера. Если в конфиге 0 - будет бесконечный фриз Только для этого он и сделан. Определить проблему это не поможет, а вот дать серверу ребутнуться - да. Добавлено (04.10.2019, 22:58) --------------------------------------------- Это из тех ошибок, что не приводят в крашам. Но они редкость, и возникают как правило либо совсем в экстремальных условиях, либо, что вероятно в 99% случаев - при вводе новых фишек, классов, менеджеров, когда код ещё не до конца испытан. Ниже рассматриваются обычные ошибки, двух видов : - при долгой обработке, когда функция ждёт отклика от других менеджеров, особенно часто это при ожидании СИНХРОННОГО запроса от базы данных.Сервер тупо ждёт, пример - когда игрок кликает на почтовый ящик. -второй тип - самый простой, обычное необработанное исключение. В обоих типах сервер сам крашнется, и при включенном гдб будет крашдамп с указанием на причину. (Включая старые "нечитаемые" дампы, где крашили сервер при помощи символов в чат, ТК символы сервер записывает как uint число, и понять было трудно, что речь о юникоде 11+, но писал же) Но есть одно НО : В первом типе, когда сервер таки крашнется с задержкой, если включен coremaxtime со значением меньше, чем операция "подвисшего" потока завершится - фриздетектор принудительно его завершит, как и остальные потоки и весь процесс сервера, и как итог - крашдампа вы не получите. |
kvipka, не сочтите за оскорбление, но содержание Ваших заблуждений и рвение, с которым Вы их отстаиваете, указывают на Вашу абсолютную несовместимость с работой в какой-либо области, так или иначе связанной с точными науками. Вам следует фундаментально изменить свой подход к изучению нового материала или вовсе оставить поприще, дабы не публиковать на форумах вроде этого посты, прочтение которых у здравомыслящих людей вызывает гримасу боли и презрения.
Запустил константовый итератор, ну например пробежаться по конкретной гильде с бродкастом чего-то. В это же время (ошибка в алгоритме) происходит удаление кого-то из этой ги, и соответственно из итератора (не до запуска итератора, не после, а прям в нем). Конвенционный итератор - ни что иное как форма указателя; переменная, призванная содержать или "оборачивать" адрес некоторой области памяти. Вы его не "запускаете", Вы просто используете его в различных алгоритмах таким образом, чтобы он указывал на некоторый элемент соответствующего ему контейнера. В целях сохранения когерентности предлагаемого Вами примера рассмотрим актуальную версию имплементации гильдий в стандартном TrinityCore ветки '3.3.5'. Класс 'Guild', определяемый в рамках такой имплементации, объявляет защищенное поле 'Members m_members;', предназначенное для хранения информации о каждом ее члене (при этом отметим, что идентификатор 'Members' имеет следующее определение: 'typedef std::unordered_map<uint32, Member*> Members;'). В это же время (ошибка в алгоритме) происходит удаление кого-то из этой ги, и соответственно из итератора (не до запуска итератора, не после, а прям в нем). Если предыдущие Ваши утверждения еще можно было объяснить применением специфических метафор, с этого фрагмента начинается форменное безумие. Удаление члена из гильдии "в это же время" возможно только из другого потока. В рамках такого удаления непременно будет вызвана какая-то из перегрузок метода 'erase' (по ключу или по итератору) относительно объекта 'm_members' ("удалить из итератора" ничего нельзя!). Для дальнейшего рассмотрения данного примера мы предположим, что пишущий (удаляющий) и читающий (итерирующийся) доступ к контейнеру надлежащим образом синхронизированы (на уровне вызова методов контейнера, что по умолчанию, кстати, не так), иначе ничто не помешает читающей стороне "увидеть" контейнер с нарушенными инвариантами, что ничем хорошим потенциально не закончится. Что произойдет ? Ничего не произойдёт. Поток гильдменеджера зависнет, не упадет, просто повиснет. Никаких неверных исключений не будет, но и итератор константовый не завершится. Еще один пример пустого резонерства. В рамках нашей гипотетической ситуации возможны всего два варианта стечения обстоятельств, в зависимости от того, равны ли удаляемый и обрабатываемый в настоящий момент чтения итераторы. Если нет - проблем не возникнет, поскольку сохранность итераторов, не соответствующих удаляемым, гарантируется для '::std::unordered_map'. Однако, если ответ "да" - произойдет использование инвалидированного итератора (разыменовывание или инкременция), что приводит к возникновению т.н. неопределенного поведения (Undefined Behaviour, UB). Как известно, никаких предсказаний относительно поведения программы, чье исполнение приводит к возникновению такового поведения, делать просто нельзя ("conforming implementation" вольна делать все, что ей будет угодно, в т.ч. абсолютно ничего; реальное поведение, однако, будет сообразно ее внутреннему устройству и в данном случае скорее всего сходно с тем, что возникает при использовании порченного указателя). Но я даже представить не могу, что заставило Вас считать, что "не произойдет ничего, и читающий поток зависнет". Фразу "итератор константовый не завершится" я, пожалуй, комментировать просто не буду, ибо содержание ее абсурдно. Ниже рассматриваются обычные ошибки, двух видов : - при долгой обработке, когда функция ждёт отклика от других менеджеров, особенно часто это при ожидании СИНХРОННОГО запроса от базы данных.Сервер тупо ждёт, пример - когда игрок кликает на почтовый ящик. -второй тип - самый простой, обычное необработанное исключение. Откуда Вы вообще взяли такую классификацию? Не удивлюсь, если самостоятельно изобрели. Спросил бы, какими рассуждениями руководствовались, но Вы ведь не сознаетесь. В отсутствии знаний нет ничего зазорного, как и в их поиске, однако в их фальсификации и, тем более, распространении результатов такой фальсификации, определенно есть. Так что рекомендую Вам, kvipka, досрочно прервать эту сессию самоунижения и идти читать профильную литературу, если Вы действительно заинтересованы в том, чтобы разбираться в обсуждаемом (и многих других) вопросе.
Сообщение # 18 написано 06.10.2019 в 02:08
|
я боюсь вы в корне не читали содержимое моего поста, и решили брать инфу "из водуха"
вот пример подробный : Код 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" ? Про самую важную уязвимость эмулей с прямой зависимостью от синхронного запроса к бд вы вообще умолчали, и спросили про мою классификацию. Я был лучшего о Вас мнения, статью целую расписали против меня, только даже не удосужились прочесть мой пост. Зато словечки модные разучили и впихиваете их везде. Ну вовжопка, чего еще стоило ожидать. |
Вот константовый итератор, и внутри его идет остановка войны между 2 конкретными гильдиями. Вы вменяемы вообще, или где? Что по-Вашему значит "внутри итератора идет остановка"? Вы решили не читать то, что я Вам написал? Я объяснил, "с чего решил взять", опять же, читайте пожалуйста внимательней. Как я могу рассматривать Ваш пример, если у меня к нему нет доступа? Хотя в данном случае это роли не играет: он, по всей видимости, так же основывается на какой-то STL map'е, а потому все написанное имеет силу, поскольку применимо для любых ассоциативных контейнеров стандартной библиотеки. Про самую важную уязвимость эмулей с прямой зависимостью от синхронного запроса к бд вы вообще умолчали, и спросили про мою классификацию. Потому что комментировал только то, что имело отношение к теме обсуждения. Так или иначе, спор наш продуктивным не будет, поскольку Вы, очевидно, заинтересованы лишь в поддержании собственного "экспертного" вида, а потому продолжите соскальзывать с темы обсуждения, опускаться до пассивно-агрессивных выпадов в адрес всех с Вами несогласных и фанатично отстаивать собственные заблуждения, вместо того, чтобы потратить несколько минут на проверку подлежащей информации. |
| |||
| |||