Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash calling numpys import_array() in C++-Api when python runs in separate thread->might relate on way python loads hashlib (openssl) library #96650

Closed
Gockel92 opened this issue Sep 7, 2022 · 3 comments
Labels
3.9 only security fixes OS-mac type-crash A hard crash of the interpreter, possibly with a core dump

Comments

@Gockel92
Copy link

Gockel92 commented Sep 7, 2022

Crash report

I get an EXC_BAD_ACCESS Error when calling import_array() in an c++ program if Python runs in an different thread.

In detail I have written a module that uses Numpy. If I initialize Python in my main thread and import my module everything works fine. But if I initialize Python in an different thread and import the module in this thread, numpy crashes when calling import_array(). More precise the crash happens wenn PyImport_ImportModule("numpy.core._multiarray_umath") is called in _import_array() (_multiarray_api.h).

I'm using macOS Monterey 12.5.1 on an Apple Silicon (M1) processor. My Python version is 3.9.6 and the NumPy I'm using is 1.23.2. Python and Numpy are for ARM architecture. As compiler I'm using Clang 13.0.0. The issue can also be reproduced on Mac intel machines.

On Windows no problem occurs.

I posted this issue allready under numpy/numpy#21588. One user said that the error is probably caused by the way python loads the hashlib library, so it's more python than numpy. Therefore I post the error here now again

#define PY_SSIZE_T_CLEAN
#include <Python.h>
#include "numpy/arrayobject.h"
#include <iostream>





static PyObject *
spam_func(PyObject *self, PyObject *args)
{
    PyObject* rhsNpArray = NULL;
    if (!PyArg_ParseTuple(args, "O!", &PyArray_Type, &rhsNpArray))
        return NULL;
    int number = PyArray_NDIM(rhsNpArray);
    return PyLong_FromSize_t(number);
}
static PyMethodDef SpamMethods[] = {
    {"func",  spam_func, METH_VARARGS,
     "Execute spam_func."},
    {NULL, NULL, 0, NULL}        /* Sentinel */
};

static struct PyModuleDef spammodule = {
    PyModuleDef_HEAD_INIT,
    "spam",
    NULL,
    -1,       
    SpamMethods
};

PyMODINIT_FUNC
PyInit_spam(void)
{
    import_array();// here the crash happens
    
    if (PyErr_Occurred()) {
        std::cerr << "Failed to import numpy Python module(s)." << std::endl;
        return NULL;
    }
    assert(! PyErr_Occurred());
    return PyModule_Create(&spammodule);
}
void doPythonThing()
{

    if (PyImport_AppendInittab("spam", PyInit_spam) == -1) {
        fprintf(stderr, "Error: could not extend in-built modules table\n");
         exit(1);
     }

     Py_Initialize();

     PyObject *pmodule = PyImport_ImportModule("spam");
}





int
main(int argc, char *argv[])
{ 
    //calling doPythonThing without a new thread works fine
    std::thread thread(doPythonThing);
    thread.join();
    return 0; 
}

Error messages

Process 5308 launched: '/Users/robin/Desktop/build/pythonTest/spam' (arm64)
Process 5308 stopped
* thread #4, stop reason = EXC_BAD_ACCESS (code=2, address=0x16ff1bff8)
    frame #0: 0x000000018ec250cc libsystem_pthread.dylib`___chkstk_darwin + 60
libsystem_pthread.dylib`___chkstk_darwin:
->  0x18ec250cc <+60>: ldur   x11, [x11, #-0x8]
    0x18ec250d0 <+64>: mov    x10, sp
    0x18ec250d4 <+68>: cmp    x9, #0x1, lsl #12         ; =0x1000 
    0x18ec250d8 <+72>: b.lo   0x18ec250f0               ; <+96>
Target 0: (spam) stopped.

Your environment

macOS Monterey 12.5.1 on an Apple Silicon (M1) processor
Python 3.9.6
NumPy 1.23.2.

@Gockel92 Gockel92 added the type-crash A hard crash of the interpreter, possibly with a core dump label Sep 7, 2022
@iritkatriel iritkatriel added the 3.9 only security fixes label Sep 7, 2022
@Gockel92
Copy link
Author

The issue can also be reproduced on Mac machines with intel processors

@ronaldoussoren
Copy link
Contributor

I've been experimenting a bit, and the crash seems to be related to OpenBlas not hashlib, in particular with the multithreading support in OpenBlas.

When I compile the program above I get the same crash as you, but if I set 'OPENBLAS_NUM_THREADS=1' in the shell environment the program works without problems.

I'm fairly sure that this is not a problem with CPython.

@ronaldoussoren ronaldoussoren added the pending The issue will be closed if no feedback is provided label Nov 17, 2022
@ronaldoussoren
Copy link
Contributor

UPDATE:

The issue might be related to the stack size given the top of the stack trace. The default stack size for threads on macOS is fairly small. In CPython we explicitly set the stack size for threads we create in the threading module to a much larger value.

I have no idea how to change the stack size using std::thread, I haven't programmed in C++ for over 20 years.

@ronaldoussoren ronaldoussoren removed the pending The issue will be closed if no feedback is provided label Nov 21, 2022
@ronaldoussoren ronaldoussoren closed this as not planned Won't fix, can't repro, duplicate, stale Nov 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.9 only security fixes OS-mac type-crash A hard crash of the interpreter, possibly with a core dump
Projects
None yet
Development

No branches or pull requests

3 participants