Open MartinHaeusler opened 4 months ago
I now also run frequently into this issue. Hard to impossible to reproduce and happens regardless of the changes. Not even the gdj files themselves have to change. So my guess would be that it somehow breaks when reloading the main jar file.
@chippmann Reloading the main jar file sounds plausible. What I find very strange is this (at least from the trace I've posted above, maybe there are also other causes):
ERROR: Cannot get class ''. at: instantiate (core/object/class_db.cpp:358)
The engine is trying to load/instantiate a class with an empty name. Now I'm not a C++ expert by any means, but that sounds invalid.
If we can't figure out the true cause right away, could we at least wrap it into a try-catch
block and show the user an error dialog, telling them to save their work and restart the editor as soon as possible? It's not pretty, but it's better than losing unsaved progress.
Yeah i agree. But first I'd like to investigate a bit before applying such a workaround
We're going to make reloading happen on cpp side so this error should go with it. I would not do a workaround if we totally change how reloading work in a next future.
The following happened while I was rebuilding my Kotlin project (and the GDJ files) while the godot editor was open:
Godot-JVM: Build lock present. Not reloading...
Godot-JVM: Changes detected, reloading classes ...
FATAL ERROR in native method: Invalid weak global JNI handle passed to DeleteWeakGlobalRef
at godot.runtime.Bootstrap.loadClasses(Native Method)
at godot.runtime.Bootstrap.initializeUsingEntry(Bootstrap.kt:159)
at godot.runtime.Bootstrap.doInit(Bootstrap.kt:102)
at godot.runtime.Bootstrap.init$lambda$1(Bootstrap.kt:81)
at godot.runtime.Bootstrap$$Lambda/0x00000008002b6f40.run(Unknown Source)
at java.util.concurrent.Executors$RunnableAdapter.call(java.base@21.0.2/Executors.java:572)
at java.util.concurrent.FutureTask.runAndReset(java.base@21.0.2/FutureTask.java:358)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(java.base@21.0.2/ScheduledThreadPoolExecutor.java:305)
at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@21.0.2/ThreadPoolExecutor.java:1144)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@21.0.2/ThreadPoolExecutor.java:642)
at java.lang.Thread.runWith(java.base@21.0.2/Thread.java:1596)
at java.lang.Thread.run(java.base@21.0.2/Thread.java:1583)
I'm still on version 0.8.1-4.2.0
.
I don't know if this is related or not, but the consequence was the same: immediate editor shutdown.
We discussed this a bit and we think we cannot easily fix this issue atm. A simple try catch also does not really resolve the problem. We could mitigate it to some degree but the effort required is probably better invested in an "actual" fix (see below). Once we switched to cpp reloading, it basically should be fixed "automatically". We now start with the refactoring of the cpp side of things, which leads the way to cpp handled/triggered reloading which in turn will fix this issue.
TLDR; could take a bit until this is fixed
Every now and then it happens that the godot editor crashes while I rebuild my kotlin files. Here's the trace:
I've found no way so far to consistently reproduce this error, it is pretty rare. However, it immediately crashes the editor, losing unsaved changes in the process, so it is cumbersome to deal with.
In the case above, I merely edited some existing kotlin files. No new ones were added, no existing ones were deleted, and no exposed properties or method signatures have changed.