View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000595||Gameplay + OpenGL||[All Projects] Bug||public||2017-04-18 07:20||2017-04-20 11:58|
|Platform||PC||OS||Windows||OS Version||10 Home x64|
|Summary||0000595: Restarting from the console causes a crash|
|Description||Executing the 'restart' CCMD from the console causes the engine to crash.|
|Steps To Reproduce||Just execute the command, without passing arguments.|
|Additional Information||Tested/produced with: 3.0pre-15-g11e6cfc, 2.5pre-363-g069e4e9 (both 64-bit)|
|Tags||No tags attached.|
Forgot the crash report.
CrashReport.zip (23,287 bytes)
|Something is wrong with garbage collection of menu objects|
Using the latest commit the issue still can be reproduced in Debug configuration built with MSVC 2015 32- and 64-bit both.
After the final GC pass the root isn't nullptr but contains some partially destroyed thing.
RelWithDebInfo configuration works fine.
I just want to make sure that all restart issues are fixed because the problem with Debug configuration seems to revealed something related.
The hanging object appeared to be a dummy soft root created before all soft roots.
Here is the callstack:
Also, looks like this assertion always fails on restart CCMD since its addition.
I'm curious how this supposed to work.
|Looks like the restart code needs a GC::DelSoftRootHead call after taking down the object list.|
Damn, I tried to call that function but placed it a wrong line. This GC stuff is way too non-obvious to me.
Fixed in e19f6fe
Welcome to the club! :D
Can you imagine how bad it was when the entire type system, the entire symbol table and all VM functions were also in there. Make the smallest mistake and these things just disappeared!
That were 9000 GC-subjected objects that didn't reference anything non-static and only wasted a lot of time...
I really wish this could be done without those godforsaken write barriers.
|Honestly I have no idea why whole this GC system is better than reference counting smart pointers, intrusive pointers seem suitable for our case.|
The system is doing one important thing a smart pointer cannot:
It actively NULLs pointers to destroyed objects. That was the entire reason why such a complex thing was done. The old system could really drag performance down, when object destruction caused massive pointer NULLing.
|2017-04-18 07:20||Blue Shadow||New Issue|
|2017-04-18 07:22||Blue Shadow||File Added: CrashReport.zip|
|2017-04-18 07:22||Blue Shadow||Note Added: 0001434|
|2017-04-18 07:55||_mental_||Status||new => confirmed|
|2017-04-18 07:55||_mental_||Note Added: 0001437|
|2017-04-18 09:42||Graf Zahl||Note Added: 0001450|
|2017-04-18 09:54||Graf Zahl||Status||confirmed => resolved|
|2017-04-18 09:54||Graf Zahl||Resolution||open => fixed|
|2017-04-19 09:41||_mental_||Status||resolved => new|
|2017-04-19 09:41||_mental_||Resolution||fixed => reopened|
|2017-04-19 09:41||_mental_||Note Added: 0001459|
|2017-04-20 03:24||_mental_||Note Added: 0001468|
|2017-04-20 07:34||Graf Zahl||Note Added: 0001471|
|2017-04-20 08:25||_mental_||Status||new => resolved|
|2017-04-20 08:25||_mental_||Resolution||reopened => fixed|
|2017-04-20 08:25||_mental_||Note Added: 0001472|
|2017-04-20 09:43||Graf Zahl||Note Added: 0001474|
|2017-04-20 10:27||_mental_||Note Added: 0001476|
|2017-04-20 11:58||Graf Zahl||Note Added: 0001478|