Engine hangs and crashes due to script debugger break fail while running GUT tests

[Xrayez]

Godot version:
3.2.4 beta f3e5577
Regression, not sure the cause yet.
May be related to #40555, but also reproducible on Linux server.

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

Issue description:

ntdll.dll!00007fffd6bdc134() (Unknown Source:0)
KernelBase.dll!00007fffd3c9e517() (Unknown Source:0)
godot.windows.tools.64.exe!_read_nolock(int fh, void * result_buffer, unsigned int result_buffer_size) Line 566 (c:\Users\Xrayez\AppData\Local\Programs\Microsoft VS Code\minkernel\crts\ucrt\src\appcrt\lowio\read.cpp:566)
godot.windows.tools.64.exe!_read(int fh, void * buffer, unsigned int buffer_size) Line 396 (c:\Users\Xrayez\AppData\Local\Programs\Microsoft VS Code\minkernel\crts\ucrt\src\appcrt\lowio\read.cpp:396)
[Inline Frame] godot.windows.tools.64.exe!common_refill_and_read_nolock(const __crt_stdio_stream) Line 146 (c:\Users\Xrayez\AppData\Local\Programs\Microsoft VS Code\minkernel\crts\ucrt\src\appcrt\stdio\_filbuf.cpp:146)
godot.windows.tools.64.exe!__acrt_stdio_refill_and_read_narrow_nolock(_iobuf * stream) Line 180 (c:\Users\Xrayez\AppData\Local\Programs\Microsoft VS Code\minkernel\crts\ucrt\src\appcrt\stdio\_filbuf.cpp:180)
[Inline Frame] godot.windows.tools.64.exe!__crt_char_traits<char>::getc_nolock(_iobuf * &&) Line 109 (c:\Users\Xrayez\AppData\Local\Programs\Microsoft VS Code\minkernel\crts\ucrt\inc\corecrt_internal_traits.h:109)
godot.windows.tools.64.exe!common_fgets<char>(char * const string, const int count, const __crt_stdio_stream stream) Line 51 (c:\Users\Xrayez\AppData\Local\Programs\Microsoft VS Code\minkernel\crts\ucrt\src\appcrt\stdio\fgets.cpp:51)
godot.windows.tools.64.exe!OS_Windows::get_stdin_string(bool p_block) Line 3165 (godot\platform\windows\os_windows.cpp:3165)
godot.windows.tools.64.exe!ScriptDebuggerLocal::debug(ScriptLanguage * p_script, bool p_can_continue, bool p_is_error_breakpoint) Line 56 (godot\core\script_debugger_local.cpp:56)
godot.windows.tools.64.exe!GDScriptLanguage::debug_break(const String & p_error, bool p_allow_continue) Line 245 (godot\modules\gdscript\gdscript_editor.cpp:245)
godot.windows.tools.64.exe!GDScriptFunction::call(GDScriptInstance * p_instance, const Variant * * p_args, int p_argcount, Variant::CallError & r_err, GDScriptFunction::CallState * p_state) Line 1601 (godot\modules\gdscript\gdscript_function.cpp:1601)
godot.windows.tools.64.exe!GDScriptInstance::call(const StringName & p_method, const Variant * * p_args, int p_argcount, Variant::CallError & r_error) Line 1239 (godot\modules\gdscript\gdscript.cpp:1239)
godot.windows.tools.64.exe!Object::call(const StringName & p_method, const Variant * * p_args, int p_argcount, Variant::CallError & r_error) Line 901 (godot\core\object.cpp:901)
godot.windows.tools.64.exe!Variant::call_ptr(const StringName & p_method, const Variant * * p_args, int p_argcount, Variant * r_ret, Variant::CallError & r_error) Line 1128 (godot\core\variant_call.cpp:1128)
godot.windows.tools.64.exe!GDScriptFunction::call(GDScriptInstance * p_instance, const Variant * * p_args, int p_argcount, Variant::CallError & r_err, GDScriptFunction::CallState * p_state) Line 1086 (godot\modules\gdscript\gdscript_function.cpp:1086)
godot.windows.tools.64.exe!GDScriptInstance::call(const StringName & p_method, const Variant * * p_args, int p_argcount, Variant::CallError & r_error) Line 1239 (godot\modules\gdscript\gdscript.cpp:1239)
godot.windows.tools.64.exe!Object::call(const StringName & p_method, const Variant * * p_args, int p_argcount, Variant::CallError & r_error) Line 901 (godot\core\object.cpp:901)
godot.windows.tools.64.exe!Variant::call_ptr(const StringName & p_method, const Variant * * p_args, int p_argcount, Variant * r_ret, Variant::CallError & r_error) Line 1128 (godot\core\variant_call.cpp:1128)
godot.windows.tools.64.exe!GDScriptFunction::call(GDScriptInstance * p_instance, const Variant * * p_args, int p_argcount, Variant::CallError & r_err, GDScriptFunction::CallState * p_state) Line 1086 (godot\modules\gdscript\gdscript_function.cpp:1086)

While running tests in GUT project, the debugger stops here, for some reason:

And then there's a warning:

Steps to reproduce:
Compile Godot 3.2.4 with Goost and run the GUT test project there.

Currently, it keeps hanging on tests in CI: https://github.com/goostengine/goost/runs/1193432265, but will eventually fail.

Minimal reproduction project:
I cannot find a minimal project which could reproduce this issue, not even with meta tests which test GUT itself.

[Xrayez]

So, the issue is that it somehow keeps breaking into the function and continuously prints:

Debugger Break, Reason: 'Attempt to call function 'has_method' in base 'null instance' on a null instance.'
*Frame 0 - res://addons/gut/test.gd:186 in function '_get_obj_filename'
Enter "help" for assistance.
Debugger Break, Reason: 'Attempt to call function 'has_method' in base 'null instance' on a null instance.'
*Frame 0 - res://addons/gut/test.gd:186 in function '_get_obj_filename'
Enter "help" for assistance.
Debugger Break, Reason: 'Attempt to call function 'has_method' in base 'null instance' on a null instance.'
*Frame 0 - res://addons/gut/test.gd:186 in function '_get_obj_filename'
Enter "help" for assistance.

[RandomShaper]

It's due to #41866, where dangling variables no longer are treated as null, to keep the behavior more similar to what you'd get on release.

The key point here is that with the debugger attached what you get when stringifying a dangling variable is "[Deleted Object]".

[Xrayez]

Ok, I'll try to update GUT version and/or try to fix this in GUT then.

[Xrayez]

Fixed in goostengine/goost#21, see details there.

I've took the linked list implementation from Godot, and this may also apply to Godot on the core level.

Namely, I'm not sure whether the pointer has to be reset to nullptr after memdelete:

godot/core/list.h

Lines 164 to 165 in 25ca77c

	memdelete_allocator<Element, A>(const_cast<Element *>(p_I));
	size_cache--;

May also explain the discussion in #42136.