jenndhemus / editra-plugins

Automatically exported from code.google.com/p/editra-plugins
0 stars 0 forks source link

OSError: Too many open files #13

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Not sure yet
2.
3.

What is the expected output? What do you see instead?
Got these tracebacks still not sure why this has happened just making note
for now.

*** Thu Aug 30 09:23:39 2007 ***
Traceback (most recent call last):
  File "build/bdist.macosx-10.3-fat/egg/projects/ProjectPane.py", line 625,
in OnItemExpanded
OSError: [Errno 24] Too many open files: '/Users/cody/web_dev/editra'

*** Thu Aug 30 09:24:20 2007 ***
Traceback (most recent call last):
  File "build/bdist.macosx-10.3-fat/egg/projects/ProjectPane.py", line
1064, in OnItemCollapsed
KeyError: 'watcher'

Please use labels and text to provide additional information.

Original issue reported on code.google.com by CodyPrec...@gmail.com on 30 Aug 2007 at 2:29

GoogleCodeExporter commented 8 years ago
Still not a 100% sure but this happened after I had the projects plugin running 
for
along time and was doing allot of work and testing of it and other parts of the 
editor.

One thing I did notice is that all of the source control commands when they do a

out = self.run(....)

The 'out' object returned is a file like object but I don't see that object ever
being given a out.close() to close it. Does this get handled explicitly 
elsewhere or
should it be handled inside the source control calls? If not this may be 
leaving many
unclosed handles that causing this error to bubble up eventually.

Original comment by CodyPrec...@gmail.com on 30 Aug 2007 at 2:52

GoogleCodeExporter commented 8 years ago
The logOutput method calls the closeProcess method which shuts down the source 
control commands.  The 
logOutput method is used by all of the source control methods, so I'm not sure 
that's the problem.  I will admit 
that I get pretty lazy about reading and writing files and I use things like 
open('...').read() and 
open('...','w').write(...) a lot.  I thought that Python cleaned those up, but 
maybe that's causing the problem.

Original comment by Kevin.Da...@gmail.com on 2 Sep 2007 at 2:52

GoogleCodeExporter commented 8 years ago
I think it will clean them up when an object is destroyed. But it is usually 
better
to be explicit with these kind of things, especially on windows where it wont 
let
another process edit/delete a file if it is opened by another process.

This error only happened once (so far), but it was rather catastrophic as I 
couldn't
save any of the files in editor and everytime I tried more error messages were
blowing up everywhere.

Original comment by CodyPrec...@gmail.com on 2 Sep 2007 at 3:00

GoogleCodeExporter commented 8 years ago
I went in and put in code to explicitly close any file handles that were 
opened.  I'm not sure if that was the 
problem, but I don't see anything else wrong with the code.  I'll mark it fixed 
for now and hope that it's taken 
care of.

Original comment by Kevin.Da...@gmail.com on 5 Sep 2007 at 4:34

GoogleCodeExporter commented 8 years ago
Only saw this the one time and haven't seen it since,

closing as verified

Original comment by CodyPrec...@gmail.com on 22 Jan 2008 at 8:40