File Closing Problem in 2.3 and 2.4, Not in 2.5

[Carroll, Barry]

Greetings:

Please forgive me if this is the wrong place for this post.  I couldn't find a more acceptable forum.  If there is one, please point me in the right direction.  

I am part of a small team writing a table-driven automated testing framework for embedded software.  The tables, which contain rows of keywords and data that drive the testing, are stored as plain-text "Comma-Separated Value" or .csv files.  Each table can call other tables, which means that multiple files may be open at a time.  

The framework includes a Parser class.  The program takes the name of the top-level table as a parameter, creates an instance of the Parser and passes the table name to it.  The Parser instance opens the .csv file with that name, reads each line of the file (row of the table) and takes the appropriate action.  When it encounters a row referencing another table, it creates a new Parser instance and passes it the name of the new table, suspending its own operation until the new Parser instance completes.  

In this way, a tree of Parser instances is created, each with a single open file object.  (BTW, recursive and circular references are not allowed.)  When each Parser instance comes to the end of its table, the instance is explicitly destroyed, presumably destroying any objects it holds, AND closing its open file.  

Because of the nature of the framework and the testing we do, this Parser tree never gets very tall: four or five levels at the most.  The same table may be invoked dozens or hundreds of times, however, with different sets of data each time.  

This is where things go wrong.  After about 500 table invocations, the framework starts refusing to process any more tables, responding with the following error:

	[Errno 24] Too many open files: 'HostCommandDevNotReady.csv'

We can correct the behavior by explicitly closing each Parser's table file object before exiting the Parser code.  This indicates that Python is failing to free up some file-related internal resource when the Parser object is destroyed.  This behavior occurs on Python 2.3 and 2.4 for Windows, but not on Python 2.3 for Linux, and not on the Windows version of Python2.5.  

This is why I didn't just post a report to Bug Tracker: the problem seems to have been fixed.  I did search through the archive of Windows related bugs, but found no mention of this type of a bug.  What I want to know is:

	* has anyone else encountered a problem like this,
	* how was the problem corrected,
	* can the fix be retro-fitted to 2.5 and 2.4?

Thanks in advance for any information you can provide.  

Regards,
 
Barry
barry.carroll at psc.com
541-302-1107
________________________
We who cut mere stones must always be envisioning cathedrals.
-Quarry worker's creed