Comment # 6 on bug 1174816 from Mohamed AMAZIRH

Hi Hans-Peter,

I wanted to report the bug (to share my findings) but found that it was already
done here.

Thanks for the workaround.

I investigated the issue and found that it's caused by the patch
make_python_3.6_compatible.patch which is part of the files used to package
blender for OpenSuse Leap 15.2.

make_python_3.6_compatible.patch replaced _PyObject_LookupAttr by a combination
of PyObject_HasAttr/PyObject_GetAttr to make blender's source code compatible
with python 3.6.

Blender crashes because, when creating a new "Video Editing" project for
example, it tries to unregister the python "cycles" module but fails in
bpy_rna.c#pyrna_unregister_class. (the cycles module is in
/usr/share/blender/2.82/scripts/addons/cycles/)

At first I thought that that, in the code introduced by the patch (in
bpy_rna.c), PyObject_HasAttr returned 1 but PyObject_GetAttr returned null
which was then passed to PyObject_CallObject and caused the crash. 

But after careful inspection, I noticed that PyObject_GetAttr exists outside of
the "case 1:{...}" block, so it's never called and PyObject_CallObject always
ends up with a null value as its first parameter.

I attached to this ticket a modified version of
make_python_3.6_compatible.patch that fixes the problem.

Also, here is the chain of events leading up to the crash:

1) Blender calls bl_app_template_utils.reset() from wm_files.c (line 511)
2) then at some point unregister from __init__.py in the "cycles" module is
called
3) which calls properties.unregister() on line 157
4) which then calls bpy.utils.unregister_class from properties.py on line 1622
5) which maps to pyrna_unregister_class from bpy_rna.c

(apparently only the classes from the cycles module implement the
register/unregister interface)

I hope this is helpful for resolving the bug and thanks for your work on this
package