Boris Staletic added the comment:
The `multiprocessing.Process`, on Linux, ends up doing something like this:
pid = os.fork()
if pid == 0: os._exit()
Translated to C:
int main() {
Py_Initialize();
PyOS_BeforeFork();
pid_t pid = fork();
if (pid == 0
Boris Staletic added the comment:
Slightly simpler C example:
#include
int main()
{
Py_Initialize();
PyObject* multiprocessing = PyImport_ImportModule("multiprocessing");
PyObject* Process = PyObject_GetAttrString(multiprocessing, "Process");
New submission from Boris Staletic :
The following C code leaks 7 locks allocated with PyThread_allocate_lock:
#include
int main()
{
Py_Initialize();
PyObject* multiprocessing = PyImport_ImportModule("multiprocessing");
PyObject* Process = PyObject_Get
Boris Staletic added the comment:
Oops... I uploaded (and pasted) the wrong file. The /correct/ example can be
found here:
https://github.com/pybind/pybind11/pull/2797/#pullrequestreview-570541151
However, I have just realized that the example doesn't really need the embedded
module
Boris Staletic added the comment:
Thanks for looking into this.
> Looks like a bug in valgrind.
That actually explains why I wasn't able to reproduce this problem on my local
machine. Ubuntu 20.04 comes with valgrind 3.15.0, while my local machine has
3.16.1. Upgrading valgrind on Ubu
Boris Staletic added the comment:
I can also reproduce the same problem with the ubuntu packaged python3, which
is 3.8.5 on Ubuntu 20.04. The only problem is that, with a stripped library,
you don't get line numbers in valgrind's output. Steps to repro:
1. apt install valgrind gcc python3
New submission from Boris Staletic :
When running valgrind on a C code that calls `PyUnicode_AsEncodedString` and
`PyUnicode_Decode`, valgrind reports that there's a conditional jump based on
uninitialized variable, if the encoding is "latin1".
I am able to replicate the
