BufferedFile: fclose at destruction #29614
Conversation
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code CoverageFor detailed information about the code coverage, see the test coverage report. ReviewsSee the guideline for information on the review process. |
| @@ -520,6 +520,10 @@ class BufferedFile | |||
| throw std::ios_base::failure("Rewind limit must be less than buffer size"); | |||
| } | |||
|
|
|||
| ~BufferedFile() { fclose(); } | |||
There was a problem hiding this comment.
It is better to check the return value of fclose(), otherwise an IO error may remain unnoticed and unreported, leading to silent data corruption.
The problem with calling fclose() from the destructor is that there is no way to signal a failure to the caller - the destructor does not return a value, does not take arguments and is not supposed to throw either.
fclose() from a destructor is a design issue, better avoid that. #29307 is related.
There was a problem hiding this comment.
BufferedFile is only used for reading, so I don't think fclose can fail in a meaningful way? #29307 also ignores the result...
There was a problem hiding this comment.
I see that now you explicitly close the file. Maybe assert there like:
assert(opt_buffered_file->fclose() == 0);and remove this destructor?
There was a problem hiding this comment.
Is it not the case that now this destructor is not needed because you explicitly call fclose()?
This comment is wrong, no? If not, it would be good to point to the exact line in the source code that closes the file in If you are trying to say that real code should be changed to accommodate a comment in a test, I am not sure, unless there is also a real reason for the change. |
|
I agree that there is a subtle error in bitcoin/src/test/fuzz/buffered_file.cpp Lines 22 to 23 in 4a90374 because at the end of the function I do not get the comment about |
|
In any case, you are adding the bug here, not fixing it. See the CI, which is failing |
luke-jr
force-pushed
the
bufferedfile_fclose
branch
from
0397ee1
to
0fa3a0c
Compare
It seems like logically correct behaviour to expect.
Yes, since the destructor calls fclose unconditionally, the AutoFile is still gone even though we fclose'd manually already. Fixed by resetting the std::optional too. |
This is currently indirectly implied by src/bench/load_external.cpp:LoadExternalBlockFile "The file will be closed by LoadExternalBlockFile()." Github-Pull: bitcoin#29614 Rebased-From: 0fa3a0c
luke-jr
force-pushed
the
bufferedfile_fclose
branch
from
0fa3a0c
to
aec5e0f
Compare
This is currently indirectly implied by src/bench/load_external.cpp:LoadExternalBlockFile "The file will be closed by LoadExternalBlockFile()." Github-Pull: bitcoin#29614 Rebased-From: 0fa3a0c
|
For context, BufferedFile may be better off to be removed wholesale, see also #28226 (comment) |
This is currently indirectly implied by src/bench/load_external.cpp:LoadExternalBlockFile "The file will be closed by LoadExternalBlockFile()."
luke-jr
force-pushed
the
bufferedfile_fclose
branch
from
aec5e0f
to
88fe778
Compare
This is currently indirectly implied by src/bench/load_external.cpp:LoadExternalBlockFile
The file will be closed by LoadExternalBlockFile().It reveals a subtle (but noop currently) bug in the BufferedFile fuzz tests: Because the BufferedFile is created before the CAutoFile, the CAutoFile gets cleaned up first, leaving the BufferedFile with pointers to a deleted CAutoFile. The simple fix for this is to use the newly-added
fclosefor BufferedFile, and both are trivial changes, so I've squashed them into a single commit.