Краши
 

Сегодня обновился на 1154, через некоторое время словил первый краш.

При этом, мангос не убился, а повис (пинг = 1000 и более сразу)

Не знаю пока что это такое вообще, буду думать)

Это уже поправлено в [z1155]. На само деле проблема была во всех ветках.

Ещё один такой же краш...

Exception code: C0000005 ACCESS_VIOLATION
Fault address: 774EAC0F 01:0001AC0F C:\Windows\SysWOW64\ntdll.dll

Ядро повисло.

Вобщем я понял из-за чего...

Пет застрял в текстурах и хана.. Кстати эти новые VMaps 3 версии хуже намного чем 2-е. Раньше таких проблем не было.

Половина НПС в инстах вообще в текстурах теперь.

Не судите о качестве третьих vmaps по качеству в Zero
если бы такое-же было в master, то их бы там не было ;)

vmaps3 отличаются от стрых не качеством - а наличием indoor/outdoor, информации о воде и зонах там где .map такую информацию предоставить не могут.
Про проблемы с высотами читать странно - т.к эта часть не должна сильно отличаться. Я не уверен на 100% что все изменения с вычислением высот перенесены - но не для vmaps а кода их последующего использования.

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

под качеством имелось ввиду не наличие дополнительной информации, а общее воздействие на юзверей Zero :)

На самых первых мобах в ЛБРС

При повторном прохождении через них краша не было.

Крашлог, причины не знаю.

А открыть блокнотом и увидеть причину, это очень сложно?

Функция GetBagSlot() ищи краш опасные места.

краш при входе в данж BRS

TheLuda mangoszero (1614)

TheLuda mangoszero-database

TheLuda mangoszero-scriptdev0


P.S. после отключение скрипдевзеро всё работает без крашей

Нехватка памяти?

У меня когда то тоже там был краш.

Потом я много-много раз проходил это место и все тщетно. Бывает)

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

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

Одно понятно - происходит со спеллами, которые кастуются итемом и удаляют его после использования, но не всегда. Кто что может подсказать?

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

Цитата:

#0 0x0000000000970b31 in Object::SendCreateUpdateToPlayer (this=0x7f6f60da0b80, player=0xfe34000) at ../../../src/game/Object.cpp:193 193 BuildCreateUpdateBlockForPlayer(&upd, player); #0 0x0000000000970b31 in Object::SendCreateUpdateToPlayer (this=0x7f6f60da0b80, player=0xfe34000) at ../../../src/game/Object.cpp:193 upd = {m_blockCount = 0, m_outOfRangeGUIDs = {_M_t = { _M_impl = {<std::allocator<std::_Rb_tree_node<ObjectGuid> >> = {<__gnu_cxx::new_allocator<std::_Rb_tree_node<Obje ctGuid> >> = {<No data fields>}, <No data fields>}, _M_key_compare = {<std::binary_function<ObjectGuid, ObjectGuid, bool>> = {<No data fields>}, <No data fields>}, _M_header = {_M_color = std::_S_red, _M_parent = 0x0, _M_left = 0x7f6f66cee5d0, _M_right = 0x7f6f66cee5d0}, _M_node_count = 0}}}, m_data = {static DEFAULT_SIZE = 4096, _rpos = 0, _wpos = 0, _storage = {<std::_Vector_base<unsigned char, std::allocator<unsigned char> >> = { _M_impl = {<std::allocator<unsigned char>> = {<__gnu_cxx::new_allocator<unsigned char>> = {<No data fields>}, <No data fields>}, _M_start = 0x7f6f4fdcd600 "", _M_finish = 0x7f6f4fdcd600 "", _M_end_of_storage = 0x7f6f4fdce600 "2³\016B\"\231A/\004"}}, <No data fields>}}} packet = {<ByteBuffer> = {static DEFAULT_SIZE = 4096, _rpos = 0, _wpos = 0, _storage = {<std::_Vector_base<unsigned char, std::allocator<unsigned char> >> = { _M_impl = {<std::allocator<unsigned char>> = {<__gnu_cxx::new_allocator<unsigned char>> = {<No data fields>}, <No data fields>}, _M_start = 0x0, _M_finish = 0x0, _M_end_of_storage = 0x0}}, <No data fields>}}, m_opcode = 0} #1 0x0000000000a0e964 in Player::DestroyItemCount (this=0xfe34000, pItem=0x7f6f60da0b80, count=@0x7f6f66cee6ec, update=true) at ../../../src/game/Player.cpp:10683 itemId = 21151 playerGuid = 285263 #2 0x0000000000a960e5 in Spell::TakeCastItem (this=0x7f6f490d9d00) at ../../../src/game/Spell.cpp:3680 count = 0 proto = (const ItemPrototype *) 0x4a9cce8 expendable = true withoutCharges = true #3 0x0000000000a92c98 in Spell::handle_immediate (this=0x7f6f490d9d00) at ../../../src/game/Spell.cpp:2828 spellInfo = (const SpellEntry *) 0x7f6f6b220208 #4 0x0000000000a9289a in Spell::cast (this=0x7f6f490d9d00, skipCheck=false) at ../../../src/game/Spell.cpp:2775 spellInfo = (const SpellEntry *) 0x7f6f6b220208 spellId = 25804 castResult = SPELL_CAST_OK #5 0x0000000000a93610 in Spell::update (this=0x7f6f490d9d00, difftime=77) at ../../../src/game/Spell.cpp:2988 No locals. #6 0x0000000000a9e26f in SpellEvent::Execute (this=0x7f6f63137308, e_time=130004, p_time=77) at ../../../src/game/Spell.cpp:5967 No locals. #7 0x0000000000c3aa7b in EventProcessor::Update (this=0xfe34130, p_time=77) at ../../../src/framework/Utilities/EventProcessor.cpp:34 Event = (BasicEvent *) 0x7f6f63137308 i = {_M_node = 0x7f6f4efc02e0} #8 0x0000000000b05533 in Unit::Update (this=0xfe34000, update_diff=77, p_time=77) at ../../../src/game/Unit.cpp:286 No locals. #9 0x00000000009f039e in Player::Update (this=0xfe34000, update_diff=77, p_time=77) at ../../../src/game/Player.cpp:1105 now = 1310134332

насколько я помню, этот краш был от патча SilverIce на GridUnload. некоторое время назад меня Владимир мордой по столу за него повозил :)

Как-то не похоже. Хотя кто его знает, интересно что Владимир или кто-нибудь из разработчиков скажут.

Так тот патч на GridUnload. Да у меня закомментирована та строчка. Все-таки надо вернуть обратно или как?

Вот иногда это дело сопровождается еще этим крашем
Тут ясно видно что якобы итемид 16138 и спелл тоже 16138. Спел существует и опять же на итеме и опять же исчезает при использовании. Неоднократно проверял все работает, и краш отследить не получается. Однако итема 16138 в помине нет :) Такое предположение что в клиентских полях неправильно пишутся данные или перезаписываются.