Crash while updating sun, when rendering animation or baking geonodes (sometimes when rendering single frame or editing too) #105295

New Issue

Mark Cowan · 2024-04-26T12:09:55+02:00

Mark Cowan commented

2024-04-26 12:09:55 +02:00

System Information
Operating system: Linux-6.5.0-28-generic-x86_64-with-glibc2.35 64 Bits, X11 UI
Graphics card: Mesa Intel(R) Graphics (RPL-P) Intel 4.6 (Core Profile) Mesa 23.2.1-1ubuntu3.1~22.04.2

Blender Version
Broken: version: 4.1.1, branch: blender-v4.1-release, commit date: 2024-04-15 15:11, hash: e1743a0317bc
Worked: (none)

Also tested in 4.2 alpha, same result (crashes while updating sun)

Crashes on Windows 11 too (Blender 4.1.x), but I didn't check the log there.

Addon Information
Name: Sun Position (3, 5, 4)
Author: Michael Martin, Damien Picard

Short description of error
When baking geonodes, or rendering animation, blender sometimes crashes.
When editing interactively or rendering a single frame, sometimes blender crashes.

Sun is animated (specifically, the time of day).
Sky texture for world shader (Nishita / Cycles) + Sun light are controlled by the plugin.

Exact steps for others to reproduce the error

Attached:

Blend file by itself
Blend file + some texture assets

Open untitled.blend

My test configurations were:

Blender: 4.1.1 / 4.2-alpha
OS: Ubuntu 22.04 / Windows 11
OS / Drivers up-to-date
Hardware: Newly purchased ASUS ROG M16 GU604 (RTX4090 Laptop GPU)

Open GeoNodes tab.
Select "Leaves" object
Select its geonodes modifier
In GeoNodes editor, find the Bake node and click Bake (as animation, should already be set to this)
This bake will sometimes already trigger a crash within a few minutes
If it doesn't, close and re-open the file then try again.

Render a frame (e.g. open Render tab, F12).
This often triggers a crash.

If you're still uncrashed, render animation. Perhaps drop resolution so you aren't waiting for hours before trying this. This should crash within a few hundred frames in the best case, or in the first frame often.

**System Information** Operating system: Linux-6.5.0-28-generic-x86_64-with-glibc2.35 64 Bits, X11 UI Graphics card: Mesa Intel(R) Graphics (RPL-P) Intel 4.6 (Core Profile) Mesa 23.2.1-1ubuntu3.1~22.04.2 **Blender Version** Broken: version: 4.1.1, branch: blender-v4.1-release, commit date: 2024-04-15 15:11, hash: `e1743a0317bc` Worked: (none) Also tested in 4.2 alpha, same result (crashes while updating sun) Crashes on Windows 11 too (Blender 4.1.x), but I didn't check the log there. **Addon Information** Name: Sun Position (3, 5, 4) Author: Michael Martin, Damien Picard **Short description of error** When baking geonodes, or rendering animation, blender sometimes crashes. When editing interactively or rendering a single frame, sometimes blender crashes. Sun is animated (specifically, the time of day). Sky texture for world shader (Nishita / Cycles) + Sun light are controlled by the plugin. **Exact steps for others to reproduce the error** Attached: - Blend file by itself - Blend file + some texture assets Open untitled.blend My test configurations were: - Blender: 4.1.1 / 4.2-alpha - OS: Ubuntu 22.04 / Windows 11 - OS / Drivers up-to-date - Hardware: Newly purchased ASUS ROG M16 GU604 (RTX4090 Laptop GPU) Open GeoNodes tab. Select "Leaves" object Select its geonodes modifier In GeoNodes editor, find the Bake node and click Bake (as animation, should already be set to this) This bake will sometimes already trigger a crash within a few minutes If it doesn't, close and re-open the file then try again. Render a frame (e.g. open Render tab, F12). This often triggers a crash. If you're still uncrashed, render animation. Perhaps drop resolution so you aren't waiting for hours before trying this. This should crash within a few hundred frames in the best case, or in the first frame often.

system-info.txt

20 KiB

untitled.crash.txt

3.4 KiB

sun-issue.zip

1.3 MiB

untitled.blend

5.6 MiB

Mark Cowan added the

labels 2024-04-26 12:09:55 +02:00

Mark Cowan referenced this issue from blender/blender

2024-04-26 18:41:41 +02:00

GeoNodes bake is lost after closing + reopening (or crash + reopen) #121140

Damien Picard self-assigned this 2024-04-26 20:38:27 +02:00

Damien Picard commented

2024-04-26 20:59:43 +02:00

Hi, thanks for the report. I can’t reproduce the crash with 4.1.0, branch: blender-v4.1-release, commit date: 2024-03-25 20:42, hash: 40a5e739e270.

Just to be sure, have you tried disabling the Sun Position add-on before baking and rendering? It’s quite possible the add-on is causing the crash, but I’d like to make sure if possible.

Hi, thanks for the report. I can’t reproduce the crash with 4.1.0, branch: blender-v4.1-release, commit date: 2024-03-25 20:42, hash: `40a5e739e270`. Just to be sure, have you tried disabling the Sun Position add-on before baking and rendering? It’s quite possible the add-on is causing the crash, but I’d like to make sure if possible.

Damien Picard added

Status

Needs Information from User

and removed

Status

Needs Triage

labels 2024-04-26 20:59:53 +02:00

Mark Cowan commented

2024-04-26 22:54:36 +02:00

Running here with: # Blender 4.1.1, Commit date: 2024-04-15 15:11, Hash e1743a0317bc, on Ubuntu 22.04.4 LTS

I assumed the issue was with the plugin due to the python trace at the end of the crash log file.

I tested now with the plugin disabled and the Bake completed 4 times.
Rendering a single frame after each bake resulted in one crash, one freeze, and two successful renders.

So perhaps the render crash and the bake crash have two different causes.

I re-enabled the Sun plugin, then ran four times: three out of four crashed during bake (one at less than 200 frames in).

Attached logs:

crash during render, with sun plugin disabled [in case the comparison is useful at all]
crash during bake, with sun plugin enabled

Running here with: `# Blender 4.1.1, Commit date: 2024-04-15 15:11, Hash e1743a0317bc`, on `Ubuntu 22.04.4 LTS` I assumed the issue was with the plugin due to the python trace at the end of the crash log file. I tested now with the plugin disabled and the Bake completed 4 times. Rendering a single frame after each bake resulted in one crash, one freeze, and two successful renders. So perhaps the render crash and the bake crash have two different causes. I re-enabled the Sun plugin, then ran four times: three out of four crashed during bake (one at less than 200 frames in). Attached logs: - crash during render, with sun plugin disabled [in case the comparison is useful at all] - crash during bake, with sun plugin enabled

crash-during-render-no-sun-plugin.log

1.3 KiB

crash-during-bake-with-sun-plugin.log

2.0 KiB

Mark Cowan commented

2024-04-26 23:02:51 +02:00

This more minimal example also triggers it for me on:
# Blender 4.1.1, Commit date: 2024-04-15 15:11, Hash e1743a0317bc

Steps to repro:

Open blend file
Set "Viewport Shading" to "Rendered" (e.g. keys "Z", "8" in 3d view) (not always needed I think, but seems to trigger the bug more often)
Bake the bake node
"Bin icon" delete the bake (if you didn't crash during step 3)
Goto step 3

I just ran 5 times, and got:

2 crashes
1 freeze
2 completed successfully

This more minimal example also triggers it for me on: `# Blender 4.1.1, Commit date: 2024-04-15 15:11, Hash e1743a0317bc` Steps to repro: 1. Open blend file 2. Set "Viewport Shading" to "Rendered" (e.g. keys "Z", "8" in 3d view) (not always needed I think, but seems to trigger the bug more often) 3. Bake the bake node 4. "Bin icon" delete the bake (if you didn't crash during step 3) 5. Goto step 3 I just ran 5 times, and got: - 2 crashes - 1 freeze - 2 completed successfully

bake-crash-with-sun.blend

944 KiB

Damien Picard added

Status

Confirmed

and removed

Status

Needs Information from User

labels 2024-04-26 23:18:11 +02:00

Damien Picard commented

2024-04-27 00:19:38 +02:00

Thanks, I can reproduce the crash now!

Mark Cowan commented

2024-04-27 09:50:00 +02:00

Sorry for the delay in getting the minimal example over - blender is just a hobby for me and my work has been crazy lately.

In ~1 week time I should be able to help with debugging / testing if needed.

Sorry for the delay in getting the minimal example over - blender is just a hobby for me and my work has been crazy lately. In ~1 week time I should be able to help with debugging / testing if needed.

Damien Picard commented

2024-04-27 11:15:05 +02:00

Hey, no problem, this isn’t my day job either!

I tried a few things and currently I don’t know why the crash happens precisely. Best hunch is that the system used to update the Sun position at each frame update is known to be somewhat unstable. Not sure how I can work around that.

Maybe adding an operator to bake the animation could help, but it’s annoying.

Hey, no problem, this isn’t my day job either! I tried a few things and currently I don’t know why the crash happens precisely. Best hunch is that the system used to update the Sun position at each frame update is [known to be somewhat unstable](https://docs.blender.org/api/master/bpy.app.handlers.html#note-on-altering-data). Not sure how I can work around that. Maybe adding an operator to bake the animation could help, but it’s annoying.

Mark Cowan commented

2024-04-27 20:22:54 +02:00

Ok, so this is a "design issue" in Blender then. For rendering it can be fixed with "lock interface", but for other stuff (e.g. baking) there isn't a UI option for that.

I wonder if one can lock/unlock the interface in code somehow, like taking a mutex...
If not, I'm curious if this is something blender main-repo people would be interested in.

Ok, so this is a "design issue" in Blender then. For rendering it can be fixed with "lock interface", but for other stuff (e.g. baking) there isn't a UI option for that. I wonder if one can lock/unlock the interface in code somehow, like taking a mutex... If not, I'm curious if this is something blender main-repo people would be interested in.

Mark Cowan commented

2024-04-27 23:18:56 +02:00

I'm trying a headless render now via a shell script (blender --background ...).

It's still crashing, but due to a different issue (likely the issue for my other ticket in blender main repo, unrelated to this sun plugin).
Interestingly, it crashes quickly with OPTIX, but when I switch to CUDA then it allocates about 70GB of RAM and then crashes with OOM.

Thanks for the tip about the concurrency issue with the view state! Headless rendering should provide a workaround for me hopefully once I find a workaround for this other issue.

I'm trying a headless render now via a shell script (`blender --background ...`). It's still crashing, but due to a different issue (likely the issue for my other ticket in blender main repo, unrelated to this sun plugin). Interestingly, it crashes quickly with OPTIX, but when I switch to CUDA then it allocates about 70GB of RAM and then crashes with OOM. Thanks for the tip about the concurrency issue with the view state! Headless rendering should provide a workaround for me hopefully once I find a workaround for this other issue.

Damien Picard commented

2024-04-28 00:26:25 +02:00

I wonder if one can lock/unlock the interface in code somehow, like taking a mutex...
If not, I'm curious if this is something blender main-repo people would be interested in.

I don’t know of any way to do that currently, but maybe it would make sense to lock the interface during bake, yes. In any case if we can make a repro case which doesn’t involve Sun Position, it could be good to take this to the Blender developers.

Interestingly, it crashes quickly with OPTIX, but when I switch to CUDA then it allocates about 70GB of RAM and then crashes with OOM.

Not sure it’s the same thing, but I noticed a memory leak when rendering your file with EEVEE, 1 sample, 5% resolution and FFMPEG output for maximum speed. The crash only happens when the Sky Texture is plugged in, so I think a new texture for the sky is created on each frame, but not deallocated till after the whole sequence is rendered. That may be yet another bug.

Thanks for the tip about the concurrency issue with the view state!

FWIW, as another workaround you can create a workplace without any viewport, and then I can’t reproduce the crash any more.

> I wonder if one can lock/unlock the interface in code somehow, like taking a mutex... > If not, I'm curious if this is something blender main-repo people would be interested in. I don’t know of any way to do that currently, but maybe it would make sense to lock the interface during bake, yes. In any case if we can make a repro case which doesn’t involve Sun Position, it could be good to take this to the Blender developers. > Interestingly, it crashes quickly with OPTIX, but when I switch to CUDA then it allocates about 70GB of RAM and then crashes with OOM. Not sure it’s the same thing, but I noticed a memory leak when rendering your file with EEVEE, 1 sample, 5% resolution and FFMPEG output for maximum speed. The crash only happens when the Sky Texture is plugged in, so I think a new texture for the sky is created on each frame, but not deallocated till after the whole sequence is rendered. That may be yet another bug. > Thanks for the tip about the concurrency issue with the view state! FWIW, as another workaround you can create a workplace without any viewport, and then I can’t reproduce the crash any more.

👍 1

Mark Cowan commented

2024-05-15 22:00:33 +02:00

Thanks for the tips / info!

Sign in to join this conversation.