Both debian ia64 and PPC are failing the mp test suite with the following error: Re-running test 'test_multiprocessing' in verbose mode test test_multiprocessing crashed -- <type 'exceptions.OSError'>: [Errno 38] Function not implemented Traceback (most recent call last): File "./Lib/test/regrtest.py", line 554, in runtest_inner indirect_test() File "/home/pybot/buildarea/trunk.klose-debian- ppc/build/Lib/test/test_multiprocessing.py", line 1764, in test_main ProcessesMixin.pool = multiprocessing.Pool(4) File "/home/pybot/buildarea/trunk.klose-debian- ppc/build/Lib/multiprocessing/__init__.py", line 226, in Pool return Pool(processes, initializer, initargs) File "/home/pybot/buildarea/trunk.klose-debian- ppc/build/Lib/multiprocessing/pool.py", line 84, in __init__ self._setup_queues() File "/home/pybot/buildarea/trunk.klose-debian- ppc/build/Lib/multiprocessing/pool.py", line 131, in _setup_queues self._inqueue = SimpleQueue() File "/home/pybot/buildarea/trunk.klose-debian- ppc/build/Lib/multiprocessing/queues.py", line 315, in __init__ self._rlock = Lock() File "/home/pybot/buildarea/trunk.klose-debian- ppc/build/Lib/multiprocessing/synchronize.py", line 106, in __init__ SemLock.__init__(self, SEMAPHORE, 1, 1) File "/home/pybot/buildarea/trunk.klose-debian- ppc/build/Lib/multiprocessing/synchronize.py", line 38, in __init__ sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) OSError: [Errno 38] Function not implemented [674193 refs] make: *** [buildbottest] Error 1 program finished with exit code 2 Buildbots: http://www.python.org/dev/buildbot/stable/ppc%20Debian%20unstable%20trun k/builds/1607/step-test/0 http://www.python.org/dev/buildbot/stable/ia64%20Ubuntu%20trunk/builds/1 89/step-test/0

Sorry, should have been debian PPC and ubuntu ia64

This is also effecting gentoo x86. After speaking with Richard, he suggested that this could be a side-effect if the buildbot execution is happening in a chroot'ed environment. Barry, do you know if this is the case?

I believe this is a Linux-specific problem relating to chroot jails missing the /dev/shm filesystem. I am suggesting we skip the test for now if /dev/shm does not exist, via: if (sys.platform.startswith("linux"): if not os.path.exists("/dev/shm"): raise TestSkipped("Missing required /dev/shm device on Linux!") at the top of test_multiprocessing.py Anyone see a problem with this?

I don't see a problem with skipping it, but if chroot is the problem, maybe the chroot environment should be fixed to include /dev/shm?

I agree, fixing the chroot is the long-term solution, however this gets us over the beta hump

I agree with your agreement.

Jesse, I say go ahead and make it so. I think you should make another report thought to keep track of getting /dev/shm in the buildbot enviroment. (Is that a buildbot bug?)

I committed the skip in r64356. Let's sit back and watch.

Did you add the import and fix the syntax error On Jun 17, 2008, at 6:44 PM, Benjamin Peterson <report@bugs.python.org> wrote: > > Benjamin Peterson <musiccomposition@gmail.com> added the comment: > > I committed the skip in r64356. Let's sit back and watch. > > _______________________________________ > Python tracker <report@bugs.python.org> > <http://bugs.python.org/issue3111> > _______________________________________

1 for 2. :)

I apologize, I should have just posted the diff On Jun 17, 2008, at 7:00 PM, Benjamin Peterson <report@bugs.python.org> wrote: > > Benjamin Peterson <musiccomposition@gmail.com> added the comment: > > 1 for 2. :) > > _______________________________________ > Python tracker <report@bugs.python.org> > <http://bugs.python.org/issue3111> > _______________________________________

On Tue, Jun 17, 2008 at 6:08 PM, Jesse Noller <report@bugs.python.org> wrote: > > Jesse Noller <jnoller@gmail.com> added the comment: > > I apologize, I should have just posted the diff It's not your fault. I'm impatient.

I switched to a more aggressive skip as it doesn't seem /dev/shm is the culprit (at least from overnight runs). I committed it in r64375 on trunk and I am going to wait for the build bots to run on trunk before merging.

> "as it doesn't seem /dev/shm is the culprit" Mounting /dev/shm seems to fix the problem in suse's autobuild (chroot) environment, so for me it actually was the culprit. Perhaps you should recheck your buildbots?

Setting this to a release blocker, because it is affecting Neal's automated execution of the regression test suite with a debug build.

Scratch that - it's more likely to be Neal's setup which is at fault, which I will be questioning on python-dev shortly (there are 3 other tests which are failing/getting skipped in Neal's regression test suite)

Can this be closed as it looks to me like a 2 year old test error and not an extension module error, am I correct? Refer to msg68349 and msg68363.

As no one is able to confirm that this is still an issue, I'm closing it. It can be reopened if necessary.

Doing cleanup: This was marked as out of date in 2010 but somehow escaped being marked closed. Closing now.