Blender crash when selecting and moving vertex using API #85899

New Issue

Johannes Schmitz · 2021-02-22T20:27:27+01:00

Johannes Schmitz commented

2021-02-22 20:27:27 +01:00

System Information
Operating system: Linux Mint 20 Ulyana
Graphics card: NVIDIA GeForce RTX 2060 Super

Blender Version
Broken: 2.91.2, 5be9ef4177, master, 2021-01-19

Exact steps for others to reproduce the error
Blender crashes when opening a new instance pasting the below script in a new document in the "Scripting" editor and clicking play:


import bpy

context = bpy.context

# Assume default cube exists and select it
obj = bpy.data.objects["Cube"]
obj.select_set(state=True)
context.view_layer.objects.active = obj

# Select a vertex and move it
obj = bpy.context.active_object
obj.data.vertices[0].select = True
bpy.ops.object.mode_set(mode = 'EDIT')
bpy.ops.transform.translate('INVOKE_DEFAULT',
                            constraint_axis=(True, True, False),
                            orient_type='GLOBAL',
                            release_confirm=True)
bpy.ops.object.mode_set(mode='OBJECT')

**System Information** Operating system: Linux Mint 20 Ulyana Graphics card: NVIDIA GeForce RTX 2060 Super **Blender Version** Broken: 2.91.2, 5be9ef417703, master, 2021-01-19 **Exact steps for others to reproduce the error** Blender crashes when opening a new instance pasting the below script in a new document in the "Scripting" editor and clicking play: ``` import bpy context = bpy.context # Assume default cube exists and select it obj = bpy.data.objects["Cube"] obj.select_set(state=True) context.view_layer.objects.active = obj # Select a vertex and move it obj = bpy.context.active_object obj.data.vertices[0].select = True bpy.ops.object.mode_set(mode = 'EDIT') bpy.ops.transform.translate('INVOKE_DEFAULT', constraint_axis=(True, True, False), orient_type='GLOBAL', release_confirm=True) bpy.ops.object.mode_set(mode='OBJECT') ```

Johannes Schmitz commented

2021-02-22 20:27:27 +01:00

Added subscriber: @johschmitz

Germano Cavalcante commented

2021-02-24 22:27:15 +01:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2021-02-24 22:27:15 +01:00

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

Germano Cavalcante closed this issue

2021-02-24 22:27:15 +01:00

Germano Cavalcante commented

2021-02-24 22:27:15 +01:00

That code is calling for crash.
The problem is that the transform operator is executed with 'INVOKE_DEFAULT' which makes it continue to be executed in modal after the script has finished.
So, that operator operates on an edited mesh that no longer exists.

Although we can fix it by checking in advance if bmesh exists inside the operator, this does not seem to be worthwhile, as it would not be of any use (the code would still not work but it would not crash).

That code is calling for crash. The problem is that the transform operator is executed with `'INVOKE_DEFAULT'` which makes it continue to be executed in modal after the script has finished. So, that operator operates on an edited mesh that no longer exists. Although we can fix it by checking in advance if bmesh exists inside the operator, this does not seem to be worthwhile, as it would not be of any use (the code would still not work but it would not crash).

Johannes Schmitz commented

2021-02-24 22:40:35 +01:00

Woot? Are honestly saying it is okay that the Python scripting layer can bring down the whole application? I am a bit shocked. Are you not aiming at building a robust API and over time find and fix all the edge cases like this one and output a warning to the user that this is invalid? It is already done for other cases and I believe that is a good thing. When I see the warning I fix my script and try again but I don't need to restart the whole Blender. If this is too difficult to implement that is another story but right now I am quite disappointed about this decision and kindly ask you to reconsider the decision to close the ticket.

Germano Cavalcante commented

2021-02-24 23:59:08 +01:00

Fixing this would add overhead to the C code and could also complicate its readability a bit.
It also wouldn't do what you intend in the code.
Solving this would cause the line with bpy.ops.transform.translate to become a dead line (instead of crash).

Using bpy operators to edit a mesh is not ideal.
It is better to use the bmesh module: https://docs.blender.org/api/current/bmesh.html

Fixing this would add overhead to the C code and could also complicate its readability a bit. It also wouldn't do what you intend in the code. Solving this would cause the line with `bpy.ops.transform.translate` to become a dead line (instead of crash). Using bpy operators to edit a mesh is not ideal. It is better to use the bmesh module: https://docs.blender.org/api/current/bmesh.html

Johannes Schmitz commented

2021-02-25 07:23:06 +01:00

I will try to formulate it as requirements:

It should not be possible to crash blender with Python API calls. Never. If a combination a Python API calls is discovered that achieve this it should always be fixed. That will make blender become more and more robust over time.
When trying to go back to object mode from a state where it is not possible, an error message should be returned and blender should stay in the previous state. Alternatively the mode switch can be executed and the previous state has to be exited with an error message.
(I have already observed this kind of behavior for other mistakes when using the API and it made a lot of sense to me. The error messages usually where very useful. The crash and missing error message on the other hand cost me a lot of debug time since obviously I am not aware what is exactly going on in the underlying C code and state machines. Another reason to provide the user with a useful error message. )
The error message should more or less easily allow to identify which line in the Python code it was caused by.

I will try to formulate it as requirements: - It should not be possible to crash blender with Python API calls. Never. If a combination a Python API calls is discovered that achieve this it should always be fixed. That will make blender become more and more robust over time. - When trying to go back to object mode from a state where it is not possible, an error message should be returned and blender should stay in the previous state. Alternatively the mode switch can be executed and the previous state has to be exited with an error message. (I have already observed this kind of behavior for other mistakes when using the API and it made a lot of sense to me. The error messages usually where very useful. The crash and missing error message on the other hand cost me a lot of debug time since obviously I am not aware what is exactly going on in the underlying C code and state machines. Another reason to provide the user with a useful error message. ) - The error message should more or less easily allow to identify which line in the Python code it was caused by.

Germano Cavalcante commented

2021-02-25 12:13:31 +01:00

Changed status from 'Archived' to: 'Confirmed'

Germano Cavalcante reopened this issue

2021-02-25 12:13:31 +01:00

Germano Cavalcante commented

2021-02-25 12:13:31 +01:00

Operators usually do not raise python error messages, the similar would be warnings in the blender's UI.
The solution to this problem is not simple. The transform operator works with several types of objects that also exist only in one mode.
It would be necessary to create a kind of pool depending on the object to check if it still exists.
It would be considerable work.

(I'm confirming the bug, but I don't plan to work on it anytime soon. Another person can try to solve in the meantime).

Operators usually do not raise python error messages, the similar would be warnings in the blender's UI. The solution to this problem is not simple. The transform operator works with several types of objects that also exist only in one mode. It would be necessary to create a kind of pool depending on the object to check if it still exists. It would be considerable work. (I'm confirming the bug, but I don't plan to work on it anytime soon. Another person can try to solve in the meantime).

Johannes Schmitz commented

2021-02-25 19:14:56 +01:00

I think this is fair. Thank you. I understand that an open source project has limited resources and don't expect a solution after any specific amount of time. I think recording such bugs is valuable though. Even if they are only fixed after a couple of years.

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Blender crash when selecting and moving vertex using API #85899