akien-mga
commented
12 months ago CC @YuriSizov @bruvzg
More woes with EditorResourcePreview triggering the SurfaceUpgradeTool possibly too early?
Closed Malcolmnixon closed 12 months ago
akien-mga
commented
12 months ago CC @YuriSizov @bruvzg
More woes with EditorResourcePreview triggering the SurfaceUpgradeTool possibly too early?
bruvzg
commented
12 months ago trying to do a blocking SetWindowTextW call - a call which requires the Main Thread message pump to process
I guess we can defer the call if it's done for non-main thread, but there are likely other WinAPI functions that have the same issue, so this should be investigated further.
Something like:
diff --git a/platform/windows/display_server_windows.cpp b/platform/windows/display_server_windows.cpp
index e8d81405f0..b217a906f3 100644
--- a/platform/windows/display_server_windows.cpp
+++ b/platform/windows/display_server_windows.cpp
@@ -1221,13 +1221,19 @@ void DisplayServerWindows::window_set_drop_files_callback(const Callable &p_call
windows[p_window].drop_files_callback = p_callable;
}
-void DisplayServerWindows::window_set_title(const String &p_title, WindowID p_window) {
- _THREAD_SAFE_METHOD_
-
+void DisplayServerWindows::_window_set_title(const String &p_title, WindowID p_window) {
ERR_FAIL_COND(!windows.has(p_window));
SetWindowTextW(windows[p_window].hWnd, (LPCWSTR)(p_title.utf16().get_data()));
}
+void DisplayServerWindows::window_set_title(const String &p_title, WindowID p_window) {
+ if (!Thread::is_main_thread()) {
+ callable_mp((DisplayServerWindows *)get_singleton(), &DisplayServerWindows::_window_set_title).call_deferred(p_title, p_window);
+ } else {
+ _window_set_title(p_title, p_window);
+ }
+}
+
Size2i DisplayServerWindows::window_get_title_size(const String &p_title, WindowID p_window) const {
_THREAD_SAFE_METHOD_
diff --git a/platform/windows/display_server_windows.h b/platform/windows/display_server_windows.h
index 48c8c20280..2ab0af671c 100644
--- a/platform/windows/display_server_windows.h
+++ b/platform/windows/display_server_windows.h
@@ -492,6 +492,8 @@ class DisplayServerWindows : public DisplayServer {
LRESULT _handle_early_window_message(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam);
Point2i _get_screens_origin() const;
+ void _window_set_title(const String &p_title, WindowID p_window = MAIN_WINDOW_ID);
+
public:
LRESULT WndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam);
LRESULT MouseProc(int code, WPARAM wParam, LPARAM lParam);Edit: This seems to be fixing deadlock, but test project seems to be always crashing (after a lot of physics server related errors).
Godot version
7022271291a3d2a9cbd6a223d22a29fd775dfc5d
System information
Windows 11, gl_compatibility, NVidia RTX 3070 TI
Issue description
A deadlock can occur during application startup with the following:
The Worker Thread owns the DisplayServerWindows mutex and is trying to do a blocking SetWindowTextW call - a call which requires the Main Thread message pump to process; however the Main Thread is blocked trying to get hold of the very mutex locked by the worker thread.
Main Thread Call Stack:
Worker Thread Call Stack:
Steps to reproduce
Happens when opening a project that has many meshes. This occurred opening https://github.com/Malcolmnixon/TiltFiveMapTest
Minimal reproduction project
It seems to be a russian-roulette with large projects - the project in the reproduce steps causes it.