Test under Python 2.3-2.6

[GoogleCodeExporter]

Make sure that the latest changes to protest.py work under Python 2.2 and
2.3 and run all the other tests on those versions, too.  The use of
subprocess may have to be changed, in particular.

Original issue reported on code.google.com by the.good...@gmail.com on 22 Aug 2008 at 5:02

[GoogleCodeExporter]

We do want to test on both 2.2 and 2.3 platforms, especially for 0.8.

Original comment by cjlee...@gmail.com on 11 Sep 2008 at 4:11

• Added labels: Milestone-Release0.8

[GoogleCodeExporter]

2.6 should also be tested, given it is stable now.

Original comment by mare...@gmail.com on 8 Jan 2009 at 12:59

[GoogleCodeExporter]

In light of how old it is, we have decided to abandon 2.2 support.

Original comment by mare...@gmail.com on 18 Feb 2009 at 1:25

• Changed title: Test under Python 2.3-2.6

[GoogleCodeExporter]

I've tested on 2.3, 2.4, 2.5 and 2.6.  All but 2.4 run the test framework fine.

I hit some problems on 2.4 due to missing a working bsddb module.  The main 
symptom
is that the fallback module (presumably gdbm) seems to open files and fail to 
close
them, because over the course of running all the tests, it start generating 
"too many
open files" errors.  If you run the test files one by one, there's only 1 error
(seqdb_test.PrefixUnionDictTest).  I don't think this is a test framework 
issue, but
I could be wrong, I guess.  I propose we resolve this as a separate issue (e.g.
"testing Pygr without bsddb accumulates open files")

Original comment by cjlee...@gmail.com on 8 Apr 2009 at 5:34

• Changed state: FixedNeedsReview

[GoogleCodeExporter]

I used Fink to repair my Python 2.4 install, and install pysqlite2 support.  

All tests pass on 2.4, 2.5, and 2.6.  

I see no easy way to install 2.3 on my mac (compiling on OS 10.5 generates all 
sorts
of error messages; all the 2.3 macpython binary installs on the web are for OS 
10.2,
which hardly seems likely to work on OS 10.5).  

So I can only run the Python 2.3 tests on linux (2.4.20).  All tests pass; 3 
suites
were skipped because this install lacks pysqlite2.  The SEGV still occurs at 
the end
of the test framework (after it reports the results of all the Pygr tests).

Original comment by cjlee...@gmail.com on 8 Apr 2009 at 8:49

[GoogleCodeExporter]

Should have had this posted earlier but Titus and his students have now got a 
Pygr 
buildbot up and running. You can see its output here: 
http://lyorn.idyll.org:8019/

As of today, buildbot results and Chris's observations match: all tests execute 
successfully on all four Python versions, except with 2.3 the process 
terminates 
with a segmentation fault about right when it should simply exit.

Given the actual tests pass even with 2.3, the issue can now be considered 
closed.

Original comment by mare...@gmail.com on 8 Apr 2009 at 9:04

• Changed state: Closed
• Added labels: Type-Task, reviewby-cjlee112
• Removed labels: Type-Defect

[GoogleCodeExporter]

I've just run Pygr tests on Mac OS 10.4 with Python 2.3 + Pyrex 0.9.8.5 and 
where 
the Linux boxes see a segmentation fault, OS X gets an indefinite hang of the 
Python 
process. The hang appears to happen during the sys.exit() call (a debug message 
inserted right before it gets printed successfully) and is quite persistent 
system-
wise (the process completely ignores most termination and suspension signals, 
as a 
result trying to attach gdb to it doesn't work because the debugger keeps 
waiting 
for the process to stop execution; it survives closing the terminal window; 
only 
SIGKILL works).

Original comment by mare...@gmail.com on 16 Apr 2009 at 8:29

[GoogleCodeExporter]

I've got the crash down to the following code:

from testlib import testutil
from pygr.cnestedlist import NLMSA
from pygr.annotation import AnnotationDB

class TestCrash(object):
    def test_crash(self):
        db1 = AnnotationDB({}, {})
        mymap = NLMSA('testfoo', 'memory')

x = TestCrash()
x.test_crash()

Original comment by the.good...@gmail.com on 17 Apr 2009 at 4:41