Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Editor crash when rebuilding GDJ files #577

Open
MartinHaeusler opened this issue Feb 10, 2024 · 7 comments
Open

Editor crash when rebuilding GDJ files #577

MartinHaeusler opened this issue Feb 10, 2024 · 7 comments
Labels
bug Something isn't working topic:core

Comments

@MartinHaeusler
Copy link
Contributor

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 chippmann added bug Something isn't working topic:core labels Mar 12, 2024
@chippmann
Copy link
Contributor

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
Copy link
Contributor Author

@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
Copy link
Contributor

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

@piiertho
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Contributor

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

@chippmann
Copy link
Contributor

Cpp reloading was implemented with #621 and thus this issue should be resolved as well.
Will keep this open for now for verification. If this does no longer pop up after our next release, I'll close it then

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working topic:core
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@MartinHaeusler @chippmann @piiertho