c2c-oerpscenario team mailing list archive

["Albert Cervera i Areny - http://www.NaN-tic.com" <albert@xxxxxxxxxxx>]

A Dilluns, 3 de gener de 2011, xrg va escriure:
> My humble comment: 
> this is a Windows-only issue. 
> 
> In other systems, file handles are just too many to care about. Also, the 
> destruction of python objects (files) means that their corresponding
> handles  are closed. That may be the explanation why we miss such "bugs".
> Resource de-allocation is automatic here.

I disagree. File handles is something to take care of. We've had problems in 
production systems with modules that didn't close their file descriptors 
(jasper_reports and other modules).

-- 
Albert Cervera i Areny
http://www.NaN-tic.com
OpenERP Partners
Tel: +34 93 553 18 03

http://twitter.com/albertnan 
http://www.nan-tic.com/blog

-- 
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.
https://bugs.launchpad.net/bugs/676931

Title:
  Server leaves file handles open on import error

Status in OpenObject Server:
  In Progress

Bug description:
  The Server leaves file handles open on errors that occur when importing (sql or csv or xml):
see the file handling for importing in addons/__init__.py

On Windows, this leaves the file locked against renaming, deletion and sometimes
even editing depending on the editor, until the server exits. On all systems, you
can run out of file handles if you are reloading lots of modules whilst debugging.
And it may be responsible for what I'm seeing occasionally under Windows XP SP3
where the net stop command to to the server leaves the server running.

All file opens in Python should be protected with try:/finally: close() - you should
check the whole code. I've done a patch to the most important one in addons__init__.py
and added the filename to the error message while I was at it.  You really
should be passing up the error message stack trace from the underlying library
to show what line in the file (or block/tag of xml) the error occurred in. But the patch is
a start.

The patch is a context diff against 5.0.15.