to guess /which/ line the spawned thread is in at the time
sys._current_frames() is called: we know it finished
enter_g.set(), but can't know whether the instruction
counter has advanced to the following leave_g.wait().
The latter is overwhelming most likely, but not guaranteed,
and I see that the "x86 Ubuntu dapper (icc) trunk" buildbot
found it on the other line once. Changed the test so it
passes in either case.
that a 2.93 sec audio file will always take 3.1 sec (as it did on the
hardware I had when I first wrote the test), expect that it will take
2.93 sec +/- 10%, and only fail if it's outside of that range.
Compute the expected
Moved the code for _PyThread_CurrentFrames() up, so it's no longer
in a huge "#ifdef WITH_THREAD" block (I didn't realize it /was/ in
one).
Changed test_sys's test_current_frames() so it passes with or without
thread supported compiled in.
Note that test_sys fails when Python is compiled without threads,
but for an unrelated reason (the old test_exit() fails with an
indirect ImportError on the `thread` module). There are also
other unrelated compilation failures without threads, in extension
modules (like ctypes); at least the core compiles again.
Do we really support --without-threads? If so, there are several
problems remaining.
of values in the time tuple passed in. Unfortunately people came to rely on
undocumented behaviour of setting unneeded values to 0, regardless of if it was
within the valid range. Now those values force the value internally to the
minimum value when 0 is passed in.
The hppa ubuntu box sometimes hangs forever in these tests. My guess
is that the wait is failing for some reason. Use WNOHANG, so we won't
wait until the buildbot kills the test suite.
I haven't been able to reproduce the failure, so I'm not sure if
this will help or not. Hopefully, this change will cause the test
to fail, rather than hang. That will be better since we will get
the rest of the test results. It may also help us debug the real problem.
*** The reason this originally failed was because there were many
zombie children outstanding before rev 47158 cleaned them up.
There are still hangs in test_subprocess that need to be addressed,
but that will take more work. This should close some holes.
str() or repr()) would work, just not multi-value tuples. Probably not a
backport candidate, since it changes the behaviour of passing a
single-element tuple:
>>> string.Template("$foo").substitute(dict(foo=(1,)))
'(1,)'
versus
'1'
handler would cause a segfault. This merges in Expat's lib/xmlparse.c
revisions 1.154 and 1.155, which fix this and a closely related problem
(the later does not affect Python).
Moved the crasher test to the tests for xml.parsers.expat.
Georg Brandl
Tim Peters
Armin Rigo
Brett Cannon
Greg Ward
Martin v. Löwis
Andrew MacIntyre
Neal Norwitz
Phillip J. Eby
Peter Astrand
Neil Schemenauer
Hye-Shik Chang
Nick Coghlan
Thomas Wouters
Fred Drake
Vinay Sajip