jiridanek
commented
10 months ago The reproducer is actually quite easy. It is enough to initialize and deinitialize Python interpreter twice in the same process.
#include "./qdr_doctest.hpp"
#include "./helpers.hpp" // must come after ./qdr_doctest.hpp
#include <Python.h>
#include <thread>
TEST_CASE("Initialize and deinitialize Python twice")
{
std::thread([]() {
Py_Initialize();
PyObject *m = PyImport_ImportModule("ctypes");
Py_DECREF(m);
PyGC_Collect();
Py_Finalize();
}).join();
std::thread([]() {
Py_Initialize();
PyObject *m = PyImport_ImportModule("ctypes");
Py_DECREF(m);
PyGC_Collect();
Py_Finalize();
}).join();
}I arrived at this by simplifying my original test at https://github.com/skupperproject/skupper-router/blob/cfc8b4c6892dafc5dd0c86682b4db87a488f2451/tests/c_unittests/test_router_startup.cpp#L25
sobolevn
pablogsal
ericsnowcurrently
Crash report
What happened?
I have a binary which is embedding python. I want to test this binary with address sanitizer, and leak sanitizer. Regular python3.12 build contained in Fedora 39 causes lsan to report leaks even with
PYTHONMALLOC=malloc_debug, which with previous versions gave me clean run.Therefore, I tried
python3-debug, which is a debug build of python packaged in Fedora. With that, I hitand I was playing around a bit. When I hit the mentioned issue, I was using PYTHONMALLOC="malloc_debug". I wanted to try other values for this variable. With
pymalloc_debug, I got the same assertion.With
malloc, I gotand with
pymallocI got a different traceDoes this look like a Python bug? I'd be happy to attempt a reproducer if the backtraces are deemed sufficiently interesting and worth investigating.
CPython versions tested on:
3.12
Operating systems tested on:
Linux
Output from running 'python -VV' on the command line: