Trying to get Blender to run in the CuBox-i (armhf): Help debugging Python!

As I posted some weeks ago, I have been playing with my CuBox-i4Pro, a gorgeous little ARM machine by SolidRun, built around an iMX6 system-on-a-chip.

My first stabs at using it resulted in my previous post on how to get a base, almost-clean Debian distribution to run (Almost? Yes, the kernel requires some patches not yet accepted upstream, so I’m still running with a patched 3.0.35-8 kernel). After writing this step by step instructions, I followed them and built images ready to dd to a SD card and start running (available at my people.debian.org space.

Now, what to do with this little machine? My version is by no means a limited box: 4 ARM cores, 2GB RAM make a quite decent box. In my case, this little machine will most likely be a home storage server with little innovation. However, the little guy is a power server, at only 3W consumption. I wanted to test its capabilities to do some number crunching and aid some of my friends — The obvious candidate is building a Blender render farm. Right, the machines might be quite underpowered, but they are cheap (and look gorgeous!), so at least it’s worth playing a bit!

Just as a data point, running on an old hard disk (and not on my very slow SD card), the little machine was able to compile the Blender sources into a Debian package in 89m13.537s, that is, 5353 seconds. According to the Debian build logs (yes, for a different version, I tried with the version in Wheezy and in a clean Wheezy system), the time it took to build on some other architectures’ build daemons was 1886s on i386, 1098s on PowerPC, 2003s on AMD64, 11513s on MIPS and 27721 on ARMHF. That means, my little machine is quite slower than desktop systems, but not unbearably so.

But sadly, I have hit a wall, and have been unable to do any further progress. Blender segfaults at startup under the Debian armhf architecture. I have submitted bug report #739194 about this, but have got no replies to it yet. I did get the great help from my friends in the OFTC #debian-arm channel, but they could only help up to a given point. It seems the problem lies in the Python interpreter in armhf, not in Blender itself… But I cannot get much further either. I’m sending this as a blog post to try to get more eyeballs on my problem — How selfish, right? :-)

So, slightly going over the bug report, blender just dies at startup:

$ blender -b -noaudio Segmentation fault

After being told that strace is of little help when debugging this kind of issues, I went via gdb. A full backtrace pointed to what feels like the right error point:

(gdb) bt full #0 0x2acd8cce in PyErr_SetObject () from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0 No symbol table info available. #1 0x2acd8c9a in PyErr_Format () from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0 No symbol table info available. #2 0x2ac8262c in PyType_Ready () from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0 No symbol table info available. #3 0x2ac55052 in _PyExc_Init () from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0 No symbol table info available. #4 0x2ace95e2 in _Py_InitializeEx_Private () from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0 No symbol table info available. #5 0x00697898 in BPY_python_start (argc=3, argv=0x7efff8d4) at /build/blender-dPxPUD/blender-2.69/source/blender/python/intern/bpy_interface.c:274 py_tstate = 0x0 py_path_bundle = 0x0 program_path_wchar = L"/usr/bin/blender", '\000' <repeats 1007 times> #6 0x0044a1ca in WM_init (C=C@entry=0x1d83220, argc=argc@entry=3, argv=argv@entry=0x7efff8d4) at /build/blender-dPxPUD/blender-2.69/source/blender/windowmanager/intern/wm_init_exit.c:176 No locals. #7 0x0042e4de in main (argc=3, argv=0x7efff8d4) at /build/blender-dPxPUD/blender-2.69/source/creator/creator.c:1597 C = 0x1d83220 syshandle = 0x1d8a338 ba = 0x1d8a840 (gdb)

I’m not pasting here the full bug history (go to the bug report for the full information!), but it does point me to this being a problem in Python-land: It points to something not found at line 59 of Python/errors.c. And what I understand from that line is that some kind of unknown exception is thrown, and the Python interpreter does not now what to do with it. The check done at line 59 is the if (exception != NULL ** ….:

void PyErr_SetObject(PyObject *exception, PyObject *value) { PyThreadState *tstate = PyThreadState_GET(); PyObject *exc_value; PyObject *tb = NULL;

if (exception != NULL &&
    !PyExceptionClass_Check(exception)) {
    PyErr_Format(PyExc_SystemError,
                 "exception %R not a BaseException subclass",
                 exception);
    return;
} </code>

So… Dear lazyweb: Any pointers on where to go on from here?

kthxbye.