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

test_multiprocessing fails on systems with HAVE_SEM_OPEN=0 #48020

Closed
djmdjm mannequin opened this issue Sep 4, 2008 · 29 comments
Closed

test_multiprocessing fails on systems with HAVE_SEM_OPEN=0 #48020

djmdjm mannequin opened this issue Sep 4, 2008 · 29 comments
Labels
extension-modules

Comments

@djmdjm
Copy link
Mannequin

@djmdjm djmdjm mannequin commented Sep 4, 2008

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']

    @djmdjm
    Copy link
    Mannequin Author

    @djmdjm djmdjm mannequin commented Sep 4, 2008

    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

    @djmdjm djmdjm mannequin added the extension-modules label Sep 4, 2008
    @jnoller
    Copy link
    Mannequin

    @jnoller jnoller mannequin commented Sep 4, 2008

    Which platforms is this appearing on?

    @djmdjm
    Copy link
    Mannequin Author

    @djmdjm djmdjm mannequin commented Sep 4, 2008

    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
    Copy link
    Mannequin

    @aimacintyre aimacintyre mannequin commented Sep 14, 2008

    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
    Copy link
    Mannequin Author

    @djmdjm djmdjm mannequin commented Sep 19, 2008

    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
    Copy link
    Mannequin

    @jnoller jnoller mannequin commented Sep 19, 2008

    Bumping up _ I'll need help with a patch

    @jnoller jnoller mannequin added the release-blocker label Sep 19, 2008
    @ncoghlan
    Copy link
    Contributor

    @ncoghlan ncoghlan commented Sep 27, 2008

    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
    Copy link
    Mannequin Author

    @djmdjm djmdjm mannequin commented Sep 27, 2008

    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
    Copy link
    Contributor

    @ncoghlan ncoghlan commented Sep 28, 2008

    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
    Copy link
    Mannequin

    @aimacintyre aimacintyre mannequin commented Sep 28, 2008

    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
    Copy link
    Mannequin

    @aimacintyre aimacintyre mannequin commented Sep 28, 2008

    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
    Copy link
    Mannequin

    @jnoller jnoller mannequin commented Sep 28, 2008

    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?

    @brettcannon
    Copy link
    Member

    @brettcannon brettcannon commented Sep 29, 2008

    Well, even if 2.6 slipped (which it is looking probably won't happen),
    how much time would you need to deal with this? Sounds like you just
    won't be able to get to it even with an extra week. So that means
    multiprocessing is just not supported on FreeBSD and OpenBSD at this
    moment. Sucks, but hopefully it can get fixed in the future. And if
    people complain, bug them to get a reliable buildbot going.

    @ncoghlan
    Copy link
    Contributor

    @ncoghlan ncoghlan commented Sep 29, 2008

    Agreed - Jesse, can you work up a patch that generates a clean import
    error when _multiprocessing.SemLock can't be defined (due to
    HAVE_SEM_OPEN=0 or a single-threaded build), adds test_multiprocessing
    to the expected skips for FreeBSD and OpenBSD, and updates the
    multiprocessing docs to note the restriction to systems with a working
    sem_open() implementation?

    Improving the *BSD and single-threaded build compatibility of the
    multiprocessing package will just have to be high on the to-do list for
    2.6.1.

    This may also be worth mentioning in the release notes - Barry's call on
    that one.

    @jnoller
    Copy link
    Mannequin

    @jnoller jnoller mannequin commented Sep 29, 2008

    Hows this error look:

    >>> import multiprocessing
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/Users/jesse/open_source/subversion/python-
    trunk/Lib/multiprocessing/__init__.py", line 178, in <module>
        " function, see issue 3770.")
    multiprocessing.SemaphoreImportError: This platform lacks a functioning 
    sem_open implementation and thereforce, the required synchronization 
    primitives needed will not function, see issue 3770.
    >>>

    @djmdjm
    Copy link
    Mannequin Author

    @djmdjm djmdjm mannequin commented Sep 29, 2008

    looks good to me

    @brettcannon
    Copy link
    Member

    @brettcannon brettcannon commented Sep 29, 2008

    On Mon, Sep 29, 2008 at 11:20 AM, Jesse Noller <report@bugs.python.org> wrote:
    >
    > Jesse Noller <jnoller@gmail.com> added the comment:
    >
    > Hows this error look:
    >
    >>>> import multiprocessing
    > Traceback (most recent call last):
    >  File "<stdin>", line 1, in <module>
    >  File "/Users/jesse/open_source/subversion/python-
    > trunk/Lib/multiprocessing/__init__.py", line 178, in <module>
    >    " function, see issue 3770.")
    > multiprocessing.SemaphoreImportError: This platform lacks a functioning
    > sem_open implementation and thereforce, the required synchronization
    > primitives needed will not function, see issue 3770.

    Is "thereforce" an actual word? Otherwise it looks fine to me.

    @jnoller
    Copy link
    Mannequin

    @jnoller jnoller mannequin commented Sep 29, 2008

    Is "thereforce" an actual word? Otherwise it looks fine to me.

    Yeah, I caught that. Rather than disable the entire package, which
    would be frustrating to many - I've changed it to only disable
    mp.synchronize for now, patch is pending my final build and test/doc
    check locally

    @jnoller
    Copy link
    Mannequin

    @jnoller jnoller mannequin commented Sep 29, 2008

    Here's a patch, works on my machine. Please review it and make sure it
    satisfies what we've spoken about.

    @ncoghlan
    Copy link
    Contributor

    @ncoghlan ncoghlan commented Sep 29, 2008

    Could use confirmation from Damien and Andrew that they now see the
    expected skips with the patch applied, but otherwise looks good to me.

    @djmdjm
    Copy link
    Mannequin Author

    @djmdjm djmdjm mannequin commented Sep 29, 2008

    I can confirm that the patch works on OpenBSD -current. Only one nit:

    Does this line in Lib/test/test_multiprocessing.py need to be there?

    +#import multiprocessing.SemaphoreImportError

    @jnoller
    Copy link
    Mannequin

    @jnoller jnoller mannequin commented Sep 29, 2008

    On Sep 29, 2008, at 6:36 PM, Damien Miller <report@bugs.python.org>
    wrote:

    Damien Miller <djmdjm@users.sourceforge.net> added the comment:

    I can confirm that the patch works on OpenBSD -current. Only one nit:

    Does this line in Lib/test/test_multiprocessing.py need to be there?

    +#import multiprocessing.SemaphoreImportError

    Oops - my bad. I'll remove it and check it tonight

    @jnoller
    Copy link
    Mannequin

    @jnoller jnoller mannequin commented Sep 30, 2008

    checked in r66688, lowering from rb to crit to address post 2.6 final

    @jnoller jnoller mannequin removed the release-blocker label Sep 30, 2008
    @aimacintyre
    Copy link
    Mannequin

    @aimacintyre aimacintyre mannequin commented Sep 30, 2008

    The checked in change has the planned effect on FreeBSD 6.3 i386. I
    can't check on my 7.0 amd64 box as I can't quickly put a current source
    tree on it.

    @bms
    Copy link
    Mannequin

    @bms bms mannequin commented Mar 12, 2009

    POSIX semaphores should be fixed in 8-CURRENT, pending MFC.

    There are rtld + malloc issues in FreeBSD. Python multiprocessing's
    use of POSIX threads is not strictly POSIX compliant, as it tries
    to do a lot more than just call exec() or async-signal-safe POSIX
    APIs after fork()-ing. There is a degree of reluctance in the camp
    to fix for these reasons...

    In the meantime, you may wish to try building Python 2.6 on FreeBSD
    using GNU Pth, here is a patch:

    http://people.freebsd.org/~bms/dump/python26-fbsd-pth.patch

    thanks!
    BMS

    @jnoller
    Copy link
    Mannequin

    @jnoller jnoller mannequin commented Mar 30, 2009

    Sorry, I hit the wrong bug

    @jnoller
    Copy link
    Mannequin

    @jnoller jnoller mannequin commented Apr 2, 2009

    Closing; we've removed hard-coded platform variables for a better autoconf
    approach. We currently skip the test suite on platforms which don't
    support or have what we need.

    @jnoller jnoller mannequin closed this as completed Apr 2, 2009
    @smattr
    Copy link
    Mannequin

    @smattr smattr mannequin commented Jan 20, 2020

    I'm trying to follow the history of this issue, as it does not seem fully resolved to me. While trying to package something for Debian, one of the buildd 0 logs for hurd-i386 points to this issue as the cause of a failure 1. This occurs with Python 3.7, though Debian's Python 3.7 may involve some distro patches on top of upstream source. If the build log is inaccessible or incomprehensible, the relevant sections are:

        ...
        The following additional packages will be installed:
        ... libpython3-stdlib libpython3.7-minimal libpython3.7-stdlib ... python3 python3-minimal python3.7 python3.7-minimal
        ...
        /usr/bin/ctest --force-new-ctest-process -j1
        Test project /<<PKGBUILDDIR>>/obj-i686-gnu
            Start 1: tests
        1/1 Test #1: tests ............................***Failed    0.10 sec
        Traceback (most recent call last):
          File "/usr/lib/python3.7/multiprocessing/synchronize.py", line 28, in <module>
            from _multiprocessing import SemLock, sem_unlink
        ImportError: cannot import name 'SemLock' from '_multiprocessing' (/usr/lib/python3.7/lib-dynload/_multiprocessing.cpython-37m-i386-gnu.so)
    
        During handling of the above exception, another exception occurred:
    
        Traceback (most recent call last):
          File "/<<PKGBUILDDIR>>/tests/run-tests.py", line 46, in <module>
            print_lock = multiprocessing.Lock()
          File "/usr/lib/python3.7/multiprocessing/context.py", line 66, in Lock
            from .synchronize import Lock
          File "/usr/lib/python3.7/multiprocessing/synchronize.py", line 32, in <module>
            " synchronization primitives needed will not" +
        ImportError: This platform lacks a functioning sem_open implementation, therefore, the required synchronization primitives needed will not function, see issue 3770.

    Do you know what is happening here? Maybe the compounded ImportError I'm seeing *was* the resolution referred to in prior comments, but if so it seems strange to reference this issue in the error message.

    The hurd-i386 platform is not a priority for me, so if the answer is "multiprocessing doesn't work there" I am perfectly OK with this. Also I realise I am asking you to recall >10 year old memories so I apologise in advance for any re-opened wounds.

    If you need to see the source for what buildd is actually testing here, it's the debian/v2020.11.01-1 tag of 2.

    @ned-deily
    Copy link
    Member

    @ned-deily ned-deily commented Jan 20, 2020

    Matthew, this tracker issue has been closed for over 10 years; posting new questions or comments to such is unlikely to get a response (I just happened to see your comment in passing). If you believe you have identified a new issue with current versions of Python, you should search for newer issues and, if appropriate, open a new one with a reference to this one. However, before doing that, I would do a web search on "cannot import name 'SemLock'"; you should find a number of references to situations that seem similar to yours with the cause being the lack of a working sem_open implementation as noted in the ImportError message, a condition that might just be a system configuration issue on the build system. Good luck!

    @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
    Projects
    None yet
    Development

    No branches or pull requests

    3 participants