Ned Deily added the comment:
This problem has reappeared on some of the freebsd buildbots, for example:
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%202.7/builds/507
Thanks to a lot of good work by koobs in investigating and documenting the
problems in irc, we have figured out what is going on here (and it's a lot more
difficult to explain than to fix!).
The root cause is that there is a bootstrap issue with the pybuilddir.txt
Makefile rule. This build step is the first step that uses the newly-built
Python executable; it creates the _sysconfigdata.py source that contains the
compiled Makefile variables and it also creates pybuilddir.txt which contains a
platform-dependent build directory name, primarily for the benefit of
cross-compile builds. This support was added by the changes for Issue13150 and
Issue17512. They added code in getpath.c to look for and use the build
directory name from pybuilddir.txt for getpath.c to determine that the
interpreter is being started from a build directory rather than from an
installed instance. In the former case, the code in getpath.c is supposed to
set up both sys.prefix (for pure modules) and sys.exec_prefix (for C extension
modules) so that standard library modules are loaded from the build/source
directories.
However, if pybuilddir.txt does not already exist when the pybuilddir.txt
Makefile rule executes (such as what happens with a clean build directory),
getpath.c gets confused: search_for_prefix correctly determines that python is
running from a build directory but search_for_exec_prefix does not. This means
that the sys.path that is created for this initial run of the newly-built
skeleton python will cause it to find the right pure python modules in the
source/build directories but it will use the installed location (as set by
--prefix, default /usr/local) to search for C standard library shared extension
modules (.so's). Now, at this point, no shared .so's could have been built yet
(in a clean build) and the -m sysconfig --generate-posix-vars step therefore
cannot depend on any such modules. But, if sys.exec_prefix does get set
(incorrectly) to an installed path (because pybuilddir.txt does not exist yet)
*and* there happen to be .so's there from a previous installation, those .so
's can get imported and attempted to be used. One such case in Python 2.7.x
builds is cStringIO.so which is conditionally used by pprint if it is
available, falling back to StringIO.py if not. It so happens that pprint is
used by sysconfig _generate-posix-vars in that build step.
Now it seems that most of the time, the spurious import of incorrect extension
modules at this point is harmless. However, there are configurations where
that is not the case. One such scenario is that of koobs's freebsd buildbot.
In this case, there was already an installed version of Python 2.7 built via
the FreeBSD ports system with --enable-shared, a default prefix of /usr/local,
and with a wide (ucs4) Unicode build. The buildbot is configured non-shared,
with debug enabled, and defaulting to a narrow (ucs2) build and /usr/local
prefix. Even though the buildbot build is never installed, whenever
pybuilddir.txt did not already exist in the build directory (after a manual
clean), getpath's search_for_exec_prefix ended up incorrectly adding
/usr/local/lib/pythonx.x/lib-dynload to sys.path and causing cStringIO.so with
a conflicting build ABI from the installed system Python to be imported and
used, which can be seen in gdb traces to be the cause of the bus error. (With
Python
3.x, there is a different scenario that can result in an installed _heapq.so
being imported but the root cause is the same.)
After finally isolating the scenario, I tried unsuccessfully to reproduce the
bus error on some other platforms (e.g. OS X) but I was able to reproduce it on
a FreeBSD 10 VM. While this may appear to be a rather obscure scenario, there
is at least one other open issue (Issue21412) which seems to be due to the same
root cause so it is definitely worth fixing. Rather than adding to the
complexity of getpath.c, I think the best way to deal with this is in the
Makefile. The attached patches change the pybuilddir.txt rule's recipes to
unconditionally create a pybuilddir.txt with a dummy path value which is
sufficient to ensure that sys.exec_prefix does not point to the installed path
location during this initial step. Further, the patches also cause ./configure
to always delete an existing pybuilddir.txt so that it will be properly
recreated in case the build environment has changed.
I'm cc'ing Matthias here for a review for any cross-compile implications;
AFAICT, there shouldn't be any.
--
components: +Build
keywords: +patch
nosy: +doko, ned.deily
resolution: fixed -
stage: - patch review
status: closed - open
title: Bus error on AMD64 FreeBSD 9.x 3.4 buildbot - Bus error in
pybuilddir.txt 'python -m
