Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

multiprocessing ppc Debian/ ia64 Ubuntu compilation error #47361

Closed
jnoller mannequin opened this issue Jun 14, 2008 · 20 comments
Closed

multiprocessing ppc Debian/ ia64 Ubuntu compilation error #47361

jnoller mannequin opened this issue Jun 14, 2008 · 20 comments
Labels
extension-modules C modules in the Modules dir type-bug An unexpected behavior, bug, or error

Comments

@jnoller
Copy link
Mannequin

jnoller mannequin commented Jun 14, 2008

BPO 3111
Nosy @warsaw, @ncoghlan, @matejcik, @benjaminp, @applio

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2015-03-05.18:12:45.416>
created_at = <Date 2008-06-14.19:46:47.578>
labels = ['extension-modules', 'type-bug']
title = 'multiprocessing ppc Debian/ ia64 Ubuntu compilation error'
updated_at = <Date 2015-03-05.18:12:45.414>
user = 'https://bugs.python.org/jnoller'

bugs.python.org fields:

activity = <Date 2015-03-05.18:12:45.414>
actor = 'davin'
assignee = 'jnoller'
closed = True
closed_date = <Date 2015-03-05.18:12:45.416>
closer = 'davin'
components = ['Extension Modules']
creation = <Date 2008-06-14.19:46:47.578>
creator = 'jnoller'
dependencies = []
files = []
hgrepos = []
issue_num = 3111
keywords = []
message_count = 20.0
messages = ['68211', '68212', '68239', '68328', '68334', '68335', '68338', '68340', '68349', '68350', '68351', '68352', '68353', '68363', '70558', '73206', '73207', '115093', '115940', '237282']
nosy_count = 9.0
nosy_names = ['barry', 'ncoghlan', 'Rhamphoryncus', 'matejcik', 'roudkerk', 'benjamin.peterson', 'jnoller', 'asksol', 'davin']
pr_nums = []
priority = 'normal'
resolution = 'out of date'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue3111'
versions = ['Python 2.6', 'Python 3.0']

@jnoller
Copy link
Mannequin Author

jnoller mannequin commented Jun 14, 2008

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

@jnoller jnoller mannequin added the extension-modules C modules in the Modules dir label Jun 14, 2008
@jnoller jnoller mannequin changed the title multiprocessing pkg Debian compilation error multiprocessing ppc Debian/ ia64 Ubuntu compilation error Jun 14, 2008
@jnoller
Copy link
Mannequin Author

jnoller mannequin commented Jun 14, 2008

Sorry, should have been debian PPC and ubuntu ia64

@jnoller
Copy link
Mannequin Author

jnoller mannequin commented Jun 15, 2008

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?

@jnoller
Copy link
Mannequin Author

jnoller mannequin commented Jun 17, 2008

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?

@Rhamphoryncus
Copy link
Mannequin

Rhamphoryncus mannequin commented Jun 17, 2008

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?

@jnoller
Copy link
Mannequin Author

jnoller mannequin commented Jun 17, 2008

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

@Rhamphoryncus
Copy link
Mannequin

Rhamphoryncus mannequin commented Jun 17, 2008

I agree with your agreement.

@benjaminp
Copy link
Contributor

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?)

@benjaminp
Copy link
Contributor

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

@jnoller
Copy link
Mannequin Author

jnoller mannequin commented Jun 17, 2008

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\>


@benjaminp
Copy link
Contributor

1 for 2. :)

@jnoller
Copy link
Mannequin Author

jnoller mannequin commented Jun 17, 2008

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\>


@benjaminp
Copy link
Contributor

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.

@jnoller
Copy link
Mannequin Author

jnoller mannequin commented Jun 18, 2008

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.

@matejcik
Copy link
Mannequin

matejcik mannequin commented Aug 1, 2008

"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?

@ncoghlan
Copy link
Contributor

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

@ncoghlan
Copy link
Contributor

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)

@BreamoreBoy
Copy link
Mannequin

BreamoreBoy mannequin commented Aug 27, 2010

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.

@BreamoreBoy BreamoreBoy mannequin added the type-bug An unexpected behavior, bug, or error label Aug 27, 2010
@asksol
Copy link
Mannequin

asksol mannequin commented Sep 9, 2010

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

@applio
Copy link
Member

applio commented Mar 5, 2015

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

@applio applio closed this as completed Mar 5, 2015
@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
extension-modules C modules in the Modules dir type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

3 participants