-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
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
SurfaceUpgradeTool::_show_popup
deadlock when loading project imported in 4.1 in 4.2 beta (self-contained editors)
#84732
Comments
Did some more testing, I'm not sure anymore whether it's a regression, and it only seems to appear with a somewhat baroque setup. My Godot 4.1.3 is used self-contained, so it doesn't share its editor data with my 4.2 snapshots / git builds, which are not self-contained and use the editor data installed in the default user folders (notably This seems to be important, and the problem seems related to generating the |
GDScriptCache::get_full_script
deadlock when loading medium size 4.1 project in 4.2 betaGDScriptCache::get_full_script
deadlock when loading medium size 4.1 project in 4.2 beta (self-contained editor issue)
GDScriptCache::get_full_script
deadlock when loading medium size 4.1 project in 4.2 beta (self-contained editor issue)SurfaceUpgradeTool::_show_popup
deadlock when loading project imported in 4.1 in 4.2 beta (self-contained editors)
So @YuriSizov and I did some digging, and the problem is indeed tied to using self-contained editors / separate editor caches in the migration from a Our friend
To reproduce this consistently, these are clearer steps:
|
Not the good way to go probably, but we're seeing more than one "regression" on imported files in the .godot folder. Would it make sense to force a full reimport upon minor release? |
@QbieShay Do you have specific issues in mind? Because this one is not about imported assets. It's about threading issues in the resource preview generator, something that we unfortunately always had. A full reimport doesn't help, not directly at least. You may offset timing of some things and "fix" the issue, but this doesn't really address the problem at its core. |
Godot version
4.2.beta5,
master
(e38686f)System information
Mageia 9 - Vulkan (Forward+) - dedicated AMD Radeon RX Vega M GL Graphics (RADV VEGAM) () - Intel(R) Core(TM) i7-8705G CPU @ 3.10GHz (8 Threads)
Issue description
I noticed a deadlock in
GDScriptCache::get_full_script
when trying to open GDQuest's 3D TPS demo in 4.2 beta 5 and latestmaster
(e38686f). I haven't yet tested earlier versions to see whether I can pinpoint a regression time, I'll do that next.It happens when opening the project in Godot 4.2 after having opened it once in 4.1.3, ensuring that all files in
.godot
have been generated by 4.1.3.The editor freezes, and attaching a debugger gives me this stacktrace of where it seems to be stuck, on a mutex in
GDScriptCache::get_full_script
:Steps to reproduce
Edit: See below, at least one of the two Godot versions must be self-contained to reproduce the issue.
.godot
is deleted, also remove the Godot cache for good measure (~/.cache/godot/
or similar locations) - that last part may not be needed but I haven't tested without that step.git checkout
any changes made by Godot 4.2, clean.godot
, etc.Minimal reproduction project
Not really minimal, I haven't yet tried to narrow it down.
But the stacktrace suggests an issue with GDScript, possibly preloading or cyclic references.
The text was updated successfully, but these errors were encountered: