Page MenuHome

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

Description

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

Details

Type
Bug

Event Timeline

Dalai Felinto (dfelinto) closed this task as Invalid.
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(update.id, "type") or update.id.type != 'MESH':
            continue
        
        mesh = update.id.data
        bm = bmesh.from_edit_mesh(mesh)        
        #bm.free()

bpy.app.handlers.depsgraph_update_post.append(depsgraph_handler)

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 bm.free() 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 bm.free and finding this:

https://developer.blender.org/T39121

Sergey Sharybin (sergey) reopened this task as Open.
Sergey Sharybin (sergey) triaged this task as Confirmed, Medium priority.

@Dalai Felinto (dfelinto), i don't think calling bm.free() 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