Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure file resources are released #326

Conversation

vokimon
Copy link
Contributor

@vokimon vokimon commented Jul 26, 2015

SymbolicReference leaked file descriptor resources when iterating on refs. unittest module complained:

symbolic.py:153: ResourceWarning: unclosed file <_io.TextIOWrapper name='...../gitrepo/.git/packed-refs' mode='rt' encoding='UTF-8'>
symbolic.py:148: ResourceWarning: unclosed file <_io.TextIOWrapper name='....../gitrepo/.git/packed-refs' mode='rt' encoding='UTF-8'>

Byron added a commit that referenced this pull request Jul 27, 2015
…patch-1

Ensure file resources are released
@Byron Byron merged commit 7c96f58 into gitpython-developers:master Jul 27, 2015
@Byron
Copy link
Member

Byron commented Jul 27, 2015

Thank you very much !

I am afraid there are many more issues of that kind buried in the code as I was wrongly assuming (back in the days) that an object destructor is deterministically called (such as in C++). This led to me failing to explicitly close files.

@Byron Byron added this to the v1.0.2 - Fixes milestone Jul 27, 2015
@vokimon
Copy link
Contributor Author

vokimon commented Jul 27, 2015

what about starting with a grep for 'open'?

@Byron
Copy link
Member

Byron commented Jul 27, 2015

One will have to spread these efforts among GitDB and SMMap as well. Both should have mechanisms to release resources, but I doubt this works properly.

For now the best way to workaround these resource related issues is to use a GitCmdObjectDB, at least when working with non-ref/object data.

EliahKagan added a commit to EliahKagan/GitPython that referenced this pull request Nov 3, 2023
This removes a comment noting that a try-finally block had been
present (or had been intended), but was removed because some
version of Python had imposed a limitation on yield appearing in
try-finally.

That comment was obsolete as of 58c5b99 (gitpython-developers#326), which wrapped the
relevant code in a with-statement, because:

1. Since then, the cleanup is done in a manner equivaent to
   try-finally.

2. It turned out, as noted in that PR, that cleanup had not
   always been done automatically. (This was contrary to the
   prediction given in the comment.)

3. At some point before that, the limitation that had prevented
   the use of try-finally no longer affected any supported version
   of Python.

   Specifically, it appears the only limitation that this could be
   was the limitation lifted in Python 2.5, where along with the
   addition of the close() method which causes try-finally to be
   called (and is itself called when a generator object is
   finalized), yield in a try-block with an associated
   finally-block became permitted, since the call to close() was
   sufficient to run the finally-block (by raising GeneratorExit).

   For details, see:
   https://docs.python.org/3/whatsnew/2.5.html#pep-342-new-generator-features

(This obsolete comment was one of the things I discovered while
working on gitpython-developers#1725, but I didn't include this change there, having
not yet looked into the history of the code enough to be sure.)
EliahKagan added a commit to EliahKagan/GitPython that referenced this pull request Nov 3, 2023
This removes a comment noting that a try-finally block had been
present (or had been intended), but was removed because some
version of Python had imposed a limitation on yield appearing in
try-finally.

That comment was obsolete as of 58c5b99 (gitpython-developers#326), which wrapped the
relevant code in a with-statement, because:

1. Since then, the cleanup is done in a manner equivaent to
   try-finally.

2. It turned out, as noted in that PR, that cleanup had not
   always been done automatically. (This was contrary to the
   prediction given in the comment.)

3. At some point before that, the limitation that had prevented
   the use of try-finally no longer affected any supported version
   of Python.

   Specifically, it appears the only limitation that this could be
   was the limitation lifted in Python 2.5, where along with the
   introduction of close(), which is automatically called when a
   generator object is finalized, it became permitted for yield to
   appear in a try-block with an associated finally-block, on the
   grounds that calling close() runs the finally-block (by raising
   GeneratorExit).

   For details, see:
   https://docs.python.org/3/whatsnew/2.5.html#pep-342-new-generator-features

(This obsolete comment was one of the things I discovered while
working on gitpython-developers#1725, but I didn't include this change there, having
not yet looked into the history of the code enough to be sure.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants