Page MenuHome

Python/BMesh: Crash on UV changes when handling depsgraph update - CDLayer re-allocation issue
Confirmed, NormalPublicBUG


System Information
Operating system: Windows 10
Graphics card: GTX970

Blender Version
Broken: Blender 2.8 RC1

Short description of error
On an addon I subscribe to the depsgraph update handler. The handler grabs some data via bmesh - its not changing anything.
Testing with the default cube - everything works fine, one can move uvs around without issues.
But on a cube with 6 subdivision (24k verts) - moving uvs results often in corruption and soon blender crashes.
Interesstingly doing regular vert transformation in the 3d view doens't create any issues as far as I can tell.

Exact steps for others to reproduce the error

  1. load attached blend file
  2. run script in text editor (review script - its really simple)
  3. enter edit mode on the cube
  4. make a uv selection
  5. try moving uvs around

Event Timeline

Dalai Felinto (dfelinto) changed the task status from Unknown Status to Invalid.Jul 17 2019, 1:50 AM
Dalai Felinto (dfelinto) claimed this task.

I get the crash even with a simple cube (and debug + ASAN build) and the following script (simplified from the reported one):

import bpy
import bmesh

def depsgraph_handler(dummy):
    depsgraph = bpy.context.evaluated_depsgraph_get()
    for update in depsgraph.updates:
        if not hasattr(, "type") or != 'MESH':
        mesh =
        bm = bmesh.from_edit_mesh(mesh)       

SUMMARY: AddressSanitizer: heap-use-after-free //source/blender/editors/transform/transform_conversions.c:3669 in flushTransUVs
Fullbacktrace: P1039

That said you are not freeing bm in your script. If you do that the crash goes away.

Closing for now, but poking other devs in case I'm missing something here:
cc @Sergey Sharybin (sergey) @Campbell Barton (campbellbarton)

@Dalai Felinto (dfelinto) thank you for looking into this.

I forgot to try in this case but I was under the impression that one should not call this for a bm bm.from_edit_mesh. I remember me having issues calling and finding this:

Sergey Sharybin (sergey) changed the task status from Invalid to Unknown Status.Jul 17 2019, 9:53 AM
Sergey Sharybin (sergey) lowered the priority of this task from 90 to 50.

@Dalai Felinto (dfelinto), i don't think calling is correct here. It doesn't make sense to free an internal data, and it only causes confusion in the script later on with AttributeError: 'bytes' object has no attribute 'faces'.

It seems that simply iterating over geometry confuses something with modal operator: possible re-allocations or tagging?

This isn't my area, leaving up to @Campbell Barton (campbellbarton) and @Bastien Montagne (mont29). I can reproduce the issue in 2.79, so doubt it's caused by the dependency graph or copy-on-write.

Yes, bpy BM access seems to re-allocate some customdata memory, and since transform operator for UVs keeps a direct pointer to that UV CDLayer… it can do nothing but crash!

@Campbell Barton (campbellbarton) I would rather leave this to you, think you have a much more complete view/understanding of those areas of code? I really do not see how to handle this case, besides not storing *any* pointer reference to CDLayer data from BMesh, in the modal operators.

Or maybe we should always ensure edit bmesh does have the CD_BM_ELEM_PYPTR? But that would only fix that case, any code adding some new layer will generate the same problem…

Bastien Montagne (mont29) renamed this task from Python: Crash on UV changes when handling depsgraph update to Python/BMesh: Crash on UV changes when handling depsgraph update - CDLayer re-allocation issue.Jul 22 2019, 3:19 PM
Philipp Oeser (lichtwerk) changed the subtype of this task from "Report" to "Bug".Feb 4 2020, 10:58 AM