-
Notifications
You must be signed in to change notification settings - Fork 256
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 various memory leaks #1723
fix various memory leaks #1723
Conversation
92d1d7d
to
2145733
Compare
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.
That is a huge improvement! How did you find all of these?
I have a few remarks. Nothing critical though.
I gathered all the logs created by asan with our test suite. |
b780ff7
to
1ae4aea
Compare
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.
The code looks great.
However, the new dbcheck test fails everywhere, so you'll have to take another look.
Do you think we should backport some/all of these into 23? |
Ill try to backport it and ill see what works. |
30eea5b
to
d220b39
Compare
PQfinish _always_ has to be called on db_handle_, if its not null: https://www.postgresql.org/docs/current/libpq-connect.html "Note that when PQconnectStart or PQconnectStartParams returns a non-null pointer, you must call PQfinish when you are finished with it, in order to dispose of the structure and any associated memory blocks. This must be done even if the connection attempt fails or is abandoned." PQexec() always allocates a new result object, that always has to be freed with PQclear()!
Instead of hunting down every place where this could get leaked, we instead use PoolMem to do so automatically.
Removing unecessary code since stifle_history() already ensures that we only have at most history_max_entries inside our history. Regardless this is a leak because remove_history returns to us a HIST_ENTRY* that we are supposed to free on our own (which we do not do!).
When an error occurs during the resource scanning, then the scanned resource is not added to any list, which means its memory is never freed. As such we free the allocated resource here but calling the appropriate callback.
e44b4e7
to
318258a
Compare
Thank you for contributing to the Bareos Project!
Please check
If you have any questions or problems, please give a comment in the PR.
Helpful documentation and best practices
Checklist for the reviewer of the PR (will be processed by the Bareos team)
Make sure you check/merge the PR using
devtools/pr-tool
to have some simple automated checks run and a proper changelog record added.General
Source code quality
Tests