Thanks for the response.

I could try simplifying it a bit, but as I mentioned, the bug is quite devastating and forces me to restart, so I can't iterate easily.

Also, the problem only surfaces when I try to render the whole scene. The scene itself is not that big, just a room and a character. I can render the room (with some hiccups), and character separately. I'm guessing it's some memory issue (computer has 8gb of RAM, GPU 2gb). I'm using default settings in Blender. Windows also generates massive memory dumps every time it happens.

In any case, I will try reducing the the size of it (right now it's around 300 mb with all assets packed) by removing some materials. But the licensing issues will still remain. Can't I just upload the file and only add members of the project in the visibility options? you could also tell me which other people to add.

Hello, in the end I was finally able to find the source of the problem. The scene had several 4k textures and after changing settings so the texture "Limit Size" was 1024 (instead of the default "no limit"), the shader compilation went smoother, the program didn't stall and it rendered the scene as expected. Also when working with that limit the program didn't have those big hiccups. I also changed Image Display Method to "2D Texture".

I also disabled the auto-save feature which I found to be quite demanding on resources, and also led to hiccups (even with small .blend files).

To sum up, I don't think I found bugs but optimizations issues (unless GLSL was also part of the problem).

I think the program should be a little more conservative resource-wise, and not take over all system resources like it currently does. A warning when texture sizes are too big would be welcomed. A global ram limit setting would also be a good addition. Furthermore, is there any reason why shader compilation is not cached long-term (and saved with the project)? something like what Unreal 4 does would be great. Also separating the shader compilation phase from rendering would be cleaner and easier on the system.

Nonetheless, an important remark should be made: when rendering the same scene in Cycles (with all 4k textures and "no limit") none of these problems surfaced (it was slow but it eventually rendered, it didn't stall and freeze the entire OS like Eevee does). So I suspect the way Eevee handles shader compilation with big textures might be part of the problem too. Note: I use CPU rendering in Cycles (with 8gb of RAM), while Eevee is using the GPU (both of the GPUs gave me the same problems). The NVIDIA GPU has 2gb of memory.

So I think this Task should be closed, or relabeled to "feedback" or something like that.

Note: The presence of even a single 4k .tif normal map texture (around 10mb in size), even with a limit of 1024, slows down the rendering in Eevee considerably. This normal is plugged into a Normal Map node and then into the Normal input of a Bump node and finally into the normal input of the Principled node (so the material uses both a bump .jpg texture and normal texture). All I mentioned above only used .jpg textures, so the original problem was not related to this. This is just a side problem I found while setting up the scene.