🐛 attack round crashing server
MowFord opened this issue · comments
I affirm:
- I understand that if I do not agree to the following points by completing the checkboxes my issue will be ignored.
- I have read and understood the Contributing Guide and the Code of Conduct.
- I have searched existing issues to see if the issue has already been opened, and I have checked the commit log to see if the issue has been resolved since my server was last updated.
OS / platform the server is running (if known)
Branch affected by issue
base
Steps to reproduce
Unsure the exact steps, as were just getting a handle on what's happening, but the new pdiff seems to be failing in a way that might not be easy to debug
Expected behavior
✨ Thanks for the report! ✨
This is a friendly automated reminder that the maintainers won't look at your report until you've properly completed all of the checkboxes in the pre-filled template.
Call Stack:
KERNELBASE.dll!00007ffd683fcf19() Unknown
libluajit_64.dll!00007ffd4f38bd28() Unknown
libluajit_64.dll!00007ffd4f38c6ad() Unknown
libluajit_64.dll!00007ffd4f38c58d() Unknown
libluajit_64.dll!00007ffd4f38c1a7() Unknown
libluajit_64.dll!00007ffd4f38c90c() Unknown
> [Inline Frame] xi_map.exe!kp_compat53L_checkstack_53(lua_State *) Line 3757 C++
[Inline Frame] xi_map.exe!sol::stack::unqualified_pusher<bool,void>::push(lua_State *) Line 14957 C++
xi_map.exe!sol::stack::push<bool const &>(lua_State * L, const bool & t) Line 11759 C++
xi_map.exe!sol::stack::multi_push_reference<CLuaBaseEntity &,CLuaBaseEntity,enum SKILLTYPE &,float &,bool &,bool,bool,bool>(lua_State * L, CLuaBaseEntity & t, CLuaBaseEntity && <args_0>, SKILLTYPE & <args_1>, float & <args_2>, bool & <args_3>, bool && <args_4>, bool && <args_5>, bool && <args_6>) Line 11854 C++
[Inline Frame] xi_map.exe!sol::basic_protected_function<sol::stack_reference,1,sol::basic_reference<0>>::call(CLuaBaseEntity &) Line 21026 C++
[Inline Frame] xi_map.exe!sol::table_proxy<sol::basic_table_core<1,sol::basic_reference<0>> &,std::tuple<char const (&)[3],char const (&)[7],char const (&)[9],char const (&)[19]>>::call(CLuaBaseEntity &) Line 24897 C++
[Inline Frame] xi_map.exe!sol::table_proxy<sol::basic_table_core<1,sol::basic_reference<0>> &,std::tuple<char const (&)[3],char const (&)[7],char const (&)[9],char const (&)[19]>>::operator()(CLuaBaseEntity & <args_1>, CLuaBaseEntity &&) Line 24902 C++
xi_map.exe!battleutils::GetDamageRatio(CBattleEntity * PAttacker, CBattleEntity * PDefender, bool isCritical, float bonusAttPercent, SKILLTYPE weaponType) Line 2943 C++
xi_map.exe!CAttack::SetCritical(bool value) Line 137 C++
xi_map.exe!CBattleEntity::OnAttack(CAttackState & state, action_t & action) Line 2265 C++
xi_map.exe!CAttackState::Update(std::chrono::time_point<std::chrono::system_clock,std::chrono::duration<__int64,std::ratio<1,10000000>>> tick) Line 66 C++
xi_map.exe!CAIContainer::Tick(std::chrono::time_point<std::chrono::system_clock,std::chrono::duration<__int64,std::ratio<1,10000000>>> _tick) Line 444 C++
xi_map.exe!CZoneEntities::ZoneServer(std::chrono::time_point<std::chrono::system_clock,std::chrono::duration<__int64,std::ratio<1,10000000>>> tick) Line 1662 C++
xi_map.exe!CZone::ZoneServer(std::chrono::time_point<std::chrono::system_clock,std::chrono::duration<__int64,std::ratio<1,10000000>>> tick) Line 932 C++
xi_map.exe!zone_server(std::chrono::time_point<std::chrono::system_clock,std::chrono::duration<__int64,std::ratio<1,10000000>>> tick, CTaskMgr::CTask * PTask) Line 82 C++
xi_map.exe!CTaskMgr::DoTimer(std::chrono::time_point<std::chrono::system_clock,std::chrono::duration<__int64,std::ratio<1,10000000>>> tick) Line 114 C++
xi_map.exe!main(int argc, char * * argv) Line 273 C++
[External Code]
crash dump:
https://drive.google.com/file/d/1ODTbXOsoatfJfw0U2zpyNzw-SRlzlesS/view?usp=sharing
m_victim looks like its got a valid pointer before passing it into GetDamageRatio
And somehow it became garbage in the function, that or the dump doesn't look right on my system --
The attacker looks fine the whole way through. I assume this doesn't crash all the time so its probably not a miscompilation
There's nothing obviously wrong here, though the fact that it says it's a stack overflow is in sol is weird given it didnt even go deep at all into the stack
yes, apologies there isn't more info to go on. we reverted the commit on live and are trying to replicate on the test server
I assume this doesn't crash all the time so its probably not a miscompilation
Not all the time but it was quite often. Every few minutes some zone cluster would crash. Might have been a compile issue? Never seen that before
The only relevant information I have that might help:
The attacker was a Kupipi trust who crit a bark spider in boyahda
Not sure why any of that would matter -- but its a datapoint.
Not all the time but it was quite often. Every few minutes some zone cluster would crash. Might have been a compile issue? Never seen that before
I can't get this thing to crash at all, is the traceback consistent?
And as for the build, the only thing you could reasonably do is run "Rebuild All" or "Clean All" then "Build All"
It's rare, but sometimes VS does compile things badly on partial builds and not full rebuilds. I can't really explain why the pointer would change addresses once it enters the function without some weird compilation issue.
Looks like the input to lua was missing a param but I don't think this is related. It won't hurt, see
#5250
I just got a lua crash (on linux):
terminate called after throwing an instance of 'sol::error'
what(): lua: error: stack overflow (not enough space left on Lua stack to push valuees)
Crash detected, generating traceback (this may take a while)
alright, I can repro this pretty easy now. standby
Think I fixed it, fairly subtle problem apparently...