Open kgensou opened 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.
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
I'll try again on a development build later tonight to see if that resolves the issue.
@kgensou i actually just tried it on 3.0.6 i can't get it to crash. i tried all 4 corners
Maybe it has something to do with #19628.
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
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.
wow, even since 2014 or so, i've never experienced or heard of this issue.. wtf lol
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.
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.
Still happens on 3.1.1 (RTX 2070, Windows 64)
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.
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!
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.
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
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?
I can only confirm that it still happens in 3.2.1 :
I got exactly same crash and I found when it happens.
I'm using laptop with two graphic cards:
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.
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?
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.
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.
@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.
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.
Same issue with 3.2.2, RTX 2060
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.
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)
This crash no longer happens for me in 3.4.stable.mono, still using 472.12 Nvidia drivers.
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.
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
.
so i got to wait for the 3.5 version?
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.
then 4.0?
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.
The DisplayServer Refractoring is pretty cool! I am wondering why it cant be backported to 3.x?
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
.
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
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.
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.
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 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.
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.
Steps to reproduce:
Minimal reproduction project: Any, as far as I can tell. Create a new project, add a panel and build/test it.