Godot: Mono: Game crash when setting Physics > 2D > Thread model to Multi-Threading

Created on 19 Nov 2019 · 12Comments · Source: godotengine/godot

Godot version:
Godot Mono Beta.1
OS/device including version:
Windows 10 1903
Issue description:
While doing a physics stress test (snow ❤️) setting Thread model for physics to Multi-Threading in Godot (Mono) causes the game to crash with the following error:

ERROR: Can't change this state while flushing queries. Use call_deferred() or set_deferred() to change monitoring state which makes no sense and gives no more clues of what might be wrong. I also tried as suggested to change the code to use call_deffered and set_deffered but it made no difference.
PhysicsStressTest

When running the same project in Godot 3.1.1 Stable it does not crash when enabling Multi-Threading but also it doesn't seem to be making any difference. CPU usage does not go beyond 30~40% (which is the maximum of the main core i assume).

Steps to reproduce:
Run the attached project.
Minimal reproduction project:
Physics stress test.zip

EDIT: Its the same error in 3.1.1. The difference is that the game does not crash (then again Mono version seems to be crashing on every error?)

ERROR: Can't change this state while flushing queries. Use call_deferred() or set_deferred() to change monitoring state when enabling Physics > 2D > Multi-Threading
EDIT: Also tried running queue_free inside _physics_process instead of _process. Same error.

~- Godot Mono is crashing on every error.~ This has been fixed by https://github.com/godotengine/build-containers/pull/36

bug crash mono physics

Source

zaksnet

👍1

All 12 comments

Single Threaded (Safe) Physics on Godot 3.1.1 does not Crash

No crashes, no error messages.
CPU Usage is at 100% on the Godot Process 1 and around 17% on Godot Process 2

Multi Threaded Physics on Godot 3.1.1 does not Crash

However, I get a bunch of these errors:
CPU Usage is around 112-115% on Godot Process 1 and 20-25% on Godot Process 2, so it appears some type of multi-threading is going on (?).
Also noticed significant slowdowns/hiccups on occasion.

This was Tested on Linux x64 on Godot Mono v3.1.1 (even though there was no c# code in the attached file)

Tested under Godot 3.2 Beta 2 (non mono version) with Multi-Threaded Physics

No crashing under Linux x64, but getting the same errors as above.

gururise on 23 Nov 2019

👍1

Godot 3.2 Beta 2 - MONO version w/Multi-Threaded Physics crashes:

ERROR: bind: Method/Function Failed, returning: ERR_UNAVAILABLE
   At: drivers/unix/net_socket_posix.cpp:390.
Running: /home/gene/Downloads/Godot_v3.2-beta2_mono_x11_64/Godot_v3.2-beta2_mono_x11.64 --path /home/gene/Documents/Godot/Physics%20stress%20test --remote-debug 127.0.0.1:6007 --allow_focus_steal_pid 553816 --position 3328,420
Godot Engine v3.2.beta2.mono.official - https://godotengine.org
OpenGL ES 3.0 Renderer: GeForce GTX 1060 6GB/PCIe/SSE2

Mono: Logfile is: /home/gene/.local/share/godot/mono/mono_logs/2019_11_23 16.14.03 (553885).txt
ERROR: body_set_shape_disabled: Can't change this state while flushing queries. Use call_deferred() or set_deferred() to change monitoring state instead.
   At: servers/physics_2d/physics_2d_server_sw.cpp:730.

=================================================================
    Native Crash Reporting
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

=================================================================
    Native stacktrace:
=================================================================
    0xcfef34 - /home/gene/Downloads/Godot_v3.2-beta2_mono_x11_64/Godot_v3.2-beta2_mono_x11.64 : (null)
    0xcff2ac - /home/gene/Downloads/Godot_v3.2-beta2_mono_x11_64/Godot_v3.2-beta2_mono_x11.64 : (null)
    0xcf1d58 - /home/gene/Downloads/Godot_v3.2-beta2_mono_x11_64/Godot_v3.2-beta2_mono_x11.64 : (null)
    0xd01fbe - /home/gene/Downloads/Godot_v3.2-beta2_mono_x11_64/Godot_v3.2-beta2_mono_x11.64 : (null)
    0x7f6fab042930 - /usr/lib/libpthread.so.0 : (null)
    0xe3ce97 - /home/gene/Downloads/Godot_v3.2-beta2_mono_x11_64/Godot_v3.2-beta2_mono_x11.64 : (null)
    0xe3fb39 - /home/gene/Downloads/Godot_v3.2-beta2_mono_x11_64/Godot_v3.2-beta2_mono_x11.64 : (null)
    0xe3fbab - /home/gene/Downloads/Godot_v3.2-beta2_mono_x11_64/Godot_v3.2-beta2_mono_x11.64 : mono_object_new
    0x2d7657b - /home/gene/Downloads/Godot_v3.2-beta2_mono_x11_64/Godot_v3.2-beta2_mono_x11.64 : _ZN14CSharpLanguage28debug_get_current_stack_infoEv
    0x1775037 - /home/gene/Downloads/Godot_v3.2-beta2_mono_x11_64/Godot_v3.2-beta2_mono_x11.64 : _ZN20ScriptDebuggerRemote12_err_handlerEPvPKcS2_iS2_S2_16ErrorHandlerType
    0x12b7d0d - /home/gene/Downloads/Godot_v3.2-beta2_mono_x11_64/Godot_v3.2-beta2_mono_x11.64 : _Z16_err_print_errorPKcS0_iS0_S0_16ErrorHandlerType
    0x1667269 - /home/gene/Downloads/Godot_v3.2-beta2_mono_x11_64/Godot_v3.2-beta2_mono_x11.64 : _ZN21Physics2DServerWrapMT11thread_loopEv
    0x29a97b5 - /home/gene/Downloads/Godot_v3.2-beta2_mono_x11_64/Godot_v3.2-beta2_mono_x11.64 : _ZN11ThreadPosix15thread_callbackEPv
    0x7f6fab0374cf - /usr/lib/libpthread.so.0 : (null)
    0x7f6faae102d3 - /usr/lib/libc.so.6 : clone

=================================================================
    Telemetry Dumper:
=================================================================
Thread 0x7f6f878f9700 may have been prematurely finalized* Assertion at mono-threads.c:650, condition `info' not met, function:mono_thread_info_current,

Log File
2019_11_23 16.14.03 (553885).txt

gururise on 24 Nov 2019

Can you still reproduce this with 3.2 RC1?

neikeq on 18 Jan 2020

Can you still reproduce this with 3.2 RC1?

Yes. Under 3.2 RC1 (Mono x64 Linux):

Godot Engine v3.2.rc1.mono.official - https://godotengine.org
OpenGL ES 3.0 Renderer: GeForce GTX 1060 6GB/PCIe/SSE2

Mono: Logfile is: /home/gene/.local/share/godot/mono/mono_logs/2020_01_18 10.28.25 (533276).txt
ERROR: body_set_shape_disabled: Can't change this state while flushing queries. Use call_deferred() or set_deferred() to change monitoring state instead.
   At: servers/physics_2d/physics_2d_server_sw.cpp:730.
ERROR: body_set_shape_as_one_way_collision: Can't change this state while flushing queries. Use call_deferred() or set_deferred() to change monitoring state instead.
   At: servers/physics_2d/physics_2d_server_sw.cpp:739.
ERROR: mono_log_callback: Mono: FATAL ERROR, ABORTING! Logfile: '/home/gene/.local/share/godot/mono/mono_logs/2020_01_18 10.28.25 (533276).txt'.
   At: modules/mono/mono_gd/gd_mono_log.cpp:86.

=================================================================
    Native Crash Reporting
=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

Log File
2020_01_18 10.28.25 (533276).txt

gururise on 18 Jan 2020

👍1

It's a different crash now. Mono's debugger agent has an assertion that doesn't take into account the possibility of a thread attaching, detaching and then attaching again. Looks like Unity had the same issue as they patched it in their fork of Mono: https://github.com/Unity-Technologies/mono/commit/995768f7dc3af7b3d19fcedd1244087a4a89bc5c

neikeq on 21 Jan 2020

Test builds with Mono rebuilt using the patch mentioned by @neikeq:

The Linux build does fix the crash for me.

akien-mga on 22 Jan 2020

🎉1

Test builds with Mono rebuilt using the patch mentioned by @neikeq:

Linux: https://downloads.tuxfamily.org/godotengine/3.2/tmp-test/Godot_v3.2-mono-tls-test_mono_x11_64.zip

Windows: https://downloads.tuxfamily.org/godotengine/3.2/tmp-test/Godot_v3.2-mono-tls-test_mono_win64.zip

macOS: https://downloads.tuxfamily.org/godotengine/3.2/tmp-test/Godot_v3.2-mono-tls-test_mono_osx.64.zip

The Linux build does fix the crash for me.

This commit seems to fix the crash for me on Windows. I will wait for @gururise to confirm also before closing as hes been spending more time on this.

I'm not sure what that commit does, but i'm concerned as to why the performance is exactly the same with Multi-Threading and with single threading. Is multi threading actually working for physics? I might be opening a new issue with some test projects and videos to demonstrate the case.

zaksnet on 22 Jan 2020

👍1

I'm not sure what that commit does, but i'm concerned as to why the performance is exactly the same with Multi-Threading and with single threading. Is multi threading actually working for physics? I might be opening a new issue with some test projects and videos to demonstrate the case.

That's a different issue though. And the example project has so many errors that performance tanks because of printing errors to the Output panel/terminal.

akien-mga on 22 Jan 2020

I'm not sure what that commit does, but i'm concerned as to why the performance is exactly the same with Multi-Threading and with single threading. Is multi threading actually working for physics? I might be opening a new issue with some test projects and videos to demonstrate the case.

That's a different issue though. And the example project has so many errors that performance tanks because of printing errors to the Output panel/terminal.

Well, looking back at the issue posted, my original problem was not the crash, it was the errors. The code is minimal and there is no indication as to what might be causing the errors. Also they seem to be linked to multi-threading which would make sense. I'd appreciate re-opening the issue since i have provided detailed instruction on how to replicate this and i will strike-through the Mono part with the commit.

zaksnet on 22 Jan 2020

@zaksnet Can that be considered the same as #26518?

neikeq on 22 Jan 2020

@neikeq Yeah sure I'm good with that.

zaksnet on 22 Jan 2020

Can confirm new build does no longer crashes using multi-threaded 2D physics. Although as @zaksnet indicated, there appear to be nearly no performance difference between single-threaded and multi-threaded physics in this example. Might be worth looking into.

gururise on 22 Jan 2020

Was this page helpful?

0 / 5 - 0 ratings