"OSError: [Errno 10] No child processes"
Hi, Could someone help me to avoid the following exception? Exception "OSError: [Errno 10] No child processes" in method __del__ of <closed file '<fdopen>', mode 'r' at 0x00002b58059f05f8> ignored Thanks in advance, Arnd
Hi, 2011/1/11 Arnd Rechenburg <Arnd.Rechenburg@tomtom.com>:
Could someone help me to avoid the following exception?
Exception "OSError: [Errno 10] No child processes" in method __del__ of <closed file '<fdopen>', mode 'r' at 0x00002b58059f05f8> ignored
More context would be useful: which version of pypy are you using, what are you trying to do, are there some kind of subprocesses, etc etc. -- Amaury Forgeot d'Arc
Hi Amaury, I use the following environment: Python 2.5.2 (e503e483e9ac, Dec 21 2010, 12:02:48) [PyPy 1.4.1] on linux2 For the moment I use os.execv and os.waitpid(-1, os.WNOHANG) to start and handle parallel jobs by myself. I tried already a 'try except OSError' around os.waitpid but without success. Greetings, Arnd -----Original Message----- From: Amaury Forgeot d'Arc [mailto:amauryfa@gmail.com] Sent: Dienstag, 11. Januar 2011 15:34 To: Arnd Rechenburg Cc: pypy-dev@codespeak.net Subject: Re: [pypy-dev] "OSError: [Errno 10] No child processes" Hi, 2011/1/11 Arnd Rechenburg <Arnd.Rechenburg@tomtom.com>:
Could someone help me to avoid the following exception?
Exception "OSError: [Errno 10] No child processes" in method __del__ of <closed file '<fdopen>', mode 'r' at 0x00002b58059f05f8> ignored
More context would be useful: which version of pypy are you using, what are you trying to do, are there some kind of subprocesses, etc etc. -- Amaury Forgeot d'Arc
2011/1/11 Arnd Rechenburg <Arnd.Rechenburg@tomtom.com>:
Hi Amaury,
I use the following environment:
Python 2.5.2 (e503e483e9ac, Dec 21 2010, 12:02:48) [PyPy 1.4.1] on linux2
For the moment I use os.execv and os.waitpid(-1, os.WNOHANG) to start and handle parallel jobs by myself.
I tried already a 'try except OSError' around os.waitpid but without success.
It's probably related to our file.__del__ which does not silence errors raised by close(). Could you file a ticket about this on the issue tracker? with a small test case if possible. https://codespeak.net/issue/pypy-dev/ -- Amaury Forgeot d'Arc
Hi Amaury, On Tue, Jan 11, 2011 at 4:41 PM, Amaury Forgeot d'Arc <amauryfa@gmail.com> wrote:
It's probably related to our file.__del__ which does not silence errors raised by close().
Indeed, it seems to be the case. Arnd, to answer the original question: there is a file that you are not explicitly closing, and when its __del__ method is (later) invoked, it raises an OSError which is printed and ignored. The real problem you have there is that you should close your files (in this case, an <fdopen> file, so I guess it's actually a pipe returned by os.popen*()). The secondary problem that we have is what to do when file.__del__ gets an exception from calling close(). Is it ok to just ignore it? FWIW in CPython, file.__del__ also prints an error message if close() raises an exception. So from that point of view there is nothing to fix in PyPy, apart maybe making the error message a bit more explicit (CPython prints "close failed in file object destructor:..."). A bientôt, Armin.
2011/1/11 Armin Rigo <arigo@tunes.org>:
The secondary problem that we have is what to do when file.__del__ gets an exception from calling close(). Is it ok to just ignore it? FWIW in CPython, file.__del__ also prints an error message if close() raises an exception. So from that point of view there is nothing to fix in PyPy, apart maybe making the error message a bit more explicit (CPython prints "close failed in file object destructor:...").
The io module chose to silence the error; I suggest to do the same, even if the reasoning is different from the comment below:: class IOBase: def __del__(self): """Destructor. Calls close().""" # The try/except block is in case this is called at program # exit time, when it's possible that globals have already been # deleted, and then the close() call might fail. Since # there's nothing we can do about such failures and they annoy # the end users, we suppress the traceback. try: self.close() except: pass -- Amaury Forgeot d'Arc
On Tue, Jan 11, 2011 at 22:09, Amaury Forgeot d'Arc <amauryfa@gmail.com> wrote:
2011/1/11 Armin Rigo <arigo@tunes.org>:
The secondary problem that we have is what to do when file.__del__ gets an exception from calling close(). Is it ok to just ignore it? FWIW in CPython, file.__del__ also prints an error message if close() raises an exception. So from that point of view there is nothing to fix in PyPy, apart maybe making the error message a bit more explicit (CPython prints "close failed in file object destructor:...").
The io module chose to silence the error; I suggest to do the same, even if the reasoning is different from the comment below::
class IOBase: def __del__(self): """Destructor. Calls close().""" # The try/except block is in case this is called at program # exit time, when it's possible that globals have already been # deleted, and then the close() call might fail. Since # there's nothing we can do about such failures and they annoy # the end users, we suppress the traceback.
I propose that PyPy keeps reporting the error for files opened in any write mode, because then an error on close might mean that an I/O error happened (it is possible in some scenarios on Linux, see below [1]); the programmer thus need to explicitly close the file and check for exceptions. Having writable files closed by __del__ also sounds like a bad idea if any buffering is involved, because close() time becomes unpredictable. Those are mostly arguments against __del__ _silently_ calling close(); but when the potential bug is triggered, i.e. you hit an I/O error, it's even more important to report it to the user. I also propose that any error is ignored for read-mode files - because then why should we care for it? The original error message talked about a read-mode file handle. [1] From the close(2) man page: "Not checking the return value of close() is a common but nevertheless serious programming error. It is quite possible that errors on a previous write(2) operation are first reported at the final close(). Not checking the return value when closing the file may lead to silent loss of data. This can especially be observed with NFS and with disk quota." Cheers, -- Paolo Giarrusso - Ph.D. Student http://www.informatik.uni-marburg.de/~pgiarrusso/
Hi Amaury, On Wed, Jan 12, 2011 at 2:49 AM, Paolo Giarrusso <p.giarrusso@gmail.com> wrote:
I propose that PyPy keeps reporting the error for files opened in any write mode
I would also think that it's better to keep reporting errors (and for all files instead of just write mode files). In my opinion, it would, if nothing else, give users the message: "we got an error when close()ing this file automatically, but you should really close it explicitly yourself in the first place". Maybe it can even be written in that sense in the error message. A bientôt, Armin.
On Thu, Jan 13, 2011 at 2:12 PM, Armin Rigo <arigo@tunes.org> wrote:
Hi Amaury,
On Wed, Jan 12, 2011 at 2:49 AM, Paolo Giarrusso <p.giarrusso@gmail.com> wrote:
I propose that PyPy keeps reporting the error for files opened in any write mode
I would also think that it's better to keep reporting errors (and for all files instead of just write mode files). In my opinion, it would, if nothing else, give users the message: "we got an error when close()ing this file automatically, but you should really close it explicitly yourself in the first place". Maybe it can even be written in that sense in the error message.
How about a link to differencies between pypy and cpython, especially about closing files? Cheers, fijal
A bientôt,
Armin. _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Hi, On Thu, Jan 13, 2011 at 1:25 PM, Maciej Fijalkowski <fijall@gmail.com> wrote:
close()ing this file automatically, but you should really close it explicitly yourself in the first place". Maybe it can even be written in that sense in the error message.
How about a link to differencies between pypy and cpython, especially about closing files?
Yes please :-) Armin
On Thu, Jan 13, 2011 at 13:43, Armin Rigo <arigo@tunes.org> wrote:
Hi,
On Thu, Jan 13, 2011 at 1:25 PM, Maciej Fijalkowski <fijall@gmail.com> wrote:
close()ing this file automatically, but you should really close it explicitly yourself in the first place". Maybe it can even be written in that sense in the error message.
How about a link to differencies between pypy and cpython, especially about closing files?
And I guess you can also mention Jython and IronPython as being PyPy-like (if the behavior just depends on having a GC instead of refcounting). Disclaimer: I've never used IronPython.
Yes please :-) -- Paolo Giarrusso - Ph.D. Student http://www.informatik.uni-marburg.de/~pgiarrusso/
participants (5)
-
Amaury Forgeot d'Arc -
Armin Rigo -
Arnd Rechenburg -
Maciej Fijalkowski -
Paolo Giarrusso