_multiprocessing.so build problems

[warsaw]

BPO	3375
Nosy	@gvanrossum, @warsaw, @pitrou
Dependencies	bpo-3088: test_multiprocessing hangs intermittently on POSIX platforms
Files	make-d.log.bz2 3375.txt

^{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 = 'https://github.com/gvanrossum'
closed_at = <Date 2008-07-17.16:26:12.829>
created_at = <Date 2008-07-16.12:57:15.517>
labels = ['build', 'release-blocker']
title = '_multiprocessing.so build problems'
updated_at = <Date 2008-07-17.16:26:12.828>
user = 'https://github.com/warsaw'

bugs.python.org fields:

activity = <Date 2008-07-17.16:26:12.828>
actor = 'gvanrossum'
assignee = 'gvanrossum'
closed = True
closed_date = <Date 2008-07-17.16:26:12.829>
closer = 'gvanrossum'
components = ['Build']
creation = <Date 2008-07-16.12:57:15.517>
creator = 'barry'
dependencies = ['3088']
files = ['10907', '10915']
hgrepos = []
issue_num = 3375
keywords = []
message_count = 14.0
messages = ['69777', '69778', '69781', '69789', '69800', '69801', '69802', '69804', '69833', '69869', '69870', '69872', '69882', '69886']
nosy_count = 5.0
nosy_names = ['gvanrossum', 'barry', 'pitrou', 'jnoller', 'mishok13']
pr_nums = []
priority = 'release blocker'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue3375'
versions = ['Python 3.0']

[warsaw]

_multiprocessing.so has build problems on both OS X 10.5 and Ubuntu
Linux 8.04. It's very strange though because there are no apparent
errors in compilation, however when the build process tries to import
the module, that fails and it gets moved to _multiprocessing_failed.so.
Interestingly enough, a subsequent 'make' succeeds, as does just
renaming the lib back to _multiprocessing.so.

Sorry, I have no more clues than that, but see also but 3088.

[warsaw]

Er, make that bug 3088

[jnoller]

I'll try with a clean tree, but I've seen this before and I'm quite
mystified.

[jnoller]

Barry, I can't seem to repro this against trunk on both my Ubuntu and OS/X
machines. If you get a chance, can you see if you can get the output from
a make -d?

[mishok13]

Attached the log of 'make -d' on clean checkout of py3k branch. This is
on Ubuntu 8.04.1.

[jnoller]

Andrii gave me make -d output with the failure:

building '_multiprocessing' extension
creating build/temp.linux-i686-
3.0/home/mishok/doc/python/tmp/py3k/Modules/_multiprocessing
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -
Wstrict-prototypes -DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1 -
DHAVE_SEM_TIMEDWAIT=1 -IModules/_multiprocessing -I. -
I/home/mishok/doc/python/tmp/py3k/./Include -I. -IInclude -I./Include -
I/usr/local/include -I/home/mishok/doc/python/tmp/py3k/Include -
I/home/mishok/doc/python/tmp/py3k -c
/home/mishok/doc/python/tmp/py3k/Modules/_multiprocessing/multiprocessin
g.c -o build/temp.linux-i686-
3.0/home/mishok/doc/python/tmp/py3k/Modules/_multiprocessing/multiproces
sing.o
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -
Wstrict-prototypes -DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1 -
DHAVE_SEM_TIMEDWAIT=1 -IModules/_multiprocessing -I. -
I/home/mishok/doc/python/tmp/py3k/./Include -I. -IInclude -I./Include -
I/usr/local/include -I/home/mishok/doc/python/tmp/py3k/Include -
I/home/mishok/doc/python/tmp/py3k -c
/home/mishok/doc/python/tmp/py3k/Modules/_multiprocessing/socket_connect
ion.c -o build/temp.linux-i686-
3.0/home/mishok/doc/python/tmp/py3k/Modules/_multiprocessing/socket_conn
ection.o
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -
Wstrict-prototypes -DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1 -
DHAVE_SEM_TIMEDWAIT=1 -IModules/_multiprocessing -I. -
I/home/mishok/doc/python/tmp/py3k/./Include -I. -IInclude -I./Include -
I/usr/local/include -I/home/mishok/doc/python/tmp/py3k/Include -
I/home/mishok/doc/python/tmp/py3k -c
/home/mishok/doc/python/tmp/py3k/Modules/_multiprocessing/semaphore.c -o
build/temp.linux-i686-
3.0/home/mishok/doc/python/tmp/py3k/Modules/_multiprocessing/semaphore.o
gcc -pthread -shared build/temp.linux-i686-
3.0/home/mishok/doc/python/tmp/py3k/Modules/_multiprocessing/multiproces
sing.o build/temp.linux-i686-
3.0/home/mishok/doc/python/tmp/py3k/Modules/_multiprocessing/socket_conn
ection.o build/temp.linux-i686-
3.0/home/mishok/doc/python/tmp/py3k/Modules/_multiprocessing/semaphore.o
-L/usr/local/lib -o build/lib.linux-i686-3.0/_multiprocessing.so
*** WARNING: renaming "_multiprocessing" since importing it failed: No
module named _multiprocessing

[jnoller]

Even with that output it's not clear what's happening during the compile
step. Barry - is this on trunk and py3k?

[warsaw]

py3k. i think the thing to do is to try to figure out why the import is
failing even though the compilation appears to succeed. it's the
suppressed import error that's going to be the clue.

[warsaw]

Okay, I have more information, but still no diagnosis. I stuck a
'raise' in the setup.py so that when the ImportError occurs, it doesn't
get swallowed. Instead it stops the build process in its tracks. The
attached file contains the relevant output.

[gvanrossum]

When a second 'make' fixes things, that usually means that there's a
dependency on another extension that is built later in the normal build
sequence. I vaguely we had this before and fixed it by reordering things.

Grepping the sources of _multiprocessing for Import, I wonder if it
could be _pickle? Or something that _pickle imports? (Since _pickle
seems to be built before _multiprocessing.)

[gvanrossum]

Here is the output of python -v during "import _multiprocessing". Maybe
this gives someone a clue?

>>> import _multiprocessing
dlopen("/Users/guido/p3/build/lib.macosx-10.3-i386-3.0/_multiprocessing.so",
2);
# /Users/guido/p3/Lib/pickle.pyc matches /Users/guido/p3/Lib/pickle.py
import pickle # precompiled from /Users/guido/p3/Lib/pickle.pyc
import marshal # builtin
# /Users/guido/p3/Lib/struct.pyc matches /Users/guido/p3/Lib/struct.py
import struct # precompiled from /Users/guido/p3/Lib/struct.pyc
dlopen("/Users/guido/p3/build/lib.macosx-10.3-i386-3.0/_struct.so", 2);
import _struct # dynamically loaded from
/Users/guido/p3/build/lib.macosx-10.3-i386-3.0/_struct.so
dlopen("/Users/guido/p3/build/lib.macosx-10.3-i386-3.0/binascii.so", 2);
import binascii # dynamically loaded from
/Users/guido/p3/build/lib.macosx-10.3-i386-3.0/binascii.so
dlopen("/Users/guido/p3/build/lib.macosx-10.3-i386-3.0/_pickle.so", 2);
import _pickle # dynamically loaded from
/Users/guido/p3/build/lib.macosx-10.3-i386-3.0/_pickle.so
import multiprocessing # directory /Users/guido/p3/Lib/multiprocessing
# /Users/guido/p3/Lib/multiprocessing/__init__.pyc matches
/Users/guido/p3/Lib/multiprocessing/__init__.py
import multiprocessing # precompiled from
/Users/guido/p3/Lib/multiprocessing/__init__.pyc
# /Users/guido/p3/Lib/multiprocessing/process.pyc matches
/Users/guido/p3/Lib/multiprocessing/process.py
import multiprocessing.process # precompiled from
/Users/guido/p3/Lib/multiprocessing/process.pyc
dlopen("/Users/guido/p3/build/lib.macosx-10.3-i386-3.0/itertools.so", 2);
import itertools # dynamically loaded from
/Users/guido/p3/build/lib.macosx-10.3-i386-3.0/itertools.so
import _multiprocessing # dynamically loaded from
/Users/guido/p3/build/lib.macosx-10.3-i386-3.0/_multiprocessing.so
import _multiprocessing # dynamically loaded from
/Users/guido/p3/build/lib.macosx-10.3-i386-3.0/_multiprocessing.so
>>>

[gvanrossum]

The order thing was a red herring. However, I understand what's going
on now. Somebody else can fix it hopefully.

So what's going on: In the Python instance that runs setup.py,
importing _multiprocessing fails. But if I start a new Python instance
in exactly the same environment, it works. Why? Because at the *start*
of running setup.py, the directory .../build/lib.macosx-10.3-i386-3.0
doesn't exist, and this is being cached in sys.path_importer_cache,
which has a NullImporter instance for that key. Maybe the solution is
to remove that cache entry (if it exists) in the code that creates that
directory?

I found this by (a) disabling the two except clauses in setup.py that
catch exceptions from the attempt to import the module that was just
built, and (b) adding a -i flag to the Python instance invoked by the
Makefile to run setup.py. This gave me an interactive interpreter at
the moment the "import _multiprocessing" failed. Poking around I could
see that sys.path_importer_cache had a NullImporter instance for the
directory from which _multiprocessing.so was to be imported. I could
even delete that cache entry, and then the import would pass!

Good luck fixing...

[pitrou]

How about simply doing sys.path_importer_cache.clear() at the right
point in setup.py? I don't think the performance loss would be
overwhelming...

[gvanrossum]

I've checked in a fix (r65063) that simply clear sys.path_importer_cache
right before the attempted import of the freshly-built extension. This
seems to work.