Faults when trying to make a basic def

Numba Community Support
1

I am having a strange problem, and I’m not sure where else to ask, so I’m hoping this is the right place.

I am using mac os x mojave, python 3.8.12, numba 0.54.1, llvmlite 0.37.0. I’m attempting to do a very basic test of numba functionality. My script is very simple (see below). However, it throws a segmentation fault or illegal hardware instruction fault when I try to run it. I’m new to numba and could just be doing something stupid, but I’m at a loss after trying to fix it.

import numba as nb
@nb.jit
def test(a):
return a
print(test(1))

When running this script line-by-line, I am able to import numba fine. It only fails after the “return a” line and before the “print” line. Ie., it is failing when I try to define test(a).

The errors I am getting are, eg:

780 segmentation fault python test.py

or

786 illegal hardware instruction python test.py

The faulthandler suggests that the problem is llvmlite/binding/ffi.py. At least, that is the last item that pings before it has a fault.

I have come across some older threads that said there was a conflict between llvmlite and symengine that produces a similar fault (though, that occurs when importing numba, not when defining a function). However, I am using a clean env, and the only thing that is installed is numba (and its dependents) using pip. There is no symengine.

I have a very similar setup on a separate computer. Same os. And numba works fine on that one. Unfortunately, my work won’t allow me to program on that computer, so I’m stuck with the one that’s misbehaving.

I would appreciate any advice. Thank you.

2

Hello, I managed to fix the issue by downgrading my python from 3.8 to 3.7. It seems like maybe numba is broken for 3.8?

3

Hi @brolcz,

I’m glad you’ve got something working. I would guess that Numba is probably in general broken for Python 3.8 as the entire test suite is run against all supported python versions (which includes 3.8) on the Numba build farm as part of release (and general) testing. Also, that you have this working on one machine but not on a similar one suggests it’s something to do with the environment or perhaps something local to that machine.

Judging by the Numba version and your description of where the code breaks, I think the issue will be either in the loading of the llvmlite package libraries, or in the machine code generated in the compilation of the function. A segfault would be likely in the case of there being conflicting LLVM symbols in the process (IIRC that was the symengine problem), but that it sometimes does a SIGILL suggests there’s something else going on (perhaps bad code generation). If you’d like to debug this then it’d probably be worth running this under lldb and printing the backtrace (type bt) when it hits the SIGSEGV/SIGILL, that would likely point to which part of compilation is at fault.

Hope this helps?

4

Hi Stuartarchibald,

Thank you for getting back to me.

Regarding the comparison between computers, the reason I thought to downgrade to python 3.7 on the affected computer, was because I realized the other computer was running on python 3.7. So, while I think you’re still probably correct, I just wanted to point that out.

I have to rush to meet some deadlines now that this is working in some form, but I will revisit it when I get a moment and see if I can check lldb like you suggested.

Thanks!