OpenClonk Bugtracker - OpenClonk
View Issue Details
0001428OpenClonkEnginepublic2015-10-16 12:082019-05-06 19:25
Assigned ToClonk-Karl 
PlatformPCOSWindowsOS Version8.1
Product Version 
Target Versiongit masterFixed in Version 
Summary0001428: Definition reloading crashes often
DescriptionDepending on what you change, the engine crashes when reloading a definition. If objects with meshes are reloaded, they often turn white.

I will continue to collect examples of action that do crash the engine.

So far:

Changing vertices
Changing .material
TagsNo tags attached.
related to 0001658confirmed  Crash when reloading an object 
Attached Files

2015-10-16 15:39   
I might be mistaken, but I think any change in a definition just causes a definition reload. And then the crash usually happens due to the script engine re-compilation causing dead pointers somewhere.
2015-10-17 23:05   
I fixed a problem with reloading mesh materials. Cannot reproduce a crash when changing vertices, though. On which scenario does this happen, and when changing the vertices of which object?
2015-10-18 12:28   
(Last edited: 2015-10-19 07:50)
You're right, just changing the vertex doesn't crash. After having changed it, you need to select it with the edit cursor and try to move it.

That may be the case with more crashes on definition reloading.

2015-10-18 22:56   
I don't even need to change anything in the DefCore.txt for this to crash. Crashes somewhere deep down in the mysteries of C4PropList. I think the definition proplist gets recreated but the object proplist still accesses some parts of the old definition proplist, e.g. Action points into the old ActMap.
2015-10-19 07:50   
Yes, it doesn't seem linked to any change in particular and may very well be the reason why I thought that various things crashed the engine.
2019-05-06 07:42   
I've traced one crash back to Objects.ocd/HUD.ocd/ControllerLibrary.ocd/Script.c:76 in OnSynchronized()

It schedules a call to Reset which in turn calls Construction, where it then crashes.
Either Construction itself, or a function within it appears to have been freed during UnLink.
2019-05-06 19:25   
I am speculating that ScheduleCall saves a reference to the old GUI_Controller.Reset.
However, this does not crash yet, because it does correct reference counting.

But then the call to Construction fails, because the other function of GUI_Controller don't exist anymore.

Also a strange thing:
Changing the following line in GUI_Controller.Reset from




makes it not crash anymore.
I assume this is because a call via "this" is looked up, but for a regular call, the function reference is embedded into the bytecode.

Issue History
2015-10-16 12:08ClonkonautNew Issue
2015-10-16 15:39Sven2Note Added: 0003947
2015-10-17 23:05Clonk-KarlNote Added: 0003958
2015-10-17 23:05Clonk-KarlAssigned To => Clonk-Karl
2015-10-17 23:05Clonk-KarlStatusnew => feedback
2015-10-18 12:28ClonkonautNote Added: 0003964
2015-10-18 12:28ClonkonautStatusfeedback => assigned
2015-10-18 12:29ClonkonautNote Edited: 0003964bug_revision_view_page.php?bugnote_id=3964#r966
2015-10-18 22:56Clonk-KarlNote Added: 0003970
2015-10-19 07:50ClonkonautNote Edited: 0003964bug_revision_view_page.php?bugnote_id=3964#r969
2015-10-19 07:50ClonkonautNote Added: 0003974
2016-01-31 05:46Clonk-KarlRelationship addedrelated to 0001658
2017-08-05 13:58MaikelTarget Version => 8.0
2017-08-20 11:30ZapperTarget Version8.0 => 8.1
2017-10-26 13:23ClonkonautTarget Version8.1 => git master
2019-05-06 07:42FoalyNote Added: 0006258
2019-05-06 19:25FoalyNote Added: 0006259