Do not delete g_pNeoLoading ourselves, probably already done by engine#730
Conversation
|
@nullsystem Do you have a crash dump for this, or repro steps? |
|
It's probably not noticeable unless you specifically run the game from visual studio in debug mode maybe? |
|
@Rainyan Repro step is just opening then closing, and it happens sometimes, sometimes it doesn't. If it happens it's on shutdown. @AdamTadeusz Still a crash and rather anonying when on a debugger? Even for people on a release build and it happens, it'll end up filling up more dump files. |
This is on master, not this branch. Haven't verified this fixes the problem yet but yes its a common crash on master on exit when debugging |
This comment was marked as outdated.
This comment was marked as outdated.
There was a problem hiding this comment.
Ok, I can reproduce it too. Looking at the backtrace, it seems to indeed be a segfault at line
neo/mp/src/game/client/clientmode_shared.cpp
Line 330 in 9dc5d66
with the ECX register ("this" ptr of the thiscall) pointing to unaddressable memory at the time of the function call, which then signals SIGSEGV.
Tracing the ~CNeoLoading base dtor, it's invoked via
neo/mp/src/vgui2/vgui_controls/Panel.cpp
Line 1682 in 9dc5d66
from the engine library before the ~ClientModeShared dtor is called, so it seems to indeed be a use-after-free on the g_pNeoLoading pointer. And since the CNeoLoading destructor is already being invoked by the engine, we should be safe to remove these lines without a memory leak.
|
firefox moment? |
Description
Still getting crash here (user after free on dangling pointer?). Just don't handle it. It's also called on exit so it's unnecessary to even cleanup here anyway.
Toolchain