bvhtree.fromObject - error ( returned NULL without setting an error) in blender 2.8 #58734
Labels
No Label
Interest
Animation & Rigging
Interest
Blender Cloud
Interest
Collada
Interest
Core
Interest
Documentation
Interest
Eevee & Viewport
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
Import and Export
Interest
Modeling
Interest
Modifiers
Interest
Nodes & Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds, Tests & Devices
Interest
Python API
Interest
Rendering & Cycles
Interest
Sculpt, Paint & Texture
Interest
Translations
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Meta
Good First Issue
Meta
Papercut
Module
Add-ons (BF-Blender)
Module
Add-ons (Community)
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
7 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender-addons#58734
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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):
SystemError: <built-in method FromObject of type object at 0x0444CA30> returned NULL without setting an error
Added subscriber: @JoseConseco
blender/blender#59869 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
Changed status from 'Open' to: 'Resolved'
For the record, the API changed, see e7c3f7ba6f1385a2138862de8568e571fa97b5b4.
Changed status from 'Resolved' to: 'Open'
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:
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):
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
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?
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.
Added subscribers: @gumby1325, @ZedDB
Added subscriber: @MichelAnders
This issue was referenced by blender/blender@b3e68a83f3
Added subscribers: @dfelinto, @mont29
Issue is actually dead simple:
C_BVHTree_FromObject()
unconditionally frees its mesh, whenbvh_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'
great! works like a charm now :-) (tested on linux 64bit)