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

gh-120754: Ensure _stat_atopen is cleared on fd change#125166

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

Merged
vstinner merged 11 commits intopython:mainfromcmaloney:cmaloney/fd_cleanup
Nov 1, 2024

Conversation

@cmaloney
Copy link
Contributor

@cmaloneycmaloney commentedOct 8, 2024
edited by bedevere-appbot
Loading

While adding _stat_atopen I accidentally created a leak in the C implementation because the_stat_atopen member was set to NULL in the C implementation, but the memory wasn't freed. That was resolved, but it showed there were a number of potential cases where_stat_atopenshould be cleared (the information is out of date because the fd changed) that it was not. In this PR I audited by reading through FileIO (in _io and _pyio), and in all cases where the fd is changed/closed made sure to clear/reset _stat_atopen as well.

Followup from:#124225 (comment), cc:@vstinner

Performed an audit of `fileio.c` and `_pyio` and made sure anytime thefd changes the stat result, if set, is also cleared/changed.There's one case where it's not cleared, if code would clear it in__init__, keep the memory allocated and just do another fstat with theexisting memory.
if (internal_close(self)<0)
/* Have to close the existing file first.
This leaves the stat so we can reuse the memory. */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I don't think that this optimization is worth it, I would prefer to always clear the cache in close().

cmaloney reacted with thumbs up emoji
#endif
}

PyMem_Free(self->stat_atopen);
Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Not sure which is preferred here. The Free + New back to back feels weird, but version with the conditional feels like "extra work/code thatshould never be executed" (but that the compiler / tools that run currently won't validate...).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Maybeif (ptr != NULL) free(ptr) would be more regular and avoid the 4 lines long comment.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Moved to that, dropped comment and simplified / back to always calling PyMem_New

Copy link
Member

@vstinnervstinner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

There are compiler warnings that you can see in the review tab.

cmaloney reacted with eyes emoji
@cmaloney
Copy link
ContributorAuthor

cmaloney commentedOct 9, 2024
edited
Loading

I think the latest commit fixes the compiler warnings (was a testing/debugging assert I accidentally committed with a missing;, latest changes remove that assert). Not able to find them in the latest changes.

@cmaloney
Copy link
ContributorAuthor

CI "Tests / Ubuntu SSL tests with OpenSSL" failed because of what looks like a network hang / not these changes:Received 164773440 of 168967744 (97.5%), 0.0 MBs/sec while doing "Configure ccache action"

}
}
PyMem_Free(self->stat_atopen);
self->stat_atopen=NULL;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

internal_close() already does the same, so it's redundant, no?

Copy link
ContributorAuthor

@cmaloneycmaloneyOct 31, 2024
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Tradeoff for matching what_pyio does which doesos.close() in these cases vs aninternal_close that does the OS close + other cleanup. Happy to drop though / definitely feels redundant to me in these two cases.

#endif
if (self->fd >=0) {
PyMem_Free(self->stat_atopen);
self->stat_atopen=NULL;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

internal_close() already does the same, so it's redundant, no?

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Moderately, in theself->closefd is false case behavior would differ from _pyio, but that will be caught by the PyMem_Free + PyMem_New below, so think this is always redundant / not needed

}

PyMem_Free(self->stat_atopen);
if (self->stat_atopen!=NULL) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

PyMem_Free(NULL) is well defined: it does nothing, so you might omit theif (stat_atopen != NULL) test.

cmaloney reacted with thumbs up emoji
@vstinnervstinner merged commit72dd471 intopython:mainNov 1, 2024
39 checks passed
@vstinner
Copy link
Member

Merged, thank you.

cmaloney reacted with hooray emoji

@cmaloneycmaloney deleted the cmaloney/fd_cleanup branchNovember 1, 2024 21:55
picnixz pushed a commit to picnixz/cpython that referenced this pull requestDec 8, 2024
…n#125166)Performed an audit of `fileio.c` and `_pyio` and made sure anytime thefd changes the stat result, if set, is also cleared/changed.There's one case where it's not cleared, if code would clear it in__init__, keep the memory allocated and just do another fstat with theexisting memory.
ebonnal pushed a commit to ebonnal/cpython that referenced this pull requestJan 12, 2025
…n#125166)Performed an audit of `fileio.c` and `_pyio` and made sure anytime thefd changes the stat result, if set, is also cleared/changed.There's one case where it's not cleared, if code would clear it in__init__, keep the memory allocated and just do another fstat with theexisting memory.
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@vstinnervstinnervstinner left review comments

Assignees

No one assigned

Labels

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@cmaloney@vstinner

[8]ページ先頭

©2009-2025 Movatter.jp