test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[djmdjm]

BPO	3770
Nosy	@ncoghlan, @ned-deily, @pmp-p, @Smattr
Files	issue3770.diff: Disable synchronize module on sem_open lacking systems

^{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 2009-04-02.03:57:50.525>
created_at = <Date 2008-09-04.00:23:58.140>
labels = ['extension-modules']
title = 'test_multiprocessing fails on systems with HAVE_SEM_OPEN=0'
updated_at = <Date 2020-12-07.23:09:56.647>
user = 'https://bugs.python.org/djmdjm'

bugs.python.org fields:

activity = <Date 2020-12-07.23:09:56.647>
actor = 'pmpp'
assignee = 'jnoller'
closed = True
closed_date = <Date 2009-04-02.03:57:50.525>
closer = 'jnoller'
components = ['Extension Modules']
creation = <Date 2008-09-04.00:23:58.140>
creator = 'djmdjm'
dependencies = []
files = ['11656']
hgrepos = []
issue_num = 3770
keywords = ['patch', 'needs review']
message_count = 29.0
messages = ['72442', '72450', '72455', '73221', '73440', '73442', '73918', '73948', '73957', '73958', '73959', '73993', '74005', '74015', '74036', '74037', '74040', '74041', '74043', '74045', '74054', '74055', '74057', '74077', '83495', '84610', '85155', '360288', '360339']
nosy_count = 8.0
nosy_names = ['aimacintyre', 'ncoghlan', 'djmdjm', 'ned.deily', 'jnoller', 'bms', 'pmpp', 'smattr']
pr_nums = []
priority = 'critical'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue3770'
versions = ['Python 2.6', 'Python 3.0']

Linked PRs

• gh-48020: [docs] Remove the logging howto suggested future FileHandler multiprocessing support #126531
• [3.13] gh-48020: [docs] Remove the logging howto suggested future FileHandler multiprocessing support (GH-126531) #126540

[djmdjm]

test_multiprocessing crashes on platforms that lack a working
sem_open(), despite it being turned off at compilation time by setting
HAVE_SEM_OPEN=0 in the Extension macros in setup.py

I think the multiprocessing module should disable the functionality
gracefully when it is missing from _multiprocessing.

Failure message:

test test_multiprocessing crashed -- <type 'exceptions.AttributeError'>:
'module' object has no attribute 'SemLock'
Traceback (most recent call last):
  File ".//Lib/test/regrtest.py", line 556, in runtest_inner
    indirect_test()
  File
"/usr/ports/lang/python/2.6/w-Python-2.6b3/Python-2.6b3/Lib/test/test_multiprocessing.py",
line 1758, in test_main
    ProcessesMixin.pool = multiprocessing.Pool(4)
  File
"/usr/ports/lang/python/2.6/w-Python-2.6b3/Python-2.6b3/Lib/multiprocessing/__init__.py",
line 226, in Pool
    return Pool(processes, initializer, initargs)
  File
"/usr/ports/lang/python/2.6/w-Python-2.6b3/Python-2.6b3/Lib/multiprocessing/pool.py",
line 84, in __init__
    self._setup_queues()
  File
"/usr/ports/lang/python/2.6/w-Python-2.6b3/Python-2.6b3/Lib/multiprocessing/pool.py",
line 130, in _setup_queues
    from .queues import SimpleQueue
  File
"/usr/ports/lang/python/2.6/w-Python-2.6b3/Python-2.6b3/Lib/multiprocessing/queues.py",
line 22, in <module>
    from multiprocessing.synchronize import Lock, BoundedSemaphore,
Semaphore, Condition
  File
"/usr/ports/lang/python/2.6/w-Python-2.6b3/Python-2.6b3/Lib/multiprocessing/synchronize.py",
line 29, in <module>
    SEM_VALUE_MAX = _multiprocessing.SemLock.SEM_VALUE_MAX
AttributeError: 'module' object has no attribute 'SemLock'
1 test failed:
    test_multiprocessing

[jnoller]

Which platforms is this appearing on?

[djmdjm]

On Thu, 4 Sep 2008, Jesse Noller wrote:

Jesse Noller <jnoller@gmail.com> added the comment:

Which platforms is this appearing on?

OpenBSD, with this section added to setup.py:

@@ -1269,6 +1268,14 @@ class PyBuildExt(build_ext):
)
libraries = []

+ elif platform.startswith('openbsd'):
+ macros = dict( # OpenBSD
+ HAVE_SEM_OPEN=0, # Not implemented
+ HAVE_SEM_TIMEDWAIT=0,
+ HAVE_FD_TRANSFER=1,
+ )
+ libraries = []
+
else: # Linux and other unices
macros = dict(
HAVE_SEM_OPEN=1,

[aimacintyre]

2.6rc1 shows the same failure traceback on FreeBSD 6.3, which is covered
by a section of setup.py the same as Damien added for OpenBSD.

[djmdjm]

So the bug is actually in the multiprocessing module rather than the
unittest. If HAVE_SEM_OPEN is not defined then SemLock is never
built into _multiprocessing.so, but multiprocessing/syncronize.py
unconditionally depends on its presence.

I guess _multiprocessing could always define a dummy SemLock or
synchronize.py could check before it depends on it.

(it would be great to see this fixed for 2.6)

-d

[jnoller]

Bumping up _ I'll need help with a patch

[ncoghlan]

Looking at mp.synchronize, the whole module really does depend on a
working _multiprocessing.SemLock instance. If these platforms don't have
a native semaphore implementation, what is their basic inter-process
synchronisation primitive?

Once that is identified, then it should be possible to code either a C
or Python semaphore implementation based on that primitive.

[djmdjm]

For 2.6/3.0 it would probably be best to just disable the module
entirely on platforms that lack shareable semaphores (OpenBSD & FreeBSD
at least)

[ncoghlan]

Jesse, how much (if any) of the rest of the package will work without
the synchronize module? If it isn't a lot, then it may be a matter of
just making this a cleaner ImportError and an expected test suite skip
on OpenBSD and FreeBSD.

(Unfortunately, our OpenBSD and FreeBSD buildbots are so unreliable that
they don't get much attention when they go red - it looks to me like the
OpenBSD buildbot isn't even managing to build _multiprocessing at the
moment, because HAVE_SEM_OPEN is incorrectly set to 1).

[aimacintyre]

I've done some more digging into this for the FreeBSD case.

FreeBSD 6.3 and 7.0 both have sem_open, and the man pages suggest it
should be fully functional. (see
http://www.freebsd.org/cgi/man.cgi?query=sem_open&apropos=0&sektion=0&manpath=FreeBSD+6.3-RELEASE&format=html)
There is a caveat on the length of the name, which I think could trigger
if the counter variable passed into SEM_CREATE() is >9999. But as that
variable seems like it can only ever be 0 (not sure this is intended!)
this shouldn't happen as it stands.

If I change HAVE_SEM_OPEN to 1 in setup.py, the _multiprocessing module
builds, but test_multiprocessing provokes a core dump in both cases.
The backtrace (on 6.3 i386) looks like:
#0 0x2820ef17 in ksem_open () from /lib/libc.so.6
#1 0x2820592c in sem_open () from /lib/libc.so.6
#2 0x284494a0 in semlock_new (type=0x2844b380, args=0x836443c, kwds=0x0)
at
/home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c:439
#3 0x0809e710 in type_call (type=0x2844b380, args=0x836443c, kwds=0x0)
at Objects/typeobject.c:731
#4 0x0806042a in PyObject_Call (func=0x2844b380, arg=0x836443c, kw=0x0)
at Objects/abstract.c:2487
#5 0x080cc367 in PyEval_EvalFrameEx (f=0x84dd00c, throwflag=0)
at Python/ceval.c:3890
#6 0x080cf9ac in PyEval_EvalCodeEx (co=0x8478800, globals=0x4e,
locals=0xa00,
args=0x819b02c, argcount=4, kws=0x0, kwcount=0, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2942
#7 0x08123f84 in function_call (func=0x8486ca4, arg=0x82e107c, kw=0x0)
at Objects/funcobject.c:524
#8 0x0806042a in PyObject_Call (func=0x8486ca4, arg=0x82e107c, kw=0x0)
at Objects/abstract.c:2487
#9 0x08069c15 in instancemethod_call (func=0x4e, arg=0x82e107c, kw=0x0)
at Objects/classobject.c:2579
#10 0x0806042a in PyObject_Call (func=0x84857ac, arg=0x82e107c, kw=0x0)
at Objects/abstract.c:2487
#11 0x080cc367 in PyEval_EvalFrameEx (f=0x826140c, throwflag=0)
at Python/ceval.c:3890
---Type <return> to continue, or q <return> to quit---

On 7.0 amd64, the top of the backtrace scrolls off screen so I can't get
the start of the trace (X not installed...).

To try and remove threads from the equation, due to FreeBSD 6.3 having
an issue with fork() in a threaded build (see bpo-3864 for more info),
I configured without threads (ie ./configure --without-threads) and
the _multiprocessing module fails to build:

gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3
-Wall-Wstrict-prototypes -DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1
-DHAVE_SEM_TIMEDWAIT=0 -IModules/_multiprocessing -I.
-I/home/andymac/build/python-svn/trunk-r66550/./Include -I. -IInclude
-I./Include -I/usr/local/include
-I/home/andymac/build/python-svn/trunk-r66550/Include
-I/home/andymac/build/python-svn/trunk-r66550 -c
/home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c
-o
build/temp.freebsd-6.3-RELEASE-i386-2.6/home/andymac/build/python-svn/trunk-r66550/Modules/_mult
iprocessing/semaphore.o
/home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c:
In function semlock_acquire': /home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c:314: error: _save' undeclared (first use in this function)
/home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c:314:
error: (Each undeclared identifier is reported only once
/home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c:314:
error: for each function it appears in.)

It appears that some support is there for a single threaded build, but
is incomplete (there's a similar problem in socket_connections.c, but
the module build bails before then).

If its not to be supported on single threaded builds (which would be a
big shame in my opinion!) then the code should make this explicit,
otherwise the single threaded build case needs to be fixed.

I'm still trying to understand the core dump in the multithreaded build

• unfortunately I'm not terribly familiar with gdb or with debugging
  from cores (and the actual failure appears to be triggering in the C
  library for which I currently don't appear to have symbols...)

Any suggests on how/where to dig further on this?

[aimacintyre]

Oops - meant to add that the actual reported cause of the core dump is
"Bad system call".

Also, the OpenBSD man pages make clear that shared semaphores aren't
supported and sem_open() doesn't exist:
http://www.openbsd.org/cgi-bin/man.cgi?query=sem_open&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

[jnoller]

I've been thinking about this - Right now, having a working mp.synchronize
module, and thread support is key to package currently. For 2.6 - it's
really too late to try to mock up a working mp.synchronize module, or
significantly change the package.

My recommendation (I'm going to work on a patch to do this) is to not
support fbsd/openbsd in this release cycle, which is unfortunate. Any
other thoughts?