Intermittent crash EXCEPTION_ACCESS_VIOLATION on frame_change_post handler modifying object scales only during render/bake. #117386

New Issue

Melissa0x1f992 · 2024-01-21T18:44:28+01:00

Melissa0x1f992 commented

2024-01-21 18:44:28 +01:00

System Information
Operating system: Windows-10-10.0.22621-SP0 64 Bits
Graphics card: AMD Radeon RX 6900 XT ATI Technologies Inc. 4.6.0 Core Profile Context 23.10.24.230718

Blender Version
Broken: version: 4.1.0 Alpha, branch: main, commit date: 2024-01-20 18:17, hash: af5731ce03a2
Worked: N/A. Bug found in 4.0.2, and persists to latest build.

Short description of error
Error found in a more complex scene while rendering after having played through the whole viewport in cycles and eevee many times already. A few dozen frames rendered successfully, before an intermittent crash. I tried baking a simulation to create a more stable scene, and the bake itself consistently crashed blender after a few dozen frames.

I've attached a simplified setup to isolate the cause of the crash. Note that the default cube has an untouched Geometry Nodes modifier. On my machine, this consistently only bakes a few hundred frames before crashing. Can even be less than 100 frames.

Exact steps for others to reproduce the error

In the attached .blend file, run the crash_sometimes.py script to assign the frame_change_post handler.
Select the Cube, and do Physics > Simulation Nodes > Calculate to Frame (the timeline cursor should already be at the last frame)

On my machine, this will crash Blender on a random frame while modifying a random Empty. I've never seen it make it to 500 frames.

Edit:
Error still reproduces even when using Lock Interface as suggested here https://docs.blender.org/api/master/bpy.app.handlers.html#note-on-altering-data

**System Information** Operating system: Windows-10-10.0.22621-SP0 64 Bits Graphics card: AMD Radeon RX 6900 XT ATI Technologies Inc. 4.6.0 Core Profile Context 23.10.24.230718 **Blender Version** Broken: version: 4.1.0 Alpha, branch: main, commit date: 2024-01-20 18:17, hash: `af5731ce03a2` Worked: N/A. Bug found in 4.0.2, and persists to latest build. **Short description of error** Error found in a more complex scene while rendering after having played through the whole viewport in cycles and eevee many times already. A few dozen frames rendered successfully, before an intermittent crash. I tried baking a simulation to create a more stable scene, and the bake itself consistently crashed blender after a few dozen frames. I've attached a simplified setup to isolate the cause of the crash. Note that the default cube has an untouched Geometry Nodes modifier. On my machine, this consistently only bakes a few hundred frames before crashing. Can even be less than 100 frames. **Exact steps for others to reproduce the error** 1. In the attached .blend file, run the crash_sometimes.py script to assign the frame_change_post handler. 2. Select the Cube, and do Physics > Simulation Nodes > Calculate to Frame (the timeline cursor should already be at the last frame) On my machine, this will crash Blender on a random frame while modifying a random Empty. I've never seen it make it to 500 frames. Edit: Error still reproduces even when using Lock Interface as suggested here https://docs.blender.org/api/master/bpy.app.handlers.html#note-on-altering-data

error.blend

1.0 MiB

error.crash.txt

53 KiB

Melissa0x1f992 added the

labels 2024-01-21 18:44:29 +01:00

Pratik Borhade commented

2024-01-22 05:11:00 +01:00

Hi, thanks for the report. Though this seems an expected behavior or a known issue, see: https://docs.blender.org/api/master/bpy.app.handlers.html#note-on-altering-data

Pratik Borhade added

Module

Python API

Status

Needs Info from Developers

and removed

Status

Needs Triage

labels 2024-01-22 05:12:19 +01:00

Melissa0x1f992 commented

2024-01-22 13:29:36 +01:00

That page suggests to Lock Interface before running such a script, but that option hasn't prevented the crash for me. Updating the issue with this detail.

Pratik Borhade commented

2024-01-23 04:25:51 +01:00

Lock interface is useful when rendering the scene, not in this case i.e. executing python script

`Lock interface` is useful when rendering the scene, not in this case i.e. executing python script

Marek Smoliński commented

2024-01-29 16:58:33 +01:00

Hi, thanks for the report. Though this seems an expected behavior or a known issue, see: https://docs.blender.org/api/master/bpy.app.handlers.html#note-on-altering-data

So the linked note applies to this case?

Lock interface is useful when rendering the scene, not in this case i.e. executing python script

So the linked note doesn't apply to this case?

What am I missing here that your two posts seem contradictory to me? What should the OP do to avoid the crash?

> Hi, thanks for the report. Though this seems an expected behavior or a known issue, see: https://docs.blender.org/api/master/bpy.app.handlers.html#note-on-altering-data So the linked note applies to this case? > `Lock interface` is useful when rendering the scene, not in this case i.e. executing python script So the linked note doesn't apply to this case? What am I missing here that your two posts seem contradictory to me? What should the OP do to avoid the crash?

Pratik Borhade commented

2024-01-30 04:41:05 +01:00

Well the crash seems to happen as handlers and viewport updates are done on different threads (as said in the api manual)
@lichtwerk can you check as well?

Well the crash seems to happen as handlers and viewport updates are done on different threads (as said in the api manual) @lichtwerk can you check as well?

Philipp Oeser referenced this issue

2024-04-19 10:57:23 +02:00

blender crash randomly on animation with link/unlink script #120795

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Intermittent crash EXCEPTION_ACCESS_VIOLATION on frame_change_post handler modifying object scales only during render/bake. #117386