ffi.lib.LLVMPY_TryAllocateExecutableMemory() not triggering OSError.

[perdigao1]

llvmlite/llvmlite/binding/executionengine.py

Line 40 in bf28f75

errno = ffi.lib.LLVMPY_TryAllocateExecutableMemory()

I am experiencing "Windows fatal exception: access violation" at "from numba import jit" line. The problem traces to this call ffi.lib.LLVMPY_TryAllocateExecutableMemory()

I have noticed that this error does not occur in different systems and, the error is probably triggered by a security OS block when it allocates RW memory and tries to flip to RX (executable) memory, as required by the JIT. Although there's probably no workaround, the code is supposed raise a OSError. However it never raises this error because the value of errno is set to zero by the function despite the error.

def check_jit_execution():
    """
    Check the system allows execution of in-memory JITted functions.
    An exception is raised otherwise.
    """
    errno = ffi.lib.LLVMPY_TryAllocateExecutableMemory()  # <== "Windows fatal exception" here, but errno is set to zero
    if errno != 0:
        raise OSError(errno,
                      "cannot allocate executable memory. "
                      "This may be due to security restrictions on your "
                      "system, such as SELinux or similar mechanisms."

[sklam]

@perdigao1, thank you for reporting the error.

Can you provide more details regarding the system?

• OS version
• Python version
• llvmlite version
• Are there any active security/antivirus software that maybe running?

[perdigao1]

Hi, thank you for checking
This was:

• Python 3.9.8, 3.10, 3.12, 3.14.
• several versions combinations of numba and llvm versions and all gave the same error.
• OS, Windows 11
• Sophos antivirus installed. I checked it and it hooks onto any python that runs. I believe this is what is causing the error we are experiencing, but it is difficult to pinpoint.

[gmarkall]

However it never raises this error because the value of errno is set to zero by the function despite the error.

I'm not following the logic here - if there was an access violation inside LLVMPY_TryAllocateExecutableMemory(), how could control have reached the return of the function for there to be any value to assign to errno? My understanding is that the process would exit inside LLVMPY_TryAllocateExecutableMemory() in the situation here.

[sklam]

@perdigao1, The issue that you are seeing seems to be caused by Sophos' feature of blocking Dynamic Shellcode (described here https://support.sophos.com/support/s/article/KBA-000007964?language=en_US):

Dynamic Shellcode protection builds on Data Execution Prevention (DEP): Which separates memory into areas for storing processor steps and data storage. Dynamic Shellcode protection prevents an application from allocating or running from a memory page containing dynamically generated code. Dynamically generated code is not part of the base application, such as .exe or .dll.

I don't think there's much we can do. The only option is for you to configure Sophos to not apply the dynamic code protection feature on the python executable or the llvmlite.dll to be more specific. If applied on the python.exe, it will however allow other potential malicious code to allocate dynamic memory bypassing Sophos.

[perdigao1]

Thank you for your replies
Indeed. It is probably Sophos that is blocking.
@gmarkall , I was wondering the same. If there is an error the function should return a error number.... but it appears that it is not, and just returning zero
Perhaps, to best capture errors in this function there should be a try except block. But I am not sure if it will work (see below)

To add a bit of more context, here is some test code below.
This problem is showing up as several error messages when running pytests, and it appears when running from numba import njit. When running the code normally, these error messages do not show up. But if we add the faulthandler, the errors are printed. pytest enables faulthandler by default.

import faulthandler
import sys

# https://docs.python.org/3/library/faulthandler.html
# Errors will be dumped to console
#  SIGSEGV, SIGFPE, SIGABRT, SIGBUS, and SIGILL
faulthandler.enable(file=sys.stderr, all_threads=True)

from numba import njit # Triggering error but continues running

@njit
def foo(s):
    return s

if __name__=="__main__":
    print("Hello World")
    print(foo("Nice to meet you"))

Interesting enough, despite the error showing up, code that is written to use njit appear to compile and run successfully with acceleration.

Correct me if I am wrong. The code is JITed, the compiled code is saved somewhere (RAM), and then executed. So the actual code execution is probably ever calling LLVMPY_TryAllocateExecutableMemory() .

I just tried to debug a bit. During the import LLVMPY_TryAllocateExecutableMemory() is a wrapped class and is called 3 times. At first occurence _lib_fn_wrapper.get_attr handles a KeyError, which will create the new key in _fntab in class _lib_wrapper.
Second time it calls self._fntab[name], its setter restype function . Will return long, if I am correct
Third time, from check_jit_execution(), makes a proper call , with empty arguments, and throws the error. The DLL file is llvmlite.dll

Program continues running, and LLVMPY_TryAllocateExecutableMemory is not called again. Why does llvmlite need to check for the allocation if it appears that it does not use it anyway?

Anyway, in an attempt to track down how the error code is generated and why it is not capturing Windows fatal exception this is what I found

The relevant code in ffi/executionengine.cpp

    using namespace llvm::sys;
    std::error_code ec;
    MemoryBlock mb = Memory::allocateMappedMemory(
        4096, nullptr, Memory::MF_READ | Memory::MF_WRITE, ec);
    if (!ec) {
        ec = Memory::protectMappedMemory(mb, Memory::MF_READ | Memory::MF_EXEC);
        (void)Memory::releaseMappedMemory(mb); /* Should always succeed */
    }
    return ec.value();
}

the error code variable ec is set inside Memory::allocateMappedMemory . I am not sure about where to find the source code for this. Inside this function is where it probably the Windows Fatal Exception occurs. Probably python will not capture this error with an try exception block. Not sure.

Regards
p