-
Notifications
You must be signed in to change notification settings - Fork 995
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
Fix up some potential memory leaks in fwrite #6757
Conversation
Generated via commit 0a0bcfe Download link for the artifact containing the test results: ↓ atime-results.zip
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #6757 +/- ##
==========================================
- Coverage 98.62% 98.62% -0.01%
==========================================
Files 79 79
Lines 14641 14635 -6
==========================================
- Hits 14440 14434 -6
Misses 201 201 ☔ View full report in Codecov by Sentry. |
A lot of allocation stuff in fwrite was written by Matt. I remove allocation for zlib streams and declare them as z_stream, not z_stream*. I've had an malloc(0) for freeing zbuffPool in all case (except if NOZLIB is defined). |
This isn't covered by the tests, but manually failing this allocation in vgdb results in a leak otherwise: 268,096 (5,952 direct, 262,144 indirect) bytes in 1 blocks are definitely lost in loss record 1,574 of 1,601 at 0x48407B4: malloc (vg_replace_malloc.c:381) by 0x74ACD86: deflateInit2_ (in /lib/x86_64-linux-gnu/libz.so.1.2.13) by 0x90EA5232: init_stream (fwrite.c:576) by 0x90EA5EB0: fwriteMain (fwrite.c:806) by 0x90EA79EE: fwriteR (fwriteR.c:310)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! We needed those deflateEnd
s in addition to the free
s. One remaining leak was visible through testing (zero-row fwrite
) and one more leak on the error path is not easily testable but was confirmed manually in the debugger. There are no remaining complaints from LeakSanitizer.
Co-authored-by: aitap <[email protected]>
Closes #6733.
Looked for any
STOP
orreturn
beforefree()
is called on anymalloc()
object, and made sure tofree()
before those exits if not already done & that object has successfullymalloc()
'd.Also
#ifndef
guards forNOZLIB
outside theargs.is_gzip
checks, so that gzip-disabled installations don't even bother checkingis_gzip
(we error ifis_gzip
is attempted in gzip-disabled installations above)DTPRINT()
calls alerting about allocations to after we checked that the allocation succeeded (the error message is informative enough in case of failure)Thanks @aitap for pointing out the
mystream
issue too. cc @philippechataignon.