python -c “import faulthandler; faulthandler.enable();import bpy; bpy.ops.render.render(write_still=True)”
: Invalid conf pair: background_thread:true
: Invalid conf pair: dirty_decay_ms:4000
Traceback (most recent call last):
File “/usr/lib/python3.8/site-packages/2.82/scripts/modules/addon_utils.py”, line 351, in enable
mod = import(module_name)
ModuleNotFoundError: No module named ‘io_anim_bvh’
Traceback (most recent call last):
File “/usr/lib/python3.8/site-packages/2.82/scripts/modules/addon_utils.py”, line 351, in enable
mod = import(module_name)
ModuleNotFoundError: No module named ‘io_curve_svg’
Traceback (most recent call last):
File “/usr/lib/python3.8/site-packages/2.82/scripts/modules/addon_utils.py”, line 351, in enable
mod = import(module_name)
ModuleNotFoundError: No module named ‘io_mesh_ply’
Traceback (most recent call last):
File “/usr/lib/python3.8/site-packages/2.82/scripts/modules/addon_utils.py”, line 351, in enable
mod = import(module_name)
ModuleNotFoundError: No module named ‘io_mesh_stl’
Traceback (most recent call last):
File “/usr/lib/python3.8/site-packages/2.82/scripts/modules/addon_utils.py”, line 351, in enable
mod = import(module_name)
ModuleNotFoundError: No module named ‘io_mesh_uv_layout’
Traceback (most recent call last):
File “/usr/lib/python3.8/site-packages/2.82/scripts/modules/addon_utils.py”, line 351, in enable
mod = import(module_name)
ModuleNotFoundError: No module named ‘io_scene_fbx’
Traceback (most recent call last):
File “/usr/lib/python3.8/site-packages/2.82/scripts/modules/addon_utils.py”, line 351, in enable
mod = import(module_name)
ModuleNotFoundError: No module named ‘io_scene_gltf2’
Traceback (most recent call last):
File “/usr/lib/python3.8/site-packages/2.82/scripts/modules/addon_utils.py”, line 351, in enable
mod = import(module_name)
ModuleNotFoundError: No module named ‘io_scene_obj’
Traceback (most recent call last):
File “/usr/lib/python3.8/site-packages/2.82/scripts/modules/addon_utils.py”, line 351, in enable
mod = import(module_name)
ModuleNotFoundError: No module named ‘io_scene_x3d’
Fatal Python error: Segmentation fault
Current thread 0x00007f929fa4d740 (most recent call first):
File “/usr/lib/python3.8/site-packages/2.82/scripts/modules/bpy/ops.py”, line 201 in call
File “”, line 1 in
Segmentation fault (core dumped)
Am I doing anything wrong during build or what could it be? Thanks!
First off, note that the standalone bpy is experimental and might therefor not work at all.
That said I just built a bpy-only version of the master branch (so that’s code for the upcoming 2.90 version of Blender) on Arch. When I import bpy in Python 3.8.2 I also get a segfault, which appears to be caused by a null pointer during OpenGL context creation:
#0 0x0000000000000000 in ?? ()
#1 0x00007f5f7762ba27 in GPU_context_create () from /home/melis/software/blender-bpy-git/bpy.so
#2 0x00007f5f757ced24 in DRW_opengl_context_create () from /home/melis/software/blender-bpy-git/bpy.so
#3 0x00007f5f756fc8f9 in WM_init_opengl () from /home/melis/software/blender-bpy-git/bpy.so
#4 0x00007f5f757cfd37 in DRW_render_to_image () from /home/melis/software/blender-bpy-git/bpy.so
#5 0x00007f5f7714ebd4 in RE_engine_render () from /home/melis/software/blender-bpy-git/bpy.so
#6 0x00007f5f77158a11 in do_render () from /home/melis/software/blender-bpy-git/bpy.so
#7 0x00007f5f7715bba8 in do_render_all_options () from /home/melis/software/blender-bpy-git/bpy.so
#8 0x00007f5f7715c2c2 in RE_RenderFrame () from /home/melis/software/blender-bpy-git/bpy.so
This might be because there’s no GUI active (which is drawn using OpenGL) and therefore no OpenGL context and rendering is available at all, meaning EEVEE might not be usable when using Blender through the bpy module. I guess @ideasman42 would know if this is the case?
Switching to Cycles and then rendering does work though:
Hi @PaulMelis ,
I built bpy-only as well and I’m on Ubuntu, so it shouldn’t be very different from yours. And using CYCLES explicitly works for bpy.ops.render.render(write_still=True).
Having said that I’m experiencing a similar problem in a slightly different context. When I try to open a file inside my Flask app like so: bpy.ops.wm.open_mainfile(filepath='/home/yuranos/development/3D/model_all_parts.blend')
I’ve got Segmentation fault (core dumped)
However, running the same code directly from bash/python works Ok. Any idea what might be wrong? Can you try running a simple Flask app and see if you can reproduce it?
It can be as simple as:
Flask, by default, uses multiple threads to handle incoming requests. So the bpy.ops.wm.open_mainfile() call is made from a different thread than the main thread. This is not supported in the bpy module (nor when running Python scripts under regular Blender). All BPy calls need to be made from the same main thread.
Well, I don’t mind single-threaded, but it didn’t help. Still the same issue. Anything else?
I’m using the same Python version in both cases and running both the app and python script fro the same location and under the same virtual env activated.
But I’m obviously missing something…
No, no, I commented out the rest of it long time ago. I think the problem is pinpointed to opening the main file.
Here’s he stack(it’s in virtualenv but with ).
call, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:40
line, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:44
line, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:46
call, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:79
line, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:80
return, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:80
return, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:46
call, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:82
line, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:86
line, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:88
call, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:168
line, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:169
line, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:170
return, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:170
return, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:88
call, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:184
line, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:185
line, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:186
line, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:189
line, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:195
call, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:155
line, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:157
line, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:158
line, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:159
return, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:159
line, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:197
line, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:201
call, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:180
line, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:182
return, /home/yuranos/.local/lib/python3.7/site-packages/2.90/scripts/modules/bpy/ops.py:182
Segmentation fault (core dumped)
Well that’s the Python stack trace, which isn’t that useful here as the actual segfault happens in the bpy.so module somewhere in C/C++ code. Try running it under gdb, e.g.
Strange thing, @PaulMelis(I’m new to Flask and Python so it’s obviously something straightforward, but will need to investigate):
Your threading solution works if the app is started as python app.py. It does not however if I run flask run.
And it doesn’t fail in gdb as well.
The flask command luanches the server in a subtly different way, I guess. Perhaps there’s some hidden multithreading going on. Do the thread id prints give any clue?
They’re just numbers :-). In this case if the numbers are the same then this means the main thread and the one handling the request are the same, ie good. If they’re different then the calls are made from separate, ie bad.