Page MenuHome

Render crash when using Python API to modify object data in frame_change_pre handler
Closed, ResolvedPublic

Tokens
"Yellow Medal" token, awarded by fin.eskimo."Love" token, awarded by Graphonix."Like" token, awarded by lucky3."The World Burns" token, awarded by LapisSea."Mountain of Wealth" token, awarded by finnb."Burninate" token, awarded by hsab."The World Burns" token, awarded by juang3d.
Authored By
Ryan G (rlguy), Jan 3 2019

Description

System Information
Operating system: Windows 10 Home
Graphics card: GTX 1070 8GB

Blender Version
Broken: 2.80, .4dd0a90f4213, 2019-01-01
Worked: 2.79b release

Short description of error

Blender crashes while rendering and animation when object data is modified inside the frame_change_pre handler using the Python API. The crashes only seem to occur while rendering and not during playback. The frequency of crashes seems to be related to the frequency at which the object data is modified.

This is part of an addon that reads and renders geometry data from a sequence of files. The addon does this by creating a Blender object, and on each frame swap out the object's mesh data with new geometry and then delete the old geometry. I have a created a simplified script that reproduces this crash within the first few frames of rendering:

import bpy


def frame_change_pre(scene):
    # The addon would load geometry from a file, but for a simplified test an icosphere works
    vertices = [
        (0.0000, 0.0000, -1.0000), (0.7236, -0.5257, -0.4472), (-0.2764, -0.8506, -0.4472), (-0.8944, 0.0000, -0.4472),
        (-0.2764, 0.8506, -0.4472), (0.7236, 0.5257, -0.4472), (0.2764, -0.8506, 0.4472), (-0.7236, -0.5257, 0.4472),
        (-0.7236, 0.5257, 0.4472), (0.2764, 0.8506, 0.4472), (0.8944, 0.0000, 0.4472), (0.0000, 0.0000, 1.0000)
    ]

    triangles = [
        (0, 1, 2), (1, 0, 5), (0, 2, 3), (0, 3, 4), (0, 4, 5), (1, 5, 10), (2, 1, 6), (3, 2, 7), (4, 3, 8), (5, 4, 9),
        (1, 10, 6), (2, 6, 7), (3, 7, 8), (4, 8, 9), (5, 9, 10), (6, 10, 11), (7, 6, 11), (8, 7, 11), (9, 8, 11), (10, 9, 11)
    ]
    
    # Create a new mesh with geometry
    new_mesh_data = bpy.data.meshes.new("mesh_data" + str(scene.frame_current))
    new_mesh_data.from_pydata(vertices, [], triangles)
    
    # Swap the new mesh data and delete the old mesh data
    mesh_cache = bpy.data.objects.get("mesh_cache")
    old_mesh_data = mesh_cache.data
    mesh_cache.data = new_mesh_data
    bpy.data.meshes.remove(old_mesh_data)
    
    # This is what causes the crash: the more frequently the mesh cache data is accessed, the more frequent the crash occurs.
    # For a simplified test, we will repeatedly set smooth shading on the mesh data polygons. This also happens if setting the 
    # object location/scale/matrix_world, mesh data materials, and other data.
    for i in range(1000):
        for p in mesh_cache.data.polygons:
            p.use_smooth = True
    

# Create a cache object to store the current frame mesh    
mesh_cache_data = bpy.data.meshes.new("mesh_cache_data")
mesh_cache_data.from_pydata([], [], [])
mesh_cache_object = bpy.data.objects.new("mesh_cache", mesh_cache_data)
bpy.context.scene.collection.objects.link(mesh_cache_object)

bpy.app.handlers.frame_change_pre.append(frame_change_pre)

This is the error Blender reports (EXCEPTION_ACCESS_VIOLATION):

Error   : EXCEPTION_ACCESS_VIOLATION
Address : 0x00007FF6F95E6650
Module  : C:\\Users\\ryanl\\Downloads\\blender-2.80.0-git.4dd0a90f4213-windows64\\blender.exe

Exact steps for others to reproduce the error

Attached is a .blend file including the script that reproduces this issue.

  1. Open the .blend file
  2. Press 'Run Script'
  3. Begin rendering the animation (Blender > Render > Render Animation)

Details

Type
Bug

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Brecht Van Lommel (brecht) removed Campbell Barton (campbellbarton) as the assignee of this task.
Brecht Van Lommel (brecht) raised the priority of this task from Confirmed, Medium to Confirmed, High.

Changing priority since variations of this crash have been reported a few times, and commonly used add-ons like Animation Nodes and FLIP fluids suffer from it.

This may be more a dependency graph issue than a Python API one.

In general it would be good to clarify which kind of data scripts are allowed or recommended to edit in the various handlers, it's not so clear anymore with multiple depsgraphs.

Just stumbled upon this bug, what a big bug!

I'm being completely unable to render one project right now because of this, I hope it gets fixed soon.

Cheers!

Developer note: this issue is caused by a threading conflict between viewport which is catching with its dependency graph in the main thread with the render thread which is modifying main database while it is used by viewport.

Not sure how/whether this worked in 2.7x yet.

These crashes existed in 2.79 two when certain things were done. Usually one was able to fix it by rendering from the terminal or locking the UI during rendering. I think these workarounds did not work anymore in Blender 2.8 (haven't tried for quite some time thought).

I was testing the recent fix for T60136 and noticed that this issue will cause a crash when baking a rigid body cache. Here is a modified version of the .blend file in the original post to reproduce this issue:

To Reproduce:

  1. Open the .blend file
  2. Press 'Run Script'
  3. Bake the rigid body world cache

Sometimes the cache bakes successfully without a crash. Repeating step 3 by deleting the cache results in a crash within a few attempts for me.

Error Output:

Error   : EXCEPTION_ACCESS_VIOLATION
Address : 0x00007FF760C36840
Module  : C:\Users\ryanl\Downloads\blender-2.80.0-git.5e626e766459-windows64\blender.exe

What is the status of this issue? This bug makes using FLIP Fluid plugin impossible because Blender 2.80 Rc 1 crashes during rendering (sometimes as soon as I press "render" (ctrl+F12) ) if FLIP Fluids' objects are present in the scene regardless if I render PNG pictures or a movie.

Status is: Open, Confirmed, High

This issue is rooting a deep design issues, which were also quite bad in Blender 2.79 but somehow crash was managed to not happen so often.

Possible workaround is to render with Lock Interface option enabled.

Lock Interface did not solve the issue, when I experienced the problem I tried it, without luck, I cannot test it right away, I'm on a hard and tight deadline, but I remember trying everything, even this, and it didn't work

From FLIP Fluids user reports regarding this render crash issue in Blender 2.80, it seems that the Lock Interface workaround works for roughly half of the users. I have tested systems where locking the interface helps reduce render crashes and some systems where this does not work. In my experience, the render crash frequency increases as the amount of mesh geometry increases.

Render crashes in Blender 2.79 are much less frequent and a workaround of setting the Render Display to Fullscreens seems to work for all FLIP Fluids users.

Piotr (Lewiatan) added a comment.EditedJul 16 2019, 10:34 PM

Status is: Open, Confirmed, High
This issue is rooting a deep design issues, which were also quite bad in Blender 2.79 but somehow crash was managed to not happen so often.
Possible workaround is to render with Lock Interface option enabled.

Do you plan to fix this bug soon? It sounds like it will take months to fix it

Piotr (Lewiatan) added a comment.EditedJul 16 2019, 10:37 PM

From FLIP Fluids user reports regarding this render crash issue in Blender 2.80, it seems that the Lock Interface workaround works for roughly half of the users. I have tested systems where locking the interface helps reduce render crashes and some systems where this does not work. In my experience, the render crash frequency increases as the amount of mesh geometry increases.
Render crashes in Blender 2.79 are much less frequent and a workaround of setting the Render Display to Fullscreens seems to work for all FLIP Fluids users.

I did notice if I had only FLIP Fluids domain and inflow mesh in the project, Blender 2.80 Rc 1 didn't crash at all. Locking Interface worked for me, I hope it will stay that way.

I really hope this gets fixed soon(and I mean before the stable release of 2.8). Flip Fluids is essentially unusable in Blender 2.8 because of it.

This is not only flip fluid related, this could probably affect also elbeem or Mantaflow, since in the end they are generating meshes too

Is there any work around for this? Even in the official release of 2.8 it crashes on render when using flip fluids. This has been an issue since January, can the Dev team at least tell us if this is something that CAN be fixed? Any communication on such an old high priority issue would be highly appreciated.

This of course can and will be fixed.

I'd very much appreciate this issue being fixed. Really excited for 2.8 and Flip Fluids but currently can't render any big files overnight which of course is a big problem.

I seem to have encountered a work-around. If you go under the Render menu and check Lock Interface it stops the crashes.

I seem to have encountered a work-around. If you go under the Render menu and check Lock Interface it stops the crashes.

Interesting, thank you Alyssa, so far I've been able to render a few dozen frames with no crash where before it would crash after 1 or 2.

I seem to have encountered a work-around. If you go under the Render menu and check Lock Interface it stops the crashes.

Yep, this was a “semi” workaround, Jacques mentioned it here before, but it still crashes after a few frames.

please fix this!
flip fluids is a must for any water sim in blender, the internal fluid simulation engine is a pain.
its a shame blender devs haven't fixed this bug already.

@Sergey Sharybin (sergey) : Just a note I have added this to 2.81 milestone (since it was set to "High"), I think you are on it already, right?

Sergey Sharybin (sergey) closed this task as Resolved.Wed, Sep 11, 11:07 AM

There are the following changes now made:

  • Dependency graph is always guaranteed to be fully evaluated after handlers for POST depsgraph/frame change (including adding/removing objects, modifying them and so on).

Currently it's as stable as we can make it. It is indeed true that interface is better be locked, otherwise render thread might cause conflicts with the viewport (due to python handlers possibly modifying data while it's being drawn by the viewport).

There are ways around it, but needs some design changes. Will be handled outside of the bug tracker as a regular development.

Great news, thanks @Sergey Sharybin (sergey) !

Currently it's as stable as we can make it.

Does it mean it may still crashes under certain circumstances?

Does it mean it may still crashes under certain circumstances?

Yes. If Python handler is adding/removing objects and rendering is happening without Locked Interface.
This was always an issue.

Thank you Sergey. Is the 2.8 build updated after the final release last month with these fixes? Should I reinstall the 2.8 version? Or is this fix only in the 2.81 version?

The fixes will be available in the net round of nightly builds and in 2.81.

2.81 release is scheduled for november as far as I remember, I'd bet they won't release a corrective 2.80a version but rather count on 2.81.