utopia-rise / godot-kotlin-jvm

Godot Kotlin JVM Module
MIT License
559 stars 38 forks source link

Editor crash when rebuilding GDJ files #577

Open MartinHaeusler opened 4 months ago

MartinHaeusler commented 4 months ago

Every now and then it happens that the godot editor crashes while I rebuild my kotlin files. Here's the trace:

Godot-JVM: Build lock present. Not reloading...
Godot-JVM: Changes detected, reloading classes ...
ERROR: Cannot get class ''.
   at: instantiate (core/object/class_db.cpp:358)
Warning: SIGSEGV handler modified!
Warning: SIGILL handler modified!
Warning: SIGFPE handler modified!
Signal Handlers:
   SIGSEGV: SIG_DFL, mask=00000000001000000000000000000000, flags=SA_RESTART, unblocked
  *** Handler was modified!
  *** Expected: javaSignalHandler in libjvm.so, mask=11100100110111111111111111111110, flags=SA_RESTART|SA_SIGINFO
  chained to: SIG_DFL, mask=00000000001000000000000000000000, flags=SA_RESTART
    SIGBUS: javaSignalHandler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO, unblocked
    SIGFPE: SIG_DFL, mask=00000001000000000000000000000000, flags=SA_RESTART, unblocked
  *** Handler was modified!
  *** Expected: javaSignalHandler in libjvm.so, mask=11100100110111111111111111111110, flags=SA_RESTART|SA_SIGINFO
  chained to: SIG_DFL, mask=00000001000000000000000000000000, flags=SA_RESTART
   SIGPIPE: javaSignalHandler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO, unblocked
   SIGXFSZ: javaSignalHandler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO, unblocked
    SIGILL: SIG_DFL, mask=00010000000000000000000000000000, flags=SA_RESTART, unblocked
  *** Handler was modified!
  *** Expected: javaSignalHandler in libjvm.so, mask=11100100110111111111111111111110, flags=SA_RESTART|SA_SIGINFO
  chained to: SIG_DFL, mask=00010000000000000000000000000000, flags=SA_RESTART
   SIGUSR2: SR_handler in libjvm.so, mask=00000000000000000000000000000000, flags=SA_RESTART|SA_SIGINFO, unblocked
    SIGHUP: UserHandler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO, unblocked
    SIGINT: UserHandler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO, unblocked
   SIGTERM: UserHandler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO, unblocked
   SIGQUIT: UserHandler in libjvm.so, mask=11100100010111111101111111111110, flags=SA_RESTART|SA_SIGINFO, blocked
   SIGTRAP: SIG_DFL, mask=00000000000000000000000000000000, flags=none, unblocked
Consider using jsig library.

================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.2.stable.custom_build (46dc277917a93cbf601bbcf0d27d00f6feeec0d5)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] /home/martin/Documents/git/cardsmithGodotKotlin/client/jre-amd64/lib/server/libjvm.so(+0xe59ac8) [0x7fb7ff859ac8] (??:0)
[2] /home/martin/Documents/git/cardsmithGodotKotlin/client/jre-amd64/lib/server/libjvm.so(JVM_handle_linux_signal+0x185) [0x7fb7ff859d35] (??:0)
[3] /lib/x86_64-linux-gnu/libc.so.6(+0x42520) [0x7fb82c642520] (??:0)
[4] /home/martin/Documents/git/cardsmithGodotKotlin/godotEngine/godot.linuxbsd.editor.x86_64(+0x48fdfda) [0x5643dd610fda] (??:0)
[5] /home/martin/Documents/git/cardsmithGodotKotlin/godotEngine/godot.linuxbsd.editor.x86_64(+0xca2409) [0x5643d99b5409] (??:0)
[6] /home/martin/Documents/git/cardsmithGodotKotlin/godotEngine/godot.linuxbsd.editor.x86_64(+0xc93ddc) [0x5643d99a6ddc] (??:0)
[7] /home/martin/Documents/git/cardsmithGodotKotlin/godotEngine/godot.linuxbsd.editor.x86_64(+0xc8f135) [0x5643d99a2135] (??:0)
[8] /home/martin/Documents/git/cardsmithGodotKotlin/godotEngine/godot.linuxbsd.editor.x86_64(+0xc8f554) [0x5643d99a2554] (??:0)
[9] /home/martin/Documents/git/cardsmithGodotKotlin/godotEngine/godot.linuxbsd.editor.x86_64(+0xc914ba) [0x5643d99a44ba] (??:0)
[10] /home/martin/Documents/git/cardsmithGodotKotlin/godotEngine/godot.linuxbsd.editor.x86_64(+0x465bb25) [0x5643dd36eb25] (??:0)
[11] /home/martin/Documents/git/cardsmithGodotKotlin/godotEngine/godot.linuxbsd.editor.x86_64(+0x48f58b1) [0x5643dd6088b1] (??:0)
[12] /home/martin/Documents/git/cardsmithGodotKotlin/godotEngine/godot.linuxbsd.editor.x86_64(+0x48f93ee) [0x5643dd60c3ee] (??:0)
[13] /home/martin/Documents/git/cardsmithGodotKotlin/godotEngine/godot.linuxbsd.editor.x86_64(+0x2796889) [0x5643db4a9889] (??:0)
[14] /home/martin/Documents/git/cardsmithGodotKotlin/godotEngine/godot.linuxbsd.editor.x86_64(+0x5dcccf) [0x5643d92efccf] (??:0)
[15] /home/martin/Documents/git/cardsmithGodotKotlin/godotEngine/godot.linuxbsd.editor.x86_64(+0x573e51) [0x5643d9286e51] (??:0)
[16] /home/martin/Documents/git/cardsmithGodotKotlin/godotEngine/godot.linuxbsd.editor.x86_64(+0x55fea1) [0x5643d9272ea1] (??:0)
[17] /lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x7fb82c629d90] (??:0)
[18] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x7fb82c629e40] (??:0)
[19] /home/martin/Documents/git/cardsmithGodotKotlin/godotEngine/godot.linuxbsd.editor.x86_64(+0x571ace) [0x5643d9284ace] (??:0)
-- END OF BACKTRACE --
================================================================

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.

chippmann commented 3 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.

MartinHaeusler commented 3 months ago

@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.

chippmann commented 3 months ago

Yeah i agree. But first I'd like to investigate a bit before applying such a workaround

piiertho commented 3 months ago

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.

MartinHaeusler commented 3 months ago

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.

chippmann commented 3 months ago

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