New submission from Jorge Herskovic :
The shelve module documentation states that "by default, mutations to
persistent-dictionary mutable entries are not automatically written
back. If the optional writeback parameter is set to True, all entries
accessed are cached in memory, and written ba
New submission from Jorge Herskovic:
I'm writing a library on top of multiprocessing. As part of the test suite, I
create and destroy dozens of processes repeatedly. About once in 50 runs, the
tests complete successfully but the program crashes with:
Error in atexit._run_exitfuncs:
Trac
Jorge Herskovic added the comment:
This happens reliably between 1-5% of the time on my home Mac (a 4.0 GHz i7).
My work Mac Pro, a lot slower, doesn't exhibit this behavior on the same 3.4.3
interpreter.
Could it be related to a concurrency issue in the interpreter?
We're att
Jorge Herskovic added the comment:
More data:
I've been unable to replicate this behavior on Ubuntu 15.04 on Python 3.4.3
over ~20 thousand test runs. (Same machine, running in a VM)
An overnight repeated run on the original machine on OS X, 3.4.3, official
distribution gave an a
Jorge Herskovic added the comment:
The failing Python:
3.4.3 (v3.4.3:9b73f1c3e601, Feb 23 2015, 02:52:03)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]
The non-failing Python:
3.4.3 (default, Jun 23 2015, 06:33:02)
[GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)]
The non-failing python
Jorge Herskovic added the comment:
20,000+ iterations of the test suite with my homebuilt 3.4.3 throw no
exceptions.
Weirder and weirder.
Any suggestions? Without any actual knowledge ("unencumbered by the thought
process"), a concurrency issue in the interpreter itself i
Jorge Herskovic added the comment:
Finally able to repro on my old Mac Pro at work (Universal 64/32bit 3.4.3 from
python.org, OS X 10.10.3). For some reason I can't quite fathom, there were two
exceptions this time.
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
Jorge Herskovic added the comment:
Ok, sorry, one more important thing I omitted in the previous comment.
^^^ The second exception above seems to be related to a new test I added, one
that includes a daemonic process which itself relies on daemonic threads.
The cleanup of that seems to be
Jorge Herskovic added the comment:
Ok, I *think* I tracked it down to Connections getting cleaned up in a
non-orderly fashion, sometimes while _run_finalizers is executing. The
following patch to lib/python3.4/multiprocessing/connection.py cures the
problem on my machine.
@@ -124,10 +124,10
