[issue13090] test_multiprocessing: memory leaks

Changes by Stefan Krah : -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[issue13090] test_multiprocessing: memory leaks

Stefan Krah added the comment: Well, since I was the one who opened this: It seems difficult if not impossible to fix the problem, so we can probably close the issue. [Please just reopen if you disagree.] -- resolution: -> wont fix stage: needs patch -> resolved _

[issue13090] test_multiprocessing: memory leaks

STINNER Victor added the comment: > If a daemon thread is killed while it is blocking on os.read() > then the bytes object used as the read buffer will never be decrefed. Ah yes, so another reason to ensure that daemon threads exit normally at Python shutdown :-) -- __

[issue13090] test_multiprocessing: memory leaks

Richard Oudkerk added the comment: > If the result of os.read() was stored in a Python daemon thread, the > memory should be released since the following changeset. Can someone > check if this issue still exist? If a daemon thread is killed while it is blocking on os.read() then the bytes obj

[issue13090] test_multiprocessing: memory leaks

Stefan Krah added the comment: The leaks still exist here. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue13090] test_multiprocessing: memory leaks

STINNER Victor added the comment: If the result of os.read() was stored in a Python daemon thread, the memory should be released since the following changeset. Can someone check if this issue still exist? changeset: 87070:c2a13acd5e2b user:Victor Stinner date:Tue Nov 12 16:3

[issue13090] test_multiprocessing: memory leaks

Antoine Pitrou added the comment: > Regarding the posix_read leak: Running with --num-callers=50 shows > that it's also thread related: Would be nice to know if it's a daemon thread. Daemon threads are simply killed by the OS at shutdown. -- ___ Pyt

[issue13090] test_multiprocessing: memory leaks

Stefan Krah added the comment: Charles-Fran??ois Natali 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 ini

[issue13090] test_multiprocessing: memory leaks

Charles-François Natali added the comment: > Two others seem to be the internal "bootstate" structure used to > run thread objects (daemon threads?). Even for daemon threads, since the boostate structure is freed when the thread's run() method returns, this shouldn't show up as a "definitely lo

[issue13090] test_multiprocessing: memory leaks

Antoine Pitrou added the comment: The first one seems to be the import lock. Two others seem to be the internal "bootstate" structure used to run thread objects (daemon threads?). Perhaps you could try to find whether a single test is responsible. -- nosy: +neologix _

[issue13090] test_multiprocessing: memory leaks

Stefan Krah added the comment: Stefan Krah wrote: > enough, the number of leaks in test_multiprocessing has grown to > five in e9d01c5c92ed (the four additional ones were definitely not To be sure, e9d01c5c92ed is completely innocent. I just tested with that revision. :) -- _

[issue13090] test_multiprocessing: memory leaks

Stefan Krah added the comment: Yes, the leak does not seem to be in posix_read() itself. Sadly enough, the number of leaks in test_multiprocessing has grown to five in e9d01c5c92ed (the four additional ones were definitely not present when I reported this). ==3047== 32 bytes in 1 blocks are de