Segfault in libmxnet.so

Discussion
1

I am attempting to build the MXNet library for an embedded ARM system but am having some issues validating the build.
I built the library with the following options as I was trying to build a minimal footprint library. I will not be doing any image recognition or GPU.

-DUSE_CUDA=OFF -DUSE_MKL_IF_AVAILABLE=OFF -DUSE_MKLDNN=OFF -DUSE_OPENCV=OFF -DUSE_OPENMP=OFF -DUSE_SSE=OFF -DUSE_F16C=OFF -DUSE_GPERFTOOLS=0 -DUSE_JEMALLOC=0

I built both the library and the python bindings using Buildroot but the library seg faults when trying to import the MXNet module into Python.
I hooked up GDB to Python to better understand what was seg faulting and got the following stack trace:

$ export MXNET_LIBRARY_PATH=/usr/lib/libmxnet.so && gdb python

Python 2.7.15 (default, Jul 31 2018, 19:39:18) 
[GCC 8.1.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import mxnet

Program received signal SIGSEGV, Segmentation fault.
0x76c05ab8 in __cxa_thread_atexit_impl () from /lib/libc.so.6
(gdb) backtrace 
#0  0x76c05ab8 in __cxa_thread_atexit_impl () from /lib/libc.so.6
#1  0x757ac398 in NNListAllOpNames () from /usr/lib/libmxnet.so
#2  0x76a8962c in ffi_call_VFP () from /usr/lib/libffi.so.6
#3  0x76a89e94 in ffi_call () from /usr/lib/libffi.so.6
#4  0x76aabeb4 in _ctypes_callproc ()
   from /usr/lib/python2.7/lib-dynload/_ctypes.so
#5  0x76aa2918 in ?? () from /usr/lib/python2.7/lib-dynload/_ctypes.so
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

I don’t know if I missed some options when building libc or if I need to disable some options when building MXNet but was wondering if anyone in the community had thoughts/insights into what might be going wrong.

2

@larroy any idea on why that might be and the recommend flags are for a minimal footprint build on ARM ?

Alternatively, have a look at this link:

My recommendation would be to see if you can get a build that works with your platform, and turn the flags off one by one to isolate the one that creates the crash.

3

I’ll work on that. I did realize that I built the library with gcc 7 whereas the build guide recommends v4 (and not using v5 or 6). Do you know if GCC 7 or 8 are OK to use? I’ll try to rebuild it again tomorrow using v4 and see if that helps.

2 Likes