Charles-Fran??ois Natali <report@bugs.python.org> wrote:
> However, I have a stupid question: are those logs for the main
> process, or for child processes ?

Valgrind was run with --trace-children=no. However, the option is a bit
tricky, since it only affects tracing of sub-processes initiated via the
exec system call.

Even with --trace-children=no Valgrind *does* trace into the child of a fork:

http://valgrind.org/docs/manual/manual-core.html#manual-core.basicopts

> Because if fork() is called while other threads are running, since
> only the main thread exists in the child process, all the blocks only
> reachable from the other threads stacks at the time of the fork -
> among which the bootstate structure, and probably the buffer allocated
> in posix_read() while a thread is blocked on the read() syscall - are
> effectively leaked in the child process since they're not referenced
> anymore.

All lines of the log I posted are prefixed with ==3047==, which should
be the process number of the main thread.

I don't know if Valgrind reports leaks in a forked-without-exec-child
as part of the parent process log. But it could be the case here.

Regarding the posix_read leak: Running with --num-callers=50 shows
that it's also thread related:

==8736== 37 bytes in 1 blocks are definitely lost in loss record 383 of 10,841
==8736==    at 0x4C2154B: malloc (vg_replace_malloc.c:236)
==8736==    by 0x5476A5: PyBytes_FromStringAndSize (bytesobject.c:98)
==8736==    by 0x4EC94B: posix_read (posixmodule.c:7010)
==8736==    by 0x58417C: PyCFunction_Call (methodobject.c:81)
==8736==    by 0x496AE0: call_function (ceval.c:4051)
==8736==    by 0x491D87: PyEval_EvalFrameEx (ceval.c:2674)
==8736==    by 0x494D5D: PyEval_EvalCodeEx (ceval.c:3426)
==8736==    by 0x496FD2: fast_function (ceval.c:4149)
==8736==    by 0x496C13: call_function (ceval.c:4072)
==8736==    by 0x491D87: PyEval_EvalFrameEx (ceval.c:2674)
==8736==    by 0x494D5D: PyEval_EvalCodeEx (ceval.c:3426)
==8736==    by 0x496FD2: fast_function (ceval.c:4149)
==8736==    by 0x496C13: call_function (ceval.c:4072)
==8736==    by 0x491D87: PyEval_EvalFrameEx (ceval.c:2674)
==8736==    by 0x494D5D: PyEval_EvalCodeEx (ceval.c:3426)
==8736==    by 0x496FD2: fast_function (ceval.c:4149)
==8736==    by 0x496C13: call_function (ceval.c:4072)
==8736==    by 0x491D87: PyEval_EvalFrameEx (ceval.c:2674)
==8736==    by 0x494D5D: PyEval_EvalCodeEx (ceval.c:3426)
==8736==    by 0x56A637: function_call (funcobject.c:669)
==8736==    by 0x53A203: PyObject_Call (abstract.c:2150)
==8736==    by 0x497B32: ext_do_call (ceval.c:4366)
==8736==    by 0x49213B: PyEval_EvalFrameEx (ceval.c:2715)
==8736==    by 0x496EC7: fast_function (ceval.c:4139)
==8736==    by 0x496C13: call_function (ceval.c:4072)
==8736==    by 0x491D87: PyEval_EvalFrameEx (ceval.c:2674)
==8736==    by 0x496EC7: fast_function (ceval.c:4139)
==8736==    by 0x496C13: call_function (ceval.c:4072)
==8736==    by 0x491D87: PyEval_EvalFrameEx (ceval.c:2674)
==8736==    by 0x494D5D: PyEval_EvalCodeEx (ceval.c:3426)
==8736==    by 0x56A637: function_call (funcobject.c:669)
==8736==    by 0x53A203: PyObject_Call (abstract.c:2150)
==8736==    by 0x551FE1: method_call (classobject.c:320)
==8736==    by 0x53A203: PyObject_Call (abstract.c:2150)
==8736==    by 0x49638A: PyEval_CallObjectWithKeywords (ceval.c:3931)
==8736==    by 0x4E347F: t_bootstrap (_threadmodule.c:997)
==8736==    by 0x4E2DFC6: start_thread (in /lib/libpthread-2.7.so)
==8736==    by 0x579C64C: clone (in /lib/libc-2.7.so)
==8736==