Various platforms have various methods of handling multiarch libffi which probably won't match the previously looked-for defines. Now we just make sure that ffi.h is available.
Add basic fuzz tests for a few common builtin functions.
This is an easy place to start, and these functions are probably safe.
We'll want to add more fuzz tests later. Lets bootstrap using these.
While the fuzz tests are included in CPython and compiled / tested on a
very basic level inside CPython itself, the actual fuzzing happens as
part of oss-fuzz (https://github.com/google/oss-fuzz). The reason to
include the tests in CPython is to make sure that they're maintained
as part of the CPython project, especially when (as some eventually
will) they use internal implementation details in the test.
(This will be necessary sometimes because e.g. the fuzz test should
never enter Python's interpreter loop, whereas some APIs only expose
themselves publicly as Python functions.)
This particular set of changes is part of testing Python's builtins,
tracked internally at Google by b/37562550.
The _xxtestfuzz module that this change adds need not be shipped with binary distributions of Python.
As of Xcode 7, SDKs for Apple platforms now include textual-format stub
libraries whose file names have a .tbd extension rather than the
standard OS X .dylib extension. The Apple compiler tool chain handles
these stub libraries transparently and the installed system shared libraries
are still .dylibs. However, the new stub libraries cause problems for
third-party programs that support building with Apple SDKs and make
build-time decisions based on the presence or paths of system-supplied
shared libraries in the SDK. In particular, building Python itself with
an SDK fails to find system-supplied libraries during setup.py's build of
standard library extension modules. The solution is to have
find_library_file() in Distutils search for .tbd files, along with
the existing types (.a, .so, and .dylib). Patch by Tim Smith.
Known limitations of the current implementation:
- documentation changes are incomplete
- there's a reference leak I haven't tracked down yet
The leak is most visible by running:
./python -m test -R3:3 test_importlib
However, you can also see it by running:
./python -X showrefcount
Importing the array or _testmultiphase modules, and
then deleting them from both sys.modules and the local
namespace shows significant increases in the total
number of active references each cycle. By contrast,
with _testcapi (which continues to use single-phase
initialisation) the global refcounts stabilise after
a couple of cycles.
Antoine Pitrou
Shlomi Fish
Devin Jeanpierre
Stefan Krah
Victor Stinner
xdegaye
Neil Schemenauer
Xavier de Gaye
INADA Naoki
Christian Heimes
Zachary Ware
Benjamin Peterson
R David Murray
Vinay Sajip
doko@ubuntu.com
Martin Panter
Ned Deily
Serhiy Storchaka
Nick Coghlan
Berker Peksag