Segmentation fault when running custom built bpy

Hello,
I am getting segfault when running custom built bpy as in this topic [SOLVED] Error when importing bpy after compiling it in ArchLinux

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!

Not sure if it’s related or not- but has Blender updated to python 3.8 yet? I was under the impression 3.7 was still the requirement.

We’re gonna stick with 3.7 for the rest of the year, however building with 3.8 should work.

Building works…But should also running bpy work?

bpy is one of those things @ideasman42 likes to keep working, but afaik there’s no official support for it what so ever.

Judging from the logs, i’d probably check if the addons are properly installed to /usr/lib/python3.8/site-packages/2.82/scripts/addons

These addon errors are there since we started working with blender 2 years ago so that shouldn’t impact SegFault.

Pinging this thread. We are stuck with v2.78 in our project because of this issue and we have templates created in v2.81 that we can’t use.

I get a segfault when I import bpy built from blender-v2.83-release on python 3.7, did you get it to work somehow ? Thanks

EDIT: seems that running the test brings a segfault, but listing objects of the, I assume default scene works:

[bpy.data.objects[‘Camera’], bpy.data.objects[‘Cube’], bpy.data.objects[‘Light’]]

EDIT: Confirmed it crashes when rendering with Eeve. It works with Cycles

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:

Python 3.8.2 (default, Apr  8 2020, 14:31:25) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import bpy
>>> bpy.context.scene.render.engine = 'CYCLES'
>>> bpy.ops.render.render(write_still=True)
...
Fra:1 Mem:48.36M (0.00M, Peak 48.90M) | Time:00:22.42 | Remaining:00:00.01 | Mem:1.65M, Peak:2.04M | Scene, View Layer | Rendered 509/510 Tiles, Sample 128/128
Fra:1 Mem:48.25M (0.00M, Peak 48.90M) | Time:00:22.45 | Mem:1.53M, Peak:2.04M | Scene, View Layer | Rendered 510/510 Tiles
Fra:1 Mem:48.25M (0.00M, Peak 48.90M) | Time:00:22.45 | Mem:1.53M, Peak:2.04M | Scene, View Layer | Finished
Fra:1 Mem:46.64M (0.00M, Peak 48.90M) | Time:00:22.45 | Sce: Scene Ve:0 Fa:0 La:0
Saved: '/tmp/.png'
 Time: 00:22.97 (Saving: 00:00.51)

{'FINISHED'}
>>> 

So perhaps try switching to Cycles explicitly and see if that helps.

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:

from flask import Flask
import bpy

app = Flask(__name__)


@app.route('/')
def hello():
    bpy.context.scene.render.engine = 'CYCLES'
    bpy.ops.wm.open_mainfile(filepath='...')
    return "Hello World!"

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.

Try running Flask in single-threaded mode, e.g.

#!/usr/bin/env python
from flask import Flask
import bpy
import threading

app = Flask(__name__)
print('main thread', threading.get_ident())

@app.route('/')
def hello():
    print('handler thread', threading.get_ident())
    bpy.context.scene.render.engine = 'CYCLES'
    bpy.ops.wm.open_mainfile(filepath='test.blend')
    return "Hello World!"
    
if __name__ == '__main__':
    app.run(threaded=False)

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…

Hmm, without the actual stack trace when it segfaults it’s going to be hard to track down. Can you provide this?

And does the example above that only does a file open already segfault for you? Or is the script doing more?

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.

$ gdb `which python`
...
(gdb) run <script.py>
...
<segfault happens>
(gdb) bt
<shows stack trace>

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?

1 Like

Well, I have yet to learn how to interpret Python thread ids.

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.