[issue25764] PyObject_Call() is called with an exception set in subprocess

2015-12-10 Thread Roundup Robot
Roundup Robot added the comment: New changeset fe844253cd44 by Martin Panter in branch '3.5': Issue #25764: Skip fork failure test when run as root https://hg.python.org/cpython/rev/fe844253cd44 New changeset 2f9541cab936 by Martin Panter in branch 'default': Issue #25764: Merge fix for root

[issue25764] PyObject_Call() is called with an exception set in subprocess

2015-12-05 Thread Martin Panter
Martin Panter added the comment: Here is a better failure in test_close_fds_after_preexec(), raising ENOMEM, so I am fairly confident that my fix is working and the exception from fork() is passing through properly.

[issue25764] PyObject_Call() is called with an exception set in subprocess

2015-12-05 Thread Roundup Robot
Roundup Robot added the comment: New changeset 6f831de45f43 by Martin Panter in branch '3.4': Issue #25764: Skip the test on OS X https://hg.python.org/cpython/rev/6f831de45f43 New changeset 6211c41106cc by Martin Panter in branch '3.5': Issue #25764: Merge OS X test skipping from 3.4 into 3.5

[issue25764] PyObject_Call() is called with an exception set in subprocess

2015-12-05 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: This may be related to issue9917. -- ___ Python tracker ___ ___

[issue25764] PyObject_Call() is called with an exception set in subprocess

2015-12-05 Thread Martin Panter
Martin Panter added the comment: I am inclined to just skip the test on OS X, unless some OS X angel wants to help me investigate this :) @skipIf(sys.platform == "darwin", "setrlimit() seems to fail on OS X") -- ___ Python tracker

[issue25764] PyObject_Call() is called with an exception set in subprocess

2015-12-04 Thread Roundup Robot
Roundup Robot added the comment: New changeset 4f4e2cbd2138 by Martin Panter in branch '3.4': Issue #25764: Preserve subprocess fork exception when preexec_fn used https://hg.python.org/cpython/rev/4f4e2cbd2138 New changeset ae27ad306dbf by Martin Panter in branch '3.5': Issue #25764: Merge

[issue25764] PyObject_Call() is called with an exception set in subprocess

2015-12-04 Thread Martin Panter
Martin Panter added the comment: OS X buildbots don’t like my resource change. http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.4/builds/1377/steps/test/logs/stdio It seems that the setrlimit() cleanup line is failing, all the subsequent tests fail to fork(). I don’t understand

[issue25764] PyObject_Call() is called with an exception set in subprocess

2015-12-04 Thread Roundup Robot
Roundup Robot added the comment: New changeset f53958873fae by Martin Panter in branch 'default': Issue #25764: Attempt to debug and skip OS X setrlimit() failure https://hg.python.org/cpython/rev/f53958873fae -- ___ Python tracker

[issue25764] PyObject_Call() is called with an exception set in subprocess

2015-12-04 Thread Roundup Robot
Roundup Robot added the comment: New changeset ccf42cdffc6d by Martin Panter in branch 'default': Issue #25764: OS X now failing on the second setrlimit() call https://hg.python.org/cpython/rev/ccf42cdffc6d -- ___ Python tracker

[issue25764] PyObject_Call() is called with an exception set in subprocess

2015-11-30 Thread Martin Panter
Martin Panter added the comment: This patch fixes the exception when releasing the import lock. I also moved the Py_XDECREF(gc_module) back out to where it was to keep the patch to a minimum, but I don’t really see a way to simplify it much more. Apparently Solaris supports posix_spawn(),

[issue25764] PyObject_Call() is called with an exception set in subprocess

2015-11-29 Thread Serhiy Storchaka
New submission from Serhiy Storchaka: http://buildbot.python.org/all/builders/x86%20OpenIndiana%203.x/builds/10847/steps/test/logs/stdio [117/400] test_subprocess -- running: test_tokenize (65 sec), test_concurrent_futures (38 sec) Assertion failed: !PyErr_Occurred(), file Objects/abstract.c,

[issue25764] PyObject_Call() is called with an exception set in subprocess

2015-11-29 Thread Martin Panter
Martin Panter added the comment: This looks like an intermittent (1 in ~5) failure in at least the Open Indiana 3.5 and 3.x buildbots. My guess is that fork() has failed, and because preexec_fn is in use, the code tries to call gc.enable() with the fork() exception already set. My patch adds