Game crashes if it has a 3D camera and windowsize is reduced to 1 pixel wide/tall.

[esijg]

Godot version:
Godot 3.0.3

OS/device including version:
Ubuntu 18.04 64bit on AMD Cayman (HD 6950) and Mesa 18.0.0-rc5.
Intel® Core™ i5-4570 CPU @ 3.20GHz × 4

Issue description:
In a 3d scene with camera, if scene is played in windowed mode and the user reduces the size of the window to 1 pixel (or less) tall or wide, the game will silently crash.

This bug gives the following terminal output when launched from Godot editor

ERROR: operator[]: FATAL: Index p_index=0 out of size (size()=0)
   At: core/vector.h:138.
handle_crash: Program crashed with signal 4
Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues
[1] /lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7f995f509f20] (??:0)
[2] /home/johannesg/bin/Godot_v3.0.3-stable_x11.64() [0xbd5267] (<artificial>:?)
[3] /home/johannesg/bin/Godot_v3.0.3-stable_x11.64() [0xc0af84] (<artificial>:?)
[4] /home/johannesg/bin/Godot_v3.0.3-stable_x11.64() [0xc84ffa] (<artificial>:?)
[5] /home/johannesg/bin/Godot_v3.0.3-stable_x11.64() [0x176879d] (<artificial>:?)
[6] /home/johannesg/bin/Godot_v3.0.3-stable_x11.64() [0x1769377] (<artificial>:?)
[7] /home/johannesg/bin/Godot_v3.0.3-stable_x11.64() [0x1784be0] (<artificial>:?)
[8] /home/johannesg/bin/Godot_v3.0.3-stable_x11.64() [0x17872d1] (<artificial>:?)
[9] /home/johannesg/bin/Godot_v3.0.3-stable_x11.64() [0x85e435] (??:?)
[10] /home/johannesg/bin/Godot_v3.0.3-stable_x11.64() [0x6ce7ad] (??:?)
[11] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f995f4ecb97] (??:0)
[12] /home/johannesg/bin/Godot_v3.0.3-stable_x11.64() [0x6dabbe] (??:?)
-- END OF BACKTRACE --

This bug gives the following terminal output when the project is exported and launched directly.

ERROR: operator[]: FATAL: Index p_index=0 out of size (size()=0)
   At: core/vector.h:138.
Illegal instruction (core dumped)

Steps to reproduce:

1. Create a new scene with only a 3d Camera.
2. Play the scene
3. Resize window so that it takes up as little vertical or horizontal space as possible. 1 pixel or less.

Minimal reproduction project:

TinyWindowBug.zip

[malbach]

Hi,

I can confirm this bug using master from 5c5aafa

I could trace it down to RasterizerSceneGLES3::_post_process in file drivers/gles3/rasterizer_scene_gles3.cpp

Here is the result of exporting test project in debug and reducing window's height down to 0 :

Only solution I found to limit this problem was to add

	if (storage->frame.current_rt->effects.mip_maps[0].sizes.size() == 0)
		return;

just before

	if (storage->frame.current_rt->buffers.active) {
		//transfer to effect buffer if using buffers, also resolve MSAA

in function _post_process around line 3584 in file drivers/gles3/rasterizer_scene_gles3.cpp

But I think the real solution would be to find why the array storage->frame.current_rt->effects.mip_maps[0].sizes becomes null... am I wrong ?

[codeinclined]

I also found what @malbach found using Visual Studio's debugger. I verified that the sizes vector is coming into the _post_process method empty when the height of the viewport is set to 0 by setting a conditional breakpoint in Visual Studio at the top of the method for when sizes._ptr is null. Therefore, it's happening somewhere else in the code base. I tried a few things, but couldn't find a fix.

[malbach]

Hi,
I think it's coming from function _render_target_allocate in file drivers/gles3/rasterizer_storage_gles3.cpp

This function returns directly if width or height is <=0, thus not allocating what's necessary for _post_process... well I think it is that 😅
For me the simplest solution would be to limit the windows's size to (1,1) in Godot but I don't know how to do it 😕

For reference, this bug has already been reported in #19207

[codeinclined]

So, I just set a conditional breakpoint on the following line of draw_viewports() in visual_server_viewport.cpp to trigger whenever the viewport size is less than 2:

visible = visible && vp->size.x > 0 && vp->size.y > 0;

It triggers when size.y is 1 as expected when I shrink down the window height.

I was able to fix the crashing by changing that line I referenced above to the following:

visible = visible && vp->size.x > 1 && vp->size.y > 1;

I think this is an acceptable and simple enough tradeoff (it skips rendering viewports with a width or height less than 2) to prevent the crashes for now, and I will likely put in a PR referencing this issue to see what the devs think about making this tradeoff.

I am very curious why a 1 height viewport is causing the mipmap sizes to go away. I tried changing some things in methods like _render_target_allocate() to see if the sizes Vector would stop being empty to no avail. Again, until the true root cause is identified, I think my proposed change is worth the tradeoff.

[lekoder]

I'm at build 1fc7973, which includes #20026 and I'm still experiencing this problem (with 2D project) - it crashes as soon as window height is dragged down to 0 with:

ERROR: Vector<struct RasterizerStorageGLES3::RenderTarget::Effects::MipMaps::Size>::operator []: 
   FATAL: Index p_index=1 out of size (size()=1)
   At: d:\projects\godot\core\vector.h:138

[malbach]

Hi,
I'm on me holidays so not able to compile but can someone test this for me ?
In function _render_target_allocate(), replace

if (rt->width <= 0 || rt->height <= 0)
return;

with

rt->width = rt->width > 0 ? rt->width : 1;
rt->height = rt->height > 0 ? rt->height : 1;

[lekoder]

@malbach compiled with patch, didn't help. Still crashed with same error.

[malbach]

@lekoder ok thx for the test
did u try my first solution ?

[lekoder]

@malbach I did now, it did not help either.

[malbach]

Hi,
Looks like a Windows problem, didn't test on iOS, but here on X11 (Xubuntu) it does not crash anymore

[codeinclined]

I'm sorry my fix didn't solve the issue. It stopped crashing for me after making the change in my PR, but obviously there's more to the issue than I had anticipated. I hope someone can figure this out, as I can no longer reproduce the crashing on my computer. I'm on Windows 10 with Intel graphics right now.

[lekoder]

@taylorjoshuaw you are correct, your PR fixed some of the issues - minimal project no longer crashes.

I managed to narrow down my issue down to glow in WorldEnvironment - once I enable it, there is a problem. I made a minimal project replicating that.

Switching to GLES2 also helps.

Hardware reference: I'm testing with Windows 10 with Intel UHD Graphics 630 and with GTX1070.

[malbach]

I should correct my own previous statement : it's also crashing in X11 with glow enabled 😢
Thanks to @lekoder narrowing down the problem, I found that it is coming from this line :

glBindFramebuffer(GL_FRAMEBUFFER, storage->frame.current_rt->effects.mip_maps[0].sizes[i + 1].fbo); //next level, since mipmaps[0] starts one level bigger

in file rasterizer_scene_gles3.cpp (around line 3931).
The problem is that when the window is reduced to 0 in width or height, the array
storage->frame.current_rt->effects.mip_maps[0].sizes only has 1 dimension, so trying to acces [i+1] is impossible, i having a value from 0 to max_glow_level+1

My first try was simply

if (storage->frame.current_rt->effects.mip_maps[0].sizes.size() > i + 1)
    glBindFramebuffer(GL_FRAMEBUFFER, storage->frame.current_rt->effects.mip_maps[0].sizes[i + 1].fbo); //next level, since mipmaps[0] starts one level bigger
else
    glBindFramebuffer(GL_FRAMEBUFFER, storage->frame.current_rt->effects.mip_maps[0].sizes[0].fbo);

and no more crash no matter how I resized the window, but it's like the first bug from the OP, I just put a patch, not a solution 🤔
For the solution, I don't exactly know how to correct it, @taylorjoshuaw could you please take a look at it ?

[ArdaE]

I get the same crash on iOS, but with a full sized viewport (1024x600 pixels or larger). I've attached a minimal scene file below, which can be dropped into any project with default settings. The mesh and the light are not instrumental in the crash; they can be removed. The scene works fine on my MacBook Pro, but crashes at core/vector.h:138 during startup on iOS.

Leading to the crash, I get half a dozen of the following error message:
At: drivers/gles3/rasterizer_storage_gles3.cpp:6383:_render_target_allocate() - Condition ' status != 0x8CD5 ' is true.
(There are various other open issues here on GitHub that report this error message, but without an accompanying crash at core/vector.h:138).

By the way, this is on an iPhone 6s, and an earlier line in the programs output says OpenGL ES 3.0 Renderer: Apple A9 GPU. Maybe the errors are causing the viewport size to be 0 and that's causing the crash? I'll try again with GLES2 when Godot 3.1 becomes available, but just wanted to report here for now in case it helps with the investigation.

TestIosCrash.tscn.zip

[akien-mga]

Cherry-picked for 3.0.7.