[Python-Dev] Internal counter to debug leaking file descriptors (original) (raw)

Guido van Rossum guido at python.org
Tue Aug 31 16:03:46 CEST 2010

If you wanted to do something like this in the Python stdlib, you'd have to monkey-patch (with a proxy/wrapper) all places that can open or close a filedescriptor -- os.open, os.popen, os.close, file open/close, socket open/close, and probably a bunch more that I've forgotten. Also some extension modules may open file descriptors directly through the C interfaces.

I don't know if the Windows libc has some kind of tracking feature for file descriptors; of course it complicates things by using separate (numeric) namespaces for sockets and files.

On Linux you can look somewhere in /proc, but I don't know that it would help you find where a file was opened.

--Guido

On Mon, Aug 30, 2010 at 11:49 PM, anatoly techtonik <techtonik at gmail.com> wrote:

Hi,

Is there any kind of internal file descriptor counter that can be queried to debug issues with leaking resources? It can be used in tests to check that all tests are finish with 0 opened descriptors. It will be very useful while porting Python applications from Unix to Windows. Unix is more tolerant to open files and can overwrite them and do other nasty things. See the thread from comment #17 - https://bugs.edge.launchpad.net/dulwich/+bug/557585/ - there is an example of mmap that starts holding file descriptor somewhere long before an error occurs. How could one debug this? Right now I have to use FileMon. It includes information about operated filenames, but no info about source code where this happens. It will be nice to have some kind of counter with filename information inside Python, so that it can be possible to get the full log of events without manually messing with external system-specific tools like FileMon. -- anatoly t.

Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org

-- --Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list