OpenClonk Bugtracker - OpenClonk
View Issue Details
0001428OpenClonkEnginepublic2015-10-16 12:082019-05-06 19:25
ReporterClonkonaut 
Assigned ToClonk-Karl 
PrioritylowSeveritycrashReproducibilityalways
StatusassignedResolutionopen 
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

Notes
(0003947)
Sven2   
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.
(0003958)
Clonk-Karl   
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?
(0003964)
Clonkonaut   
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.

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

(0003970)
Clonk-Karl   
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.
(0003974)
Clonkonaut   
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.
(0006258)
Foaly   
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.
(0006259)
Foaly   
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

Construction();

to

this->Construction();

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