bvhtree.fromObject - error ( returned NULL without setting an error) in blender 2.8 #58734

Closed
opened 2018-12-04 20:03:37 +01:00 by Jose Conseco · 19 comments

x = bvhtree.BVHTree.FromObject(C.active_object, C.scene)
Is broken in blender 2.8 builds for some time now. I also tested on latest build from 4 December.

Error message:
raceback (most recent call last):

File "<blender_console>", line 1, in <module>

SystemError: <built-in method FromObject of type object at 0x0444CA30> returned NULL without setting an error
image.png

x = bvhtree.BVHTree.FromObject(C.active_object, C.scene) Is broken in blender 2.8 builds for some time now. I also tested on latest build from 4 December. Error message: raceback (most recent call last): ``` File "<blender_console>", line 1, in <module> ``` SystemError: <built-in method FromObject of type object at 0x0444CA30> returned NULL without setting an error ![image.png](https://archive.blender.org/developer/F5817161/image.png)
Author

Added subscriber: @JoseConseco

Added subscriber: @JoseConseco

blender/blender#59869 was marked as duplicate of this issue

blender/blender#59869 was marked as duplicate of this issue

blender/blender#59889 was marked as duplicate of this issue

blender/blender#59889 was marked as duplicate of this issue

#59710 was marked as duplicate of this issue

#59710 was marked as duplicate of this issue
Dalai Felinto was assigned by Bastien Montagne 2018-12-05 11:29:49 +01:00

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'

For the record, the API changed, see e7c3f7ba6f1385a2138862de8568e571fa97b5b4.

For the record, the API changed, see e7c3f7ba6f1385a2138862de8568e571fa97b5b4.
Author

Changed status from 'Resolved' to: 'Open'

Changed status from 'Resolved' to: 'Open'
Author

Thanks for the fix. The operation bvhtree .fromObject now works when executed once. But it crashes on second run of operation each time:
Steps to reproduce:
run in console:

from mathutils.bvhtree import BVHTree
BVHTree.FromObject(C.active_object, C.depsgraph) 
BVHTree.FromObject(C.active_object, C.depsgraph)  #it will crash here (no error)

In addon I developed I have operator with some F6 props, and if I edit any F6 operator props, BVHTree.FromObject will crash blender. Simple operator example (run it 2x to to crash blender):

import bpy
from mathutils.bvhtree import BVHTree

class SimpleOperator(bpy.types.Operator):
    """Tooltip"""
    bl_idname = "object.simple_operator"
    bl_label = "Simple Object Operator"
    

    def execute(self, context):
        sourceSurface_BVHT = BVHTree.FromObject(context.active_object, context.depsgraph) #crash on second run from F6 props
        print('Crash on second run')
        return {'FINISHED'}


def register():
    bpy.utils.register_class(SimpleOperator)


def unregister():
    bpy.utils.unregister_class(SimpleOperator)


if __name__ == "__main__":
    register()


Thanks for the fix. The operation bvhtree .fromObject now works when executed once. But it crashes on second run of operation each time: Steps to reproduce: run in console: ``` from mathutils.bvhtree import BVHTree BVHTree.FromObject(C.active_object, C.depsgraph) BVHTree.FromObject(C.active_object, C.depsgraph) #it will crash here (no error) ``` In addon I developed I have operator with some F6 props, and if I edit any F6 operator props, BVHTree.FromObject will crash blender. Simple operator example (run it 2x to to crash blender): ``` import bpy from mathutils.bvhtree import BVHTree class SimpleOperator(bpy.types.Operator): """Tooltip""" bl_idname = "object.simple_operator" bl_label = "Simple Object Operator" def execute(self, context): sourceSurface_BVHT = BVHTree.FromObject(context.active_object, context.depsgraph) #crash on second run from F6 props print('Crash on second run') return {'FINISHED'} def register(): bpy.utils.register_class(SimpleOperator) def unregister(): bpy.utils.unregister_class(SimpleOperator) if __name__ == "__main__": register() ```

It actually crashes immediatelly with:
BLI_assert failed: //source/blender/blenkernel/intern/DerivedMesh.c:2192, mesh_get_eval_final(), at 'ob->id.tag & LIB_TAG_COPIED_ON_WRITE'

It actually crashes immediatelly with: `BLI_assert failed: //source/blender/blenkernel/intern/DerivedMesh.c:2192, mesh_get_eval_final(), at 'ob->id.tag & LIB_TAG_COPIED_ON_WRITE'`

Added subscriber: @Sergey

Added subscriber: @Sergey

For the records, I can "fix" the initial crash with P872, however when I call it the second time I indeed get a crash:

SUMMARY: AddressSanitizer: heap-use-after-free //source/blender/blenkernel/intern/DerivedMesh.c:2208 in mesh_get_eval_final
Full backtrace: P871

@Sergey suggestions?

For the records, I can "fix" the initial crash with [P872](https://archive.blender.org/developer/P872.txt), however when I call it the second time I indeed get a crash: `SUMMARY: AddressSanitizer: heap-use-after-free //source/blender/blenkernel/intern/DerivedMesh.c:2208 in mesh_get_eval_final` Full backtrace: [P871](https://archive.blender.org/developer/P871.txt) @Sergey suggestions?

Think your assert is a side effect. Surely, should be fixed, but don't think it will crash.

The P872 is wrong. Is ok to mock around with evaluated objects which you control and own (as in the baking), but you must not do such trickery for objects which are only "leased" to you ;) Doing such stuff will confuse regular evaluation routines.

The fact that crash is only happening on redo makes me believe that it's same type of errors where operator wants to know evaluated state of the scene an unless special flag is set for an operator, dependency graph is not guaranteed to be evaluated.

Think your assert is a side effect. Surely, should be fixed, but don't think it will crash. The [P872](https://archive.blender.org/developer/P872.txt) is wrong. Is ok to mock around with evaluated objects which you control and own (as in the baking), but you must not do such trickery for objects which are only "leased" to you ;) Doing such stuff will confuse regular evaluation routines. The fact that crash is only happening on redo makes me believe that it's same type of errors where operator wants to know evaluated state of the scene an unless special flag is set for an operator, dependency graph is not guaranteed to be evaluated.

Added subscribers: @gumby1325, @ZedDB

Added subscribers: @gumby1325, @ZedDB
Member

Added subscriber: @MichelAnders

Added subscriber: @MichelAnders

This issue was referenced by blender/blender@b3e68a83f3

This issue was referenced by blender/blender@b3e68a83f30f7f9948a384d756aaf43eb055ab46

Added subscribers: @dfelinto, @mont29

Added subscribers: @dfelinto, @mont29
Dalai Felinto was unassigned by Bastien Montagne 2018-12-27 17:19:37 +01:00
Bastien Montagne self-assigned this 2018-12-27 17:19:37 +01:00

Issue is actually dead simple: C_BVHTree_FromObject() unconditionally frees its mesh, when bvh_get_mesh() actually may return direct data from evaluated object, not always creating its own mesh...

As for the asserts, one just have to pass eval object to mesh_get_eval_xxx() functions, not orig one.

Issue is actually dead simple: `C_BVHTree_FromObject()` unconditionally frees its mesh, when `bvh_get_mesh()` actually may return direct data from evaluated object, not always creating its own mesh... As for the asserts, one just have to pass eval object to `mesh_get_eval_xxx()` functions, not orig one.

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'
Member

great! works like a charm now :-) (tested on linux 64bit)

great! works like a charm now :-) (tested on linux 64bit)
Sign in to join this conversation.
No Milestone
No project
No Assignees
7 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender-addons#58734
No description provided.