test_tokenize and test_io does sometimes hung on buildbot ARMv4 Debian 3.x. It looks to be related to #8429.

http://www.python.org/dev/buildbot/builders/ARMv4 Debian 3.x/builds/52/steps/test/logs/stdio
---------
...
test_tokenize

command timed out: 1800 seconds without output, killing pid 10998
process killed by signal 9
program finished with exit code -1
elapsedTime=12155.584910
---------

http://www.python.org/dev/buildbot/builders/ARMv4 Debian 3.x/builds/50/steps/test/logs/stdio
----------
...
test_io

command timed out: 1800 seconds without output, killing pid 18097
process killed by signal 9
program finished with exit code -1
elapsedTime=3859.149082
----------

I don't know about test_tokenize, but test_io is quite heavy and a couple of individual tests launch many threads. On a slow CPU with little RAM, the test could simply be still running (swapping?) after 1800s...

There are other hung on trunk (output of bbreport):

ARMv4 Debian trunk         80129, 80120, 80101, 80098, 80085,      
 80129: # hung for 30 min: test_ast                                
 80120: # hung for 30 min: test_descr                              
 80101: # hung for 30 min: test_parser                             
 80098: # hung for 30 min: test_decorators                         
 80085: # hung for 30 min: test_lib2to3                            

ARMv7Thumb Ubuntu trunk    80120, 80098, 80084, 80084,  *** , 80030
 80120: # hung for 30 min: test_descr                              
 80098: # hung for 30 min: test_ast                                
 80084: # hung for 30 min: test_decorators                         
 ...
 80030: # hung for 30 min: test_opcodes

Antoine is right: On a fast machine (3.16GHz) test_io.py takes 810s
on debian-arm/qemu. All tests pass, so perhaps the limit is just too
restrictive on slow machines.

On ARMv7Thumb Ubuntu trunk, build 47 hung after the following tests:
---
test_wait3
test_genericpath
test_uuid
test_zipimport_support
test_slice
test_decorators
---

build 48 hung after the following tests:
---
test_memoryio
test_robotparser
test_charmapcodec
test_ast
---

build 49 hung after the following tests:
---
test_grp
test_binascii
test_uu
test_zlib
test_unpack
test_array
test_list
test_cmd_line
test_traceback
test_global
test_index
test_cd
test_cd skipped -- No module named cd
test_bz2
test_fnmatch
test_posixpath
test_random
test_code
test_gc
test_dict
test_threading_local
test_eof
test_codecmaps_hk
test_aifc
test_descr
---

test_tokenize and test_io were not yet executed.

It would help if regrtest.py added a timestamp to messages (at least "test_xxx" lines). Eg. "18:08:34.750933: test_io".

I ran the whole test suite on

http://people.debian.org/~aurel32/qemu/arm/debian_lenny_arm_small.qcow2

and there were no hanging processes. test_tokenize also takes around
10min on a fast machine (12s without -uall).

Probably the timeout has to be increased drastically or -uall should
be dropped.

> Probably the timeout has to be increased drastically or -uall should
> be dropped.

We should probably increase the timeout on this particular set of
buildbots. -uall has no influence on the duration of e.g. test_io.

the ARMv4 buildbot is a 500Mhz Xscale, with a SATA disk attached, 256MB RAM. It can't go faster :-/

the ARMv7 buildbot is a cortex-a8, 500Mhz, 512MB RAM. I found here five or six python processes still running, now killed. The machine may be unresponsive sometime, as one other (non python) build might run in parallel.

> the ARMv4 buildbot is a 500Mhz Xscale, with a SATA disk attached, 256MB 
> RAM. It can't go faster :-/

Have you checked running the test suite manually (possibly with the -v option for more progress information), to check whether these were genuine freezes? Have you also checked that there was no swapping during the test suite?

In any case, we should probably increase the timeout on that buildbot. Perhaps Martin knows how to do that.

There are no more ARM buildbots, so let's close this issue.