Memory leak cause my computer to freeze when rendering anumation #100061

New Issue

Nisim Joseph · 2022-07-29T14:26:00+02:00

Nisim Joseph commented

2022-07-29 14:26:00 +02:00

System Information
Operating system: macOS-12.5-x86_64-i386-64bit 64 Bits
Graphics card: AMD Radeon Pro 5300M OpenGL Engine ATI Technologies Inc. 4.1 ATI-4.8.101

Blender Version
Broken: version: 3.2.2 Release Candidate, branch: master, commit date: 2022-07-28 14:19, hash: c857405c0d
Worked: worked on blender ~3.0 but it broke on 3.1+.

Short description of error
when rendering full animations the memory of Blender is raised to 20GB, although the animation is a very simple content. after 300 frames of rendering in the low quality, we are still stuck and the rendering output is blank frames.
The entire compute get stuck and Swap Files rose to 10GB. I have 32 GB of memory.

Exact steps for others to reproduce the error
I will attach the file I render to this ticket.

Update August 19, 2022
The memory issue was fixed in the current 3.2.2 version and in 3.3 version.
but there is an issue with black images rendered from frame 700 in the animation ( in the same file attached).
in the previous versions the black frames occurred from the frame 300 because of memory leak issue.

**System Information** Operating system: macOS-12.5-x86_64-i386-64bit 64 Bits Graphics card: AMD Radeon Pro 5300M OpenGL Engine ATI Technologies Inc. 4.1 ATI-4.8.101 **Blender Version** Broken: version: 3.2.2 Release Candidate, branch: master, commit date: 2022-07-28 14:19, hash: `c857405c0d` Worked: worked on blender ~3.0 but it broke on 3.1+. **Short description of error** when rendering full animations the memory of Blender is raised to 20GB, although the animation is a very simple content. after 300 frames of rendering in the low quality, we are still stuck and the rendering output is blank frames. The entire compute get stuck and Swap Files rose to 10GB. I have 32 GB of memory. **Exact steps for others to reproduce the error** I will attach the file I render to this ticket. **Update August 19, 2022** The memory issue was fixed in the current 3.2.2 version and in 3.3 version. but there is an issue with black images rendered from frame 700 in the animation ( in the same file attached). in the previous versions the black frames occurred from the frame 300 because of memory leak issue.

Nisim Joseph commented

2022-07-29 14:26:00 +02:00

Added subscriber: @Nisim

Nisim Joseph commented

2022-07-29 14:27:48 +02:00

how do I attach blender file to the ticket?

Nisim Joseph commented

2022-07-29 19:07:20 +02:00

blender file reproduce the issue
https://www.dropbox.com/s/cma4svpqeqcocqb/balloons%20Try3.blend.zip?dl=0

blender file reproduce the issue https://www.dropbox.com/s/cma4svpqeqcocqb/balloons%20Try3.blend.zip?dl=0

Erick Tukuniata commented

2022-07-31 09:55:17 +02:00

Added subscriber: @ErickNyanduKabongo

Erick Tukuniata commented

2022-07-31 09:56:54 +02:00

It seems like I'm having the same problem in Windows with my AMD

Omar Emara commented

2022-08-01 13:40:25 +02:00

Added subscriber: @OmarEmaraDev

Omar Emara commented

2022-08-01 13:40:25 +02:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Omar Emara commented

2022-08-01 13:40:25 +02:00

From what I understand:

You are rendering on the GPU using Metal.
VRAM usage consistently increase each frame until it reaches its maximum and then it starts offloading to RAM.
RAM is filled up until it reaches 20 GB and then it starts swapping.

Is that correct?

What does this mean exactly?

we are still stuck and the rendering output is blank frames.

Is rendering not working at all and just outputs blank frames?

From what I understand: - You are rendering on the GPU using Metal. - VRAM usage consistently increase each frame until it reaches its maximum and then it starts offloading to RAM. - RAM is filled up until it reaches 20 GB and then it starts swapping. Is that correct? What does this mean exactly? > we are still stuck and the rendering output is blank frames. Is rendering not working at all and just outputs blank frames?

Erick Tukuniata commented

2022-08-09 14:58:52 +02:00

To Clear my name, the problem that I was having seems to be solved, but rendering my CPU still getting easily up to 97%-98%, that is another problem that I have to track somehow.

Nisim Joseph commented

2022-08-09 18:46:46 +02:00

I checked on Blender 3.3 Beta and the issue still remain. but I get it after 700 small frames and not 250 frames like before.
the memory looks better, Blender kept on 1-2GB, but the rendering from the frame 700 (using the example .blend file I attached) rendering Empty (blank) image files.
it occurred also in 3.2 but without the memory claiming to 15-20GB.

I checked on Blender 3.3 Beta and the issue still remain. but I get it after 700 small frames and not 250 frames like before. the memory looks better, Blender kept on 1-2GB, but the rendering from the frame 700 (using the example .blend file I attached) rendering Empty (blank) image files. it occurred also in 3.2 but **without** the memory claiming to 15-20GB.

Erick Tukuniata commented

2022-08-09 21:52:44 +02:00

Someone has to check out this one, I tried to render @Nisim shared blend file, wow!, rendering this light file my CPU is hitting 100%, what is going on?

Omar Emara commented

2022-08-17 12:12:36 +02:00

Changed status from 'Needs User Info' to: 'Needs Triage'

Omar Emara commented

2022-08-19 09:42:49 +02:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Omar Emara commented

2022-08-19 09:42:49 +02:00

It seems for 3.3, your report is no longer about excessive RAM usage, but blank frames, can you update your report accordingly?
Does it always start producing blank frames at exactly 700 or is it random but happens at around frame 700?
Does it seems to render them correctly but saves blank frames or does it render blank directly?
I can't reproduce the issue myself on the CPU.

It seems for 3.3, your report is no longer about excessive RAM usage, but blank frames, can you update your report accordingly? Does it always start producing blank frames at exactly 700 or is it random but happens at around frame 700? Does it seems to render them correctly but saves blank frames or does it render blank directly? I can't reproduce the issue myself on the CPU.

Nisim Joseph commented

2022-08-19 10:33:56 +02:00

I used Mac GPU and CPU. when the RAM issue existed it occurred on about frame #300, but now it starts on frame 700 but it can vary to plus/minus frames.
it occurred all the time
try to run with GPU with latest Mac OS update

I used Mac GPU and CPU. when the RAM issue existed it occurred on about frame #300, but now it starts on frame 700 but it can vary to plus/minus frames. it occurred all the time try to run with GPU with latest Mac OS update

Omar Emara commented

2022-08-19 10:58:48 +02:00

Can you update the report description to explain this? As the report still mentions the memory issue specify.

Also:

Does it seems to render them correctly but saves blank frames or does it render blank directly?

Can you update the report description to explain this? As the report still mentions the memory issue specify. Also: > Does it seems to render them correctly but saves blank frames or does it render blank directly?

Nisim Joseph commented

2022-08-19 12:41:18 +02:00

I added an update to the description.

Omar Emara commented

2022-08-19 12:45:07 +02:00

Changed status from 'Needs User Info' to: 'Needs Triage'

Nisim Joseph commented

2022-08-25 21:52:02 +02:00

I checked with the current 3.3 Beta and I see the rendering issue still present. see attached file. it started at frame #787. and it occurs there constantly. you can see frame #786 looks ok but all the ones after that looks the same as #787.

I checked with the current 3.3 Beta and I see the rendering issue still present. see attached file. it started at frame #787. and it occurs there constantly. you can see frame #786 looks ok but all the ones after that looks the same as #787. ![0787.png](https://archive.blender.org/developer/F13417224/0787.png) ![0786.png](https://archive.blender.org/developer/F13417223/0786.png)

Alexander Hartmann commented

2022-11-03 01:12:00 +01:00

Added subscriber: @Alexander-Hartmann

Alexander Hartmann commented

2022-11-05 15:58:19 +01:00

Is it still a macOS specific issue?

In #100061#1397453, @ErickNyanduKabongo wrote:
It seems like I'm having the same problem in Windows with my AMD

Memory consumption was a maximum of 900 MB RAM.
After frame 751 I had to terminate 'Blender'. The UI is frozen. The CPU usage was very high. After 2 to 3 minutes, the CPU usage was at 1-3% and the UI was still frozen. I'll try to reproduce it later in debug mode.

0751.png

version: 3.4.0 Beta, branch: master, commit date: 2022-11-05 08:57, hash: 037b771e1a
renderer: 'Apple M1'
version: '4.1 Metal - 83'
device type: 'APPLE'
backend type: 'OPENGL'

system-info.txt

**Is it still a macOS specific issue?** > In #100061#1397453, @ErickNyanduKabongo wrote: > It seems like I'm having the same problem in Windows with my AMD Memory consumption was a maximum of 900 MB RAM. After frame 751 I had to terminate 'Blender'. The UI is frozen. The CPU usage was very high. After 2 to 3 minutes, the CPU usage was at 1-3% and the UI was still frozen. I'll try to reproduce it later in debug mode. 0751.png ![0751.png](https://archive.blender.org/developer/F13859101/0751.png) > version: 3.4.0 Beta, branch: master, commit date: 2022-11-05 08:57, hash: 037b771e1af5 > renderer: 'Apple M1' > version: '4.1 Metal - 83' > device type: 'APPLE' > backend type: 'OPENGL' [system-info.txt](https://archive.blender.org/developer/F13859090/system-info.txt)

Alexander Hartmann commented

2022-11-06 22:11:16 +01:00

Added subscribers: @mont29, @ideasman42, @brecht

Alexander Hartmann commented

2022-11-06 22:11:16 +01:00

In debug mode (debug build) I could not reproduce this error. Debug build takes up to 20x more time to render a frame.
I checked further with "release build" and ##printf## outputs.
It looks like a "thread lock" problem, but diagnostic function ##PyGILState_GetThisThreadState## returns "NULL" value and function ##PyGILState_Check## returns "0".
After the Python function ##PyGILState_Ensure## it doesn't go any further. On previous two calls I also see ##bpy_context_clear -> PyGILState_Release##

@ideasman42, @mont29, @brecht
(NOTE) Is it an "RNA" problem? Should I further investigate the issue and optimize my output? Or can you already do something with this description?

https://developer.blender.org/diffusion/B/browse/blender-v3.4-release/source/blender/python/intern/bpy_rna.c$8494

version: 3.4.0 Beta, branch: master, commit date: 2022-11-05 08:57, hash: 037b771e1a

lines =10, name=last 3 calls: bpy_class_call
py_class: 'CyclesRender', PyGILState_Check: 0 
(CyclesRender): thread_state = NULL 
(CyclesRender) bpy_context_set_DEBUG
(CyclesRender) BEGIN bpy_context_set_DEBUG, py_call_level: 2 
(CyclesRender) *gilstate = PyGILState_Ensure(); 
(CyclesRender) END bpy_context_set_DEBUG 
....
....
py_class: 'CyclesRender', PyGILState_Check: 0 
(CyclesRender): thread_state -> thread_id: 8172119296, id: 1, gilstate_counter: 1 
(CyclesRender) bpy_context_set_DEBUG
(CyclesRender) BEGIN bpy_context_set_DEBUG, py_call_level: 2 
(CyclesRender) *gilstate = PyGILState_Ensure(); 
(CyclesRender) END bpy_context_set_DEBUG 
......
(CyclesRender) bpy_context_clear_DEBUG
(CyclesRender) BEGIN bpy_context_clear_DEBUG, py_call_level: 1 
(CyclesRender) PyGILState_Release(*gilstate); 
(CyclesRender) END bpy_context_clear_DEBUG 
END (CyclesRender) bpy_class_call: 0 
....
....
(CyclesRender) bpy_context_clear_DEBUG
(CyclesRender) BEGIN bpy_context_clear_DEBUG, py_call_level: 1 
(CyclesRender) PyGILState_Release(*gilstate); 
(CyclesRender) END bpy_context_clear_DEBUG 
END (CyclesRender) bpy_class_call: 0

py_class: 'CyclesRender', PyGILState_Check: 0 
(CyclesRender): thread_state = NULL 
(CyclesRender) bpy_context_set_DEBUG
(CyclesRender) BEGIN bpy_context_set_DEBUG, py_call_level: 2 
(CyclesRender) *gilstate = PyGILState_Ensure(); 
(CyclesRender) END bpy_context_set_DEBUG 
.....
(CyclesRender) bpy_context_clear_DEBUG
(CyclesRender) BEGIN bpy_context_clear_DEBUG, py_call_level: 1 
(CyclesRender) PyGILState_Release(*gilstate); 
(CyclesRender) END bpy_context_clear_DEBUG 
END (CyclesRender) bpy_class_call: 0

py_class: 'CyclesRender', PyGILState_Check: 0 
(CyclesRender): thread_state = NULL 
(CyclesRender) C = BPY_context_get(); 
(CyclesRender) bpy_context_set_DEBUG(C, &gilstate); 
(CyclesRender) BEGIN bpy_context_set_DEBUG, py_call_level: 2 
(CyclesRender) *gilstate = PyGILState_Ensure();

============ ??? [THREAD LOCK] ??? ==============

In debug mode (debug build) I could not reproduce this error. Debug build takes up to 20x more time to render a frame. I checked further with "release build" and ##printf## outputs. It looks like a "thread lock" problem, but diagnostic function ##PyGILState_GetThisThreadState## returns "NULL" value and function ##PyGILState_Check## returns "0". After the Python function ##PyGILState_Ensure## it doesn't go any further. On previous two calls I also see ##bpy_context_clear -> PyGILState_Release## @ideasman42, @mont29, @brecht (NOTE) Is it an "RNA" problem? Should I further investigate the issue and optimize my output? Or can you already do something with this description? https://developer.blender.org/diffusion/B/browse/blender-v3.4-release/source/blender/python/intern/bpy_rna.c$8494 > version: 3.4.0 Beta, branch: master, commit date: 2022-11-05 08:57, hash: 037b771e1af5 ``` lines =10, name=last 3 calls: bpy_class_call py_class: 'CyclesRender', PyGILState_Check: 0 (CyclesRender): thread_state = NULL (CyclesRender) bpy_context_set_DEBUG (CyclesRender) BEGIN bpy_context_set_DEBUG, py_call_level: 2 (CyclesRender) *gilstate = PyGILState_Ensure(); (CyclesRender) END bpy_context_set_DEBUG .... .... py_class: 'CyclesRender', PyGILState_Check: 0 (CyclesRender): thread_state -> thread_id: 8172119296, id: 1, gilstate_counter: 1 (CyclesRender) bpy_context_set_DEBUG (CyclesRender) BEGIN bpy_context_set_DEBUG, py_call_level: 2 (CyclesRender) *gilstate = PyGILState_Ensure(); (CyclesRender) END bpy_context_set_DEBUG ...... (CyclesRender) bpy_context_clear_DEBUG (CyclesRender) BEGIN bpy_context_clear_DEBUG, py_call_level: 1 (CyclesRender) PyGILState_Release(*gilstate); (CyclesRender) END bpy_context_clear_DEBUG END (CyclesRender) bpy_class_call: 0 .... .... (CyclesRender) bpy_context_clear_DEBUG (CyclesRender) BEGIN bpy_context_clear_DEBUG, py_call_level: 1 (CyclesRender) PyGILState_Release(*gilstate); (CyclesRender) END bpy_context_clear_DEBUG END (CyclesRender) bpy_class_call: 0 ``` ------------------------------------------------------------------------------ ``` py_class: 'CyclesRender', PyGILState_Check: 0 (CyclesRender): thread_state = NULL (CyclesRender) bpy_context_set_DEBUG (CyclesRender) BEGIN bpy_context_set_DEBUG, py_call_level: 2 (CyclesRender) *gilstate = PyGILState_Ensure(); (CyclesRender) END bpy_context_set_DEBUG ..... (CyclesRender) bpy_context_clear_DEBUG (CyclesRender) BEGIN bpy_context_clear_DEBUG, py_call_level: 1 (CyclesRender) PyGILState_Release(*gilstate); (CyclesRender) END bpy_context_clear_DEBUG END (CyclesRender) bpy_class_call: 0 ``` ------------------------------------------------------------------------------ ``` py_class: 'CyclesRender', PyGILState_Check: 0 (CyclesRender): thread_state = NULL (CyclesRender) C = BPY_context_get(); (CyclesRender) bpy_context_set_DEBUG(C, &gilstate); (CyclesRender) BEGIN bpy_context_set_DEBUG, py_call_level: 2 (CyclesRender) *gilstate = PyGILState_Ensure(); ``` ``` ============ ??? [THREAD LOCK] ??? ==============

Iliya Katushenock removed the

Status

Needs Triage

label 2023-08-24 17:31:46 +02:00

Brecht Van Lommel added

Module

Render & Cycles

and removed

Module

Platforms, Builds & Tests

labels 2024-02-07 17:53:29 +01:00

Sign in to join this conversation.