This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author freakboy3742
Recipients bkabrda, doko, freakboy3742, ncoghlan, ned.deily, r.david.murray, rkuska, ronaldoussoren
Date 2015-05-04.07:46:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1430725626.44.0.242746802188.issue23670@psf.upfronthosting.co.za>
In-reply-to
Content
This new patch (20150504.diff) adds support for running the Python test suite The new patch is standalone, and contains everything in the previous patch.

An XCode project (Tools/iOS-test) has been added to the source tree; this project contains bootstrap C code to start and run the full Python regression test suite.

There's also a new target in the iOS/Makefile meta-buildfile - "make test" - which will compile a debug version of the Python framework, and install it into the iOS-test project.

Getting the test suite to run has revealed one major limitation of the iOS platform - system calls like fork, exec*, and spawn* don't work. The OS calls *exist* at an API level - but if you use them, they either crash, or they lock up the device while you wait for a subprocess that will never execute. This makes sense considering the platform itself - there's no such thing as a "background process" in iOS; background tasks are very heavily sandboxed. 

A number of other minor problems have been identified as a result of running the full test suite; they have been addressed in the patch.

The test suite still has 5 failures on the simulator. I'm investigating the cause of these failures.

There's a couple of more failures on a physical device - 13 failures in total. These device-specific failures appear to be largely due to ctypes problems and a permissions issue with os.mkdir. 

If you run the test suite in XCode as a debug binary, the debugger will stop whenever a SIGPIPE, SIGINT, SIGXFSZ, SIGUSR1 or SIGUSR2 signal is raised. You can just hit continue in the debugger, and the test will continue. To work around this, you need to run the following debugger commands before the first signal is raised:

process handle SIGPIPE -n true -p true -s false
process handle SIGINT -n true -p true -s false
process handle SIGXFSZ -n true -p true -s false
process handle SIGUSR1 -n true -p true -s false
process handle SIGUSR2 -n true -p true -s false

I've been doing this by setting a breakpoint in the main.c method; I'm investigating other ways to automate this.
History
Date User Action Args
2015-05-04 07:47:07freakboy3742setrecipients: + freakboy3742, doko, ronaldoussoren, ncoghlan, ned.deily, r.david.murray, bkabrda, rkuska
2015-05-04 07:47:06freakboy3742setmessageid: <1430725626.44.0.242746802188.issue23670@psf.upfronthosting.co.za>
2015-05-04 07:47:06freakboy3742linkissue23670 messages
2015-05-04 07:47:06freakboy3742create