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

kgensou commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

kgensou commented 5 years ago

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

girng commented 5 years ago

@kgensou i actually just tried it on 3.0.6 i can't get it to crash. i tried all 4 corners

Xrayez commented 5 years ago

Maybe it has something to do with #19628.

girng commented 5 years ago

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 commented 5 years ago

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 1ff502c5f4 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. GIF of described issue

girng commented 5 years ago

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

Calinou commented 5 years ago

I couldn't reproduce this bug on commit https://github.com/godotengine/godot/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 commented 5 years ago

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 commented 5 years ago

Still happens on 3.1.1 (RTX 2070, Windows 64)

ghost commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

I can only confirm that it still happens in 3.2.1 :

output

Supaplex77 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 ( 20a6fcd3ea72b3c26eeb3479709e5b2d2701fbd) 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.

Zireael07 commented 4 years ago

@kgensou: Close, master uses Vulkan only now, there are plans to use OpenGL 2 as a lower-end option, but it's not done yet. OpenGL 3 is going to be phased out, but 2 is going to stay - and you said the crash is present in OpenGL2, too, that is bad news and even more proof that this is likely on the drivers, not Godot.

Calinou commented 4 years ago

OpenGL 3 is going to be phased out

Actually, probably not: https://github.com/godotengine/godot-proposals/issues/877

Still, if your GPU supports Vulkan (which all Kepler+ NVIDIA GPUs do), this shouldn't be a problem.

ghost commented 3 years ago

Same issue with 3.2.2, RTX 2060

Supergeek commented 3 years ago

Because it's been a while since there's been an update to this thread, just reporting in to say this still happens, using 3.3.4-stable-mono with an RTX 3060 and Nvidia drivers 472.12. It works okay most of the time just resizing a window like a sane person, but if you scrub the resize corner in a circular motion, the crash happens within a few frames for me every time.

ProgrammerJames commented 3 years ago

Same thing here, tried on 3.3.4 stable win64 version, I'm using an Nvidia GTX 1650 super, no errors show up at all, just crashes the window, I've not had any issues with any windows with OpenGL on this PC, even with a barebones OpenGL window project in C++ (just to add some more information out there)

Supergeek commented 2 years ago

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

akien-mga commented 2 years ago

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 commented 2 years ago

Reopening, as this still occurs as per https://github.com/godotengine/godot/issues/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 commented 2 years ago

so i got to wait for the 3.5 version?

Calinou commented 2 years ago

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 commented 2 years ago

then 4.0?

Calinou commented 2 years ago

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 commented 2 years ago

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

Calinou commented 2 years ago

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 commented 2 years ago

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 Screenshot (20) I wonder why it's trying to open epic games folder which doesn't even exists anymore

Calinou commented 2 years ago

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 https://github.com/godotengine/godot-proposals/issues/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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

Calinou commented 2 years ago

@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.

godotengine / godot

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