When I render, Blender hangs:
…yet it continues to display the frames of the render as they’re rendered - merely the GUI thread appears to become unresponsive.
Is this expected? If not, how might I acquire enough information to create an actionable report about this?
I’m using EEVEE.
Check out the console.
All processes that occur during rendering are recorded.
@oo_1942, I’m not sure what questions of mine that answers, or if it allows me to remediate the issue, how it does.
@oo_1942, I don’t appear to have that option:
blender.stackexchange.com/questions/145890/where-is-the-system-console#comment497809_145891 makes me worry that trying to find it might be a wild goose chase. I hope I’m not being stupid. I’ll try blenderartists.org/t/1236120/4:
Many thanks for the assistance.
@oo_1942, that seems to work. However, I’m merely seeing what I expect to be logged, based upon your screenshot’s example:
GPUTexture: Blender Texture Not Loaded! GPUTexture: Blender Texture Not Loaded! Append frame 1 Time: 00:08.26 (Saving: 00:00.01) Append frame 2 Time: 00:07.21 (Saving: 00:00.01) Append frame 3 Time: 00:07.21 (Saving: 00:00.01)
Would a flame graph be of more use, perhaps? That is, if the main GUI is meant to be responsive during a render.
I don’t know much about Linux. 
Please refer to the video below.
@oo_1942, that seems analogous to merely invoking blender in the terminal, since he’s just invoking the absolute path (instead of using env) through the terminal, merely via a shell script. Am I correct, or have I missed something obvious?
Sorry…
I can’t give you a good answer because I don’t know much about Linux.
I understand that what he shows in the video explains how he can check the error output of the blender through the console. 
No worries. Thank you.
No it is not normal.
I use Linux and have not had this problem. Your screenshot says “Blender render (not responding)” that is not normal it seems to be a warning IE something is wrong.
I can add a monkey hit render animation and move the monkey around in 3d view-port and those movements (rotations) get rendered “realtime” without errors. The main GUI is supposed to stay responsive.
and the screenshot is not much info to go from.
We have no idea what sort of size complexity the scene has, are you using the compositor, if it fits in your graphic memory, are you over the texture size limit etc etc
A full-screen screenshot with the memory statistics in the status bar would be good to see how complex the scene is and how much memory it is using.
Does blender save the frames in your output folder? If yes are they blank?
There could be many reasons for this sort of error so it is impossible to guess without a lot more info.
First you should find out if it is that specific file or if it happens with a simple scene.
If you can render a simple default scene with render animation and rotate the cube around while you render and see the results getting rendered out as you do so then that is the normal behavior, and the problem is with your file.
To be able to report a bug you need to be able to reproduce the bad behavior with the most simple scenario.
So you need to start ruling things out, simplifying the scene until it you find what is causing the fault.
Unless you can pinpoint a cause (for example blender hangs when I do this, or add that) you will probably not be able to report a bug.
“Blender hangs” is a consequence of something not a bug itself.
@DNorman, apologies for the wait.
I have posted a demonstration to youtu.be/lUEzdPacpj8:
I manually save them, but they’re not blank:
Unfortunately, my PC is fast enough that such a basic scene wouldn’t take long enough to render for the problem to appear. Consequently, I presume that this is an example of what superuser.com/revisions/839852/1 explains:
So when a program crashes, it has literally given up and terminated execution.
This is different when a program stops responding. Windows programs maintain communication with the OS using a message loop. If the program gets stuck, either waiting on I/O or an infinite loop, it will stop getting messages from the loop, and Windows then tells you the program is not responding. One thing that can cause programs to unexpectedly wait on I/O is when you are low on RAM and the OS has to use the page file to handle memory requests. Another might be if your disk suddenly fails and the programmer never considered the possibility that writes to a file might be interrupted with something like that - or the programmer did something like “if this operation fails, retry forever.”
Ideally, Blender’s GUI and render threads should be separate. Are they?
Well that is a generic description of why programs crash, it does not really help us much for specific cases.
Yes and no the gui is also handled by your graphics card so it does use up some of its memory/threads (not as much as render.)
Your scene does not look too complex 113,000 tris is not too big, you should be able to handle millions (at least 1 or 2). I did a test with an animation with over 1million tris and the gui did not freeze during render (it was laggy though).
The warning Blender Render “not responding” is not a good sign, also it looks like it did not take long for the error to show up.
I would suspect that there is some problem with your grafic card or drivers, it seems that the render did not even get past the inicial stages loading the scene to your card. Eevee depends exclusively on your graphics card.
What are your specs? How much system Ram, which GPU and driver version etc.
I am hoping you will not say you have an AMD card that can be an unsolvable issue.
@DNorman, it’s not a description of why software crashes. I presume you didn’t read all except the first line.
Crashes are caused by an exception handler deferring to the OS’s exception handlers when the internal event loop is unrecoverably halted, whereas a hang occurs when the internal event loop ceases to communicate with the OS.
The latter can merely occur temporarily, hence Blender’s temporary “unresponsive”-ness (as my DE refers to it).
The scene always successfully renders if I leave it:
It merely hangs until it’s completed.
I do: 1 x AMD Radeon RX 5700.
#!/usr/bin/env sh
kinfo
#!/usr/bin/env xdg-open Operating System : Fedora Linux 41 KDE Plasma Version : 6.2.4 KDE Frameworks Version : 6.9.0 Qt Version : 6.8.1 Kernel Version : 6.12.4-200.fc41.x86_64 (64-bit) Graphics Platform : Wayland Processors : 12 × AMD Ryzen 5 7600X 6-Core Processor Memory : 30.4 GiB of RAM Graphics Processor : AMD Radeon RX 5700 Manufacturer : ASRock Product Name : X670E Taichi
Why might that be supposedly unsolveable?
Ok so it does successfully render, the problem is more that you can not do anything while rendering?
I would say that is more expected depending on the scene.
Well AMD have had many problems with drivers, but if the scene does render then it is not all bad.
Yes.
Thanks.
Do you think this would be a reasonable feature request, then? Most professional software deliberately separates the GUI thread from all else to prevent exactly this. I can only presume that Blender hasn’t.
@DNorman, yeah, they do. Especially on Linux.
Then again, I don’t need an out-of-tree kernel module like NVIDIA demands, so it’s not so bad.
It would probably mean setting aside a block of the GPU threads and Vram for GUI which in turn would take them away from the render process. I suspect that some people would not be keen if they are rendering “at the limit” of their hardware possibilities, it could be preferable to leave the GUI unresponsive (“wait I am busy”) than to run out of resources completely.
I think it would be more a “suggestion” than a bug, but I expect it would be complex and there would be pros and cons.
Personally I do not, no. I have no expectations that I can continue to work in the application doing other things, while it is simultaneously rendering.
To a certain extent you already can if the scene is not too complex, (I usually render in cycles though), Eevee is more GPU grabbing. I often fiddle with things while rendering (even with view-port render preview on).
But I do think most people prefer fast rendering (more so with animation) over the ability to carry on working and if the scene needs all the GPU let it be. Also editing while rendering animation affects the subsequent animation frames so not always a good idea.