Godot crashes on window resize on NVIDIA graphics cards (fixed in master)

[kgensou]

---

Bugsquad edit: This issue has been confirmed several times already. No need to confirm it further.

---

Godot version:
v3.0.6 (About page lists Godot Engine v3.0.6.stable.official.8314054)

OS/device including version:
Windows 10 Pro, NVIDIA Display Driver v417.35
Godot executable console prints 'OpenGL ES 3.0 Renderer: GeForce GTX 1080/PCIe/SSE2'

Issue description:
This happens to me with all Godot-built applications I've tried and/or built myself so far. Upon every resize along a corner, the application runs the risk of crashing. This will give no error, but silently exit the application. While it does give a 'server disconnected' error, I presume this is the debugging socket.

• The crash can be triggered by (rapidly) resizing the window by clicking and dragging along the corners only. If you resize it slower, it will still crash, but take a longer time.
• This happens with any project I've tested so far. To test, I have started a new project, added a single Panel, and built the executable. This will also crash with the step described above.
• It will not occur when resizing along only one axis, not along any single edge.
• It will not occur when maximizing or restoring the window, no matter how often.
• Moving the whole application window off the screen to force repainting will not crash it either.

Steps to reproduce:

• Build a Godot application on Windows, or run the project from within the editor. Make sure the project is windowed, and the settings allow for resizing the window.
• Resize the application along any corner point. It has to be a corner. Dragging the corner around fast will make the crash occur earlier. If the mouse is jerked around fast enough, it will always crash within a second.
• The application will lock up for a second, then silently crash.

Minimal reproduction project:
Any, as far as I can tell. Create a new project, add a panel and build/test it.

[kgensou]

I cannot reproduce the issue with a Linux-built executable. However, the Linux executable also blanks the window while it's being resized. I suspect this is related.

[girng]

similar setup here, but gtx 950. can't replicate on build 9ba6849
tried with debug enabled and disabled. i'm jerking the mouse very hard as well. can't trigger it

[kgensou]

I'll try again on a development build later tonight to see if that resolves the issue.

[girng]

@kgensou i actually just tried it on 3.0.6

i can't get it to crash. i tried all 4 corners

[Xrayez]

Maybe it has something to do with #19628.

[girng]

i'll bet my left kidney this is prob a rare edge case bug with nvidia drivers (windows only). makes me want to test this on my AMD card, but can't find it

[kgensou]

Thank you for the fast responses and your time!

@Xrayez I think that's a different issue, since it shows an error and the crash happens a lot earlier in my case. What @girng shows in their recording is exactly what will crash it for me, as described. If I'd do it on my system it would exit without displaying an error. If run from a command prompt, the variable %ERRORLEVEL% contains -1073741819 afterwards.

I've managed to build version 1ff502c but still experience the same issue. (Huge props to the team for making building an easy and painless effort!) Since this looks like a very localized issue, is there anything I can do to help debug it?

I'm using Visual Studio Community 2017. The debugger quits as soon as the project view is closed, and I'm not sure how to debug the editor itself (or ultimately the resulting project). I realize that's more of a C++ general question, but I'd like to add useful information to this issue if possible. If I can provide any other information that would help, let me know.

I've added a short recording to show what it looks like for me.

[girng]

wow, even since 2014 or so, i've never experienced or heard of this issue.. wtf lol

[Calinou]

I couldn't reproduce this bug on commit cd22551d2 using the llvmpipe software driver from mesa-dist-win. I tested both GLES3 and GLES2 renderers.

@kgensou Can you still reproduce this issue on 3.1.1 stable or a daily build? If so, you could also try reproducing the bug with the GLES2 renderer, so that we can determine whether the bug is renderer-specific.

[RafeHall]

Having the same problem, it's happening in all the available versions of godot on the website and the daily build. Changing the renderer to GLES2 doesn't make any difference either. I attempted to try and debug using visual studio and got an access violation exception.

[noozo]

Still happens on 3.1.1 (RTX 2070, Windows 64)

[ghost]

I'm using Visual Studio Community 2017. The debugger quits as soon as the project view is closed, and I'm not sure how to debug the editor itself (or ultimately the resulting project).

If you have the VS Project from building with scons, the debugger has to be attached to it, but it will disconnect when opening a project from the Project Manager window. The quickest way around it is to directly launch the debugger into a project using the -e command argument.

In the Godot project properties, there is a place for arguments. As seen in the screenshot below. Put a path to a project file there.

As far as debugging a built project, I haven't yet experimented with that, so couldn't give any specific instructions.

[ColinJTod]

I have been suffering from this problem too.

I just noticed that the debugger was spewing out hundreds of warnings about font oversampling not working and it was annoying me. I am not actually using font oversampling at the moment so I had a poke around and found where to disable it ... (Project Settings, Rendering, Quality, Use Oversampling). I turned it off, which stopped the warnings and suddenly the resizing crashes stopped too!

I have been trying for several minutes to get another crash and can't - it only used to last a few seconds before.

I hope that helps and gives somebody smarter than me an idea about what is going on!

[ColinJTod]

And of course, about 10 seconds after I posted that ... it crashed!

Still, it is much more robust than it was before and I can live with it while somebody fixes it.

PS 6 days on and I haven't managed to crash it again, so it is MUCH more reliable.

[hedrickbt]

Turning off the oversampling setting didn't make it any more robust for me. If I move the window around ( just a single UI object with a black colorrect ) no problems. But as soon as I start resizing, within seconds, it crashes.

Running: C:\Program Files\godot\Godot_v3.1.1-stable_win64.exe\Godot_v3.1.1-stable_win64.exe --path D:/data/SpiderOak/projects/ParentChildClub/godot/godot-getaway/godot-getaway/sol-02-02-preparing-the-multiplayer-lobby --remote-debug 127.0.0.1:6007 --allow_focus_steal_pid 7712 --position 1408,780 res://Lobby/Lobby.tscn
OpenGL ES 3.0 Renderer: GeForce GTX 1080/PCIe/SSE2
ERROR: _get_socket_error: Socket error: 10054
   At: drivers/unix/net_socket_posix.cpp:190

[Anutrix]

Any reliable way to reproduce this on 3.2.1? I couldn't reproduce this on Windows 10 though I don't using any GPU. Is this confirmed to be Nvidia related?

[TheMoye]

I can only confirm that it still happens in 3.2.1 :

[Supaplex77]

I got exactly same crash and I found when it happens.

I'm using laptop with two graphic cards:

• Intel HD Graphics 4600
• NVIDIA Geforce GTX 960M

When I switch to Intel, everything is ok, I can resize the window.
When I switch to NVIDIA, godot crashes.

I hope this helps someone who tries to solve this problem.

[ghost]

I have an old GeForce 9600 GT and a GeForce GTX 1660 SUPER, and two other types of GeForce in other non-work machines. I haven't had this kind crashing, and cannot reproduce it.

Is it the GTX 960M to 1080 models? If it is these and the drivers, are there any versions of the drivers that don't have the problem?

[kgensou]

I'm also betting on it being an NVIDIA exclusive issue, but I have no reliable way to confirm this. I've retested it with the most recent version on my Windows installation (Godot Engine v3.2.1.stable.official at the time of writing) and still experience this issue. The NVIDIA driver version is now 432.00.

There doesn't seem to be a difference in the time it takes to crash since my original post. I am still using the same GTX 1080. I've not yet found a driver version without this problem. There is still no error on crashing. On exit, it still only prints 'Debugging process stopped' with no additional information.

[kgensou]

It also seems to be OpenGL specific. The crash happens with both OpenGL ES 2.0 and 3.0. I've tried building the latest commit on master ( 20a6fcd) and running a sample project with --path, and it will not crash - but it seems to be using the Vulkan renderer instead of OpenGL. Vulkan is also the only selectable renderer when building the editor locally.

Am I missing a build flag to be able to select OpenGL? I may be able to further debug this issue if I can reproduce it. If the idea is to phase out OpenGL ES 3.0 in favour of Vulkan, then this issue may no longer be relevant in the future.

[Supergeek]

This crash no longer happens for me in 3.4.stable.mono, still using 472.12 Nvidia drivers.

[akien-mga]

This was probably fixed / worked around by #51973 indeed. It might still be possible to trigger the issue by calling OS.set_min_window_size(Vector2(0, 0)), but at least that's called out in the docs and no longer the default.

[Calinou]

Reopening, as this still occurs as per #24702 (even if the minimum window size can no longer go to (0, 0) by default).

This bug is most likely fixed in master as part of the DisplayServer refactoring, but it should still be fixed in 3.x.

[CR-Studios]

so i got to wait for the 3.5 version?

[Calinou]

so i got to wait for the 3.5 version?

This hasn't been fixed in the 3.x branch yet, simply because we don't know how to fix the issue.

[CR-Studios]

then 4.0?

[Calinou]

then 4.0?

This is indeed fixed in the master branch (which will be released as 4.0 in the future), thanks to the DisplayServer refactoring. It's not something we can backport to 3.x though.

[CR-Studios]

The DisplayServer Refractoring is pretty cool! I am wondering why it cant be backported to 3.x?

[Calinou]

The DisplayServer Refractoring is pretty cool! I am wondering why it cant be backported to 3.x?

The DisplayServer refactoring involved many backwards-incompatible changes, which is why it can't be backported to 3.x.

[CR-Studios]

Well, I tried 4.0 and the problem's fixed. But the engine has gone pretty slow to open, run etc. and even the resizing is not smooth, (even though i got pretty powerful laptop) and i get a bunch of errors on startup

I wonder why it's trying to open epic games folder which doesn't even exists anymore

[Calinou]

You can ignore those Vulkan errors – these will be silenced eventually.

But the engine has gone pretty slow to open, run etc.

The engine needs to compile shaders when it starts. These shaders are then cached so they no longer need to be compiled on subsequent runs. See also godotengine/godot-proposals#3657.

and even the resizing is not smooth,

Rendering buffer recreation could likely be further optimized. Either way, window resizing isn't something people do often in games (if at all), so it's not critical for now.

[BigBugBang]

I did a test today, I resized the window with the mouse but only on one direction and Godot does not crash. You can resize the window without crashing if you don't use a corner of the window.

[SchezoWegey]

This is not a NVIDIA specific crash. I have a 6800 and Ryzen cpu and experience the same exact crash as OP. Though if the game starts in fullscreen mode, my computer most of the time freezes then restarts. On rare occasions my computer will not reset and instead the AMD software tells me that there has been a driver timeout. Note any godot game runs perfectly in windowed mode on startup and will start normally ONCE in fullscreen then will crash after any other openings of a game.

[SchezoWegey]

[SchezoWegey]

[SchezoWegey]

[Calinou]

@SchezoWegey PS: In the future, please use the Edit button (located behind the … icon in the top-right corner of your comments) instead of multi-posting.