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.

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

Engine hangs on exit after executing GDScript unit tests using GUT #42339

Closed
Xrayez opened this issue Sep 25, 2020 · 0 comments · Fixed by #42356
Closed

Engine hangs on exit after executing GDScript unit tests using GUT #42339

Xrayez opened this issue Sep 25, 2020 · 0 comments · Fixed by #42356

Comments

@Xrayez
Copy link
Contributor

Xrayez commented Sep 25, 2020

Godot version:
3.2.4 beta 4162df4.
Related to #42305. (CC @RandomShaper).

OS/device including version:
Tested on Windows 10, Linux server platforms.

Issue description:
After #42323, the crash is resolved, but the engine hangs after all tests are finished. When I pause the debugger, occasionally this ends up with a call stack similar to this:

godot.windows.tools.64.goost.exe!Ref<class Script>::Ref<class Script>(void) (Unknown Source:0)
godot.windows.tools.64.goost.exe!GDScriptLanguage::~GDScriptLanguage() Line 2256 (d:\usr\src\godot\goostengine\goost\godot\modules\gdscript\gdscript.cpp:2256)
godot.windows.tools.64.goost.exe!GDScriptLanguage::`scalar deleting destructor'(unsigned int) (Unknown Source:0)
godot.windows.tools.64.goost.exe!memdelete<GDScriptLanguage>(GDScriptLanguage * p_class) Line 119 (d:\usr\src\godot\goostengine\goost\godot\core\os\memory.h:119)
godot.windows.tools.64.goost.exe!unregister_gdscript_types() Line 180 (d:\usr\src\godot\goostengine\goost\godot\modules\gdscript\register_types.cpp:180)
godot.windows.tools.64.goost.exe!unregister_module_types() Line 228 (d:\usr\src\godot\goostengine\goost\godot\modules\register_module_types.gen.cpp:228)
godot.windows.tools.64.goost.exe!Main::cleanup() Line 2255 (d:\usr\src\godot\goostengine\goost\godot\main\main.cpp:2255)
godot.windows.tools.64.goost.exe!widechar_main(int argc, wchar_t * * argv) Line 164 (d:\usr\src\godot\goostengine\goost\godot\platform\windows\godot_windows.cpp:164)
godot.windows.tools.64.goost.exe!_main() Line 184 (d:\usr\src\godot\goostengine\goost\godot\platform\windows\godot_windows.cpp:184)
godot.windows.tools.64.goost.exe!main(int _argc, char * * _argv) Line 196 (d:\usr\src\godot\goostengine\goost\godot\platform\windows\godot_windows.cpp:196)
[Inline Frame] godot.windows.tools.64.goost.exe!invoke_main() Line 78 (d:\agent\_work\4\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78)
godot.windows.tools.64.goost.exe!__scrt_common_main_seh() Line 288 (d:\agent\_work\4\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288)
kernel32.dll!00007ffe5d5e7bd4() (Unknown Source:0)
ntdll.dll!00007ffe5d9ace51() (Unknown Source:0)

Seems to happen on project get_tree().quit() once tests are finished.

See GUT log at https://github.com/goostengine/goost/runs/1164928377, where the testing stage kept running for 5 hours, until it got automatically cancelled by GitHub, which fail CI result.

Steps to reproduce:
Likely running some GUT tests could reproduce this, but in case if you need the exact state:

git clone https://github.com/goostengine/goost
cd goost
scons

Then run GUT tests using the tests/run.sh with the resulting binaries, or manually...

Minimal reproduction project:
I haven't yet created a minimal project to test this out, seems to happen with more complex testing procedures, but perhaps this could already provide some insights.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants