Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Ensure file resources are released#326

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation

vokimon
Copy link
Contributor

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 requestJul 27, 2015
@ByronByron merged commit7c96f58 intogitpython-developers:masterJul 27, 2015
@Byron
Copy link
Member

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.

@ByronByron added this to thev1.0.2 - Fixes milestoneJul 27, 2015
@vokimon
Copy link
ContributorAuthor

what about starting with a grep for 'open'?

@Byron
Copy link
Member

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 aGitCmdObjectDB, at least when working with non-ref/object data.

EliahKagan added a commit to EliahKagan/GitPython that referenced this pull requestNov 3, 2023
This removes a comment noting that a try-finally block had beenpresent (or had been intended), but was removed because someversion of Python had imposed a limitation on yield appearing intry-finally.That comment was obsolete as of58c5b99 (gitpython-developers#326), which wrapped therelevant 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 whileworking ongitpython-developers#1725, but I didn't include this change there, havingnot yet looked into the history of the code enough to be sure.)
EliahKagan added a commit to EliahKagan/GitPython that referenced this pull requestNov 3, 2023
This removes a comment noting that a try-finally block had beenpresent (or had been intended), but was removed because someversion of Python had imposed a limitation on yield appearing intry-finally.That comment was obsolete as of58c5b99 (gitpython-developers#326), which wrapped therelevant 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 whileworking ongitpython-developers#1725, but I didn't include this change there, havingnot yet looked into the history of the code enough to be sure.)
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Milestone
v1.0.2 - Fixes
Development

Successfully merging this pull request may close these issues.

2 participants
@vokimon@Byron

[8]ページ先頭

©2009-2025 Movatter.jp