Crash during lattice modifier evaluation during data transfer operator call with python #96888

New Issue

Simon Thommes · 2022-03-30T13:04:51+02:00

Simon Thommes commented

2022-03-30 13:04:51 +02:00

System Information
Operating system: Linux-5.15.23-76051523-generic-x86_64-with-glibc2.34 64 Bits
Graphics card: Quadro RTX 6000/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 510.54

Blender Version
Broken: version: 3.2.0 Alpha, branch: master, commit date: 2022-03-30 09:41, hash: ebb49ddd83
Worked: (newest version of Blender that worked as expected)

Short description of error
When running bpy.ops.object.data_transfer() with python Blender crashes while evaluating a lattice modifier.

Exact steps for others to reproduce the error
Run script in following file:
lattice_evaluation_crash.blend

**System Information** Operating system: Linux-5.15.23-76051523-generic-x86_64-with-glibc2.34 64 Bits Graphics card: Quadro RTX 6000/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 510.54 **Blender Version** Broken: version: 3.2.0 Alpha, branch: master, commit date: 2022-03-30 09:41, hash: `ebb49ddd83` Worked: (newest version of Blender that worked as expected) **Short description of error** When running `bpy.ops.object.data_transfer()` with python Blender crashes while evaluating a lattice modifier. **Exact steps for others to reproduce the error** Run script in following file: [lattice_evaluation_crash.blend](https://archive.blender.org/developer/F12956811/lattice_evaluation_crash.blend)

Simon Thommes commented

2022-03-30 13:04:51 +02:00

Added subscriber: @SimonThommes

Philipp Oeser commented

2022-03-30 13:25:31 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2022-03-30 13:25:31 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Philipp Oeser commented

2022-03-30 13:25:31 +02:00

Can confirm, will check in a bit.

Philipp Oeser commented

2022-03-30 15:43:32 +02:00

Changed status from 'Confirmed' to: 'Needs User Info'

Philipp Oeser commented

2022-03-30 15:43:32 +02:00

Seems like the operator needs the active_object correctly in the context (asserts if it is not a mesh - should not crash though, true).
If I override this as well, I dont get a crash.
Does this yield the correct results for you?

import bpy

bpy.ops.object.data_transfer(
    {
        "active_object": bpy.data.objects.get("Cube"),
        "object": bpy.data.objects.get("Cube"),
        "selected_editable_objects": [bpy.data.objects.get("Cube.001")],
    },
    data_type="UV",
    use_create=True,
    loop_mapping="NEAREST_POLYNOR",
    poly_mapping="NEAREST",
    layers_select_src="ALL",
    layers_select_dst="NAME",
    mix_mode="REPLACE",
)

This is where the assert happens btw.:

1   __pthread_kill_implementation                             0x7ffff7a90f0c 
2   raise                                                     0x7ffff7a40a36 
3   abort                                                     0x7ffff7a2a82f 
4   _BLI_assert_abort             BLI_assert.c           46   0x10aa301e     
5   makeDerivedMesh               DerivedMesh.cc         1766 0x427e041      
6   mesh_get_eval_final           DerivedMesh.cc         1822 0x427e2c9      
7   dt_layers_select_src_itemf    object_data_transfer.c 150  0x56a4ef9      
8   dt_layers_select_itemf        object_data_transfer.c 239  0x56a5348      
9   RNA_property_enum_items_ex    rna_access.c           1469 0x4c30941      
10  RNA_property_enum_items       rna_access.c           1500 0x4c30a48      
11  RNA_property_enum_value       rna_access.c           1644 0x4c31032      
12  pyrna_string_to_enum          bpy_rna.c              1238 0x4e9f91c      
13  pyrna_py_to_prop              bpy_rna.c              1778 0x4ea0d9a      
14  pyrna_pydict_to_props         bpy_rna.c              1493 0x4ea02fc      
15  pyop_call                     bpy_operator.c         259  0x4ebbb2f      
16  cfunction_call                methodobject.c         552  0xf6399c4      
17  _PyObject_MakeTpCall          call.c                 215  0xf5f3e28      
18  _PyObject_VectorcallTstate    abstract.h             112  0x3d8774b      
19  _PyObject_VectorcallTstate    abstract.h             99   0x3d8774b      
20  PyObject_Vectorcall           abstract.h             123  0x3d8774b      
... <More>

Seems like the operator needs the `active_object` correctly in the context (asserts if it is not a mesh - should not crash though, true). If I override this as well, I dont get a crash. Does this yield the correct results for you? ``` import bpy bpy.ops.object.data_transfer( { "active_object": bpy.data.objects.get("Cube"), "object": bpy.data.objects.get("Cube"), "selected_editable_objects": [bpy.data.objects.get("Cube.001")], }, data_type="UV", use_create=True, loop_mapping="NEAREST_POLYNOR", poly_mapping="NEAREST", layers_select_src="ALL", layers_select_dst="NAME", mix_mode="REPLACE", ) ``` This is where the assert happens btw.: ``` 1 __pthread_kill_implementation 0x7ffff7a90f0c 2 raise 0x7ffff7a40a36 3 abort 0x7ffff7a2a82f 4 _BLI_assert_abort BLI_assert.c 46 0x10aa301e 5 makeDerivedMesh DerivedMesh.cc 1766 0x427e041 6 mesh_get_eval_final DerivedMesh.cc 1822 0x427e2c9 7 dt_layers_select_src_itemf object_data_transfer.c 150 0x56a4ef9 8 dt_layers_select_itemf object_data_transfer.c 239 0x56a5348 9 RNA_property_enum_items_ex rna_access.c 1469 0x4c30941 10 RNA_property_enum_items rna_access.c 1500 0x4c30a48 11 RNA_property_enum_value rna_access.c 1644 0x4c31032 12 pyrna_string_to_enum bpy_rna.c 1238 0x4e9f91c 13 pyrna_py_to_prop bpy_rna.c 1778 0x4ea0d9a 14 pyrna_pydict_to_props bpy_rna.c 1493 0x4ea02fc 15 pyop_call bpy_operator.c 259 0x4ebbb2f 16 cfunction_call methodobject.c 552 0xf6399c4 17 _PyObject_MakeTpCall call.c 215 0xf5f3e28 18 _PyObject_VectorcallTstate abstract.h 112 0x3d8774b 19 _PyObject_VectorcallTstate abstract.h 99 0x3d8774b 20 PyObject_Vectorcall abstract.h 123 0x3d8774b ... <More> ```

Simon Thommes commented

2022-03-30 15:53:32 +02:00

Ah, interesting!

Yea, that seems to work, thanks! I always found it very unpredictable what an operator actually needs to have overridden, but I guess I should just override everything that could be potentially needed.
But yea, it probably still shouldn't crash. The issue seems to also just be with the lattice modifier from what I have seen.

But for my case, this definitely avoids the issue.

Ah, interesting! Yea, that seems to work, thanks! I always found it very unpredictable what an operator actually needs to have overridden, but I guess I should just override everything that could be potentially needed. But yea, it probably still shouldn't crash. The issue seems to also just be with the lattice modifier from what I have seen. But for my case, this definitely avoids the issue.

Julian Eisel commented

2022-03-31 11:28:01 +02:00

Added subscriber: @JulianEisel

Philipp Oeser commented

2022-04-04 17:11:11 +02:00

Changed status from 'Needs User Info' to: 'Needs Triage'

Philipp Oeser self-assigned this 2022-04-05 09:38:54 +02:00

blender-admin commented

2022-04-05 09:49:55 +02:00

This issue was referenced by 1d18c0682f

This issue was referenced by 1d18c0682fa43324193639c16fcee0d22c34d15e

Philipp Oeser commented

2022-04-05 10:04:45 +02:00

Lets still get rid of the crash ( D14552 will also let you override "object" - no need to override "active_object" then )

Lets still get rid of the crash ( [D14552](https://archive.blender.org/developer/D14552) will also let you override "object" - no need to override "active_object" then )

Philipp Oeser commented

2022-04-05 15:13:23 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Philipp Oeser commented

2022-04-07 10:54:33 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Philipp Oeser closed this issue

2022-04-07 10:54:33 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Crash during lattice modifier evaluation during data transfer operator call with python #96888