[dev.icinga.com #3405] Failure to free() libdbi results causes memory leaks in ido2db #1150
This issue has been migrated from Redmine: https://dev.icinga.com/issues/3405
Created by crfriend on 2012-10-28 23:29:35 +00:00
The changes required to get around the new "unsafeness" of "UPDATE .. ON DUPLICATE KEY" in MySQL resulted in a failure to properly free() the results from queries to the MySQL database. This, in turn, resulted in a memory leak. The attached patch, having been run for 3+ hours with no indicated leakage, attempts to address the issue.
It is worth noting that similar countermeasures may be required for Postgres databases, and the tactic used in this patch may well be applicable to Postgres. I was unable to test or verify that, however, as I do not have a Postgres database operational in my lab.
2012-10-29 18:31:20 +00:00 by mfriedrich 59bec47
Updated by crfriend on 2012-10-29 20:09:54 +00:00
The observed behaviours in #3406 are the same as I was trying to fix. I suspect either patch-set will fix them.
In my case, I've been watching my patched version of ido2db for the past 24 hours and it's not leaked even a single page of mainstore.
At first blush, I believe that the same fixes are applicable to the Postgres database as well, but as I do not have an operational Postgres databsase here I opted to not try patching that and defer to someone who uses Postgres.
Updated by mfriedrich on 2012-10-30 21:19:09 +00:00
your patch does add a free sometimes after the second query was issued - which is then cleaned outside the call of the insert_or_update query. though, to note, within #3408 this must be fixed anyways.
Updated by crfriend on 2012-10-30 21:48:16 +00:00
In looking at the reasons for leakage on my work systems it came to my attention that I had not updated the MySQL database schema correctly which caused some queries to fail on "Unknown column" -- and when queries failed memory allocated to create the query was not freed.
For the sake of completeness and correctness I feel this should be corrected with a patch. Does the community feel the same way? If so, I'll provide what I can find.
Updated by crfriend on 2012-10-31 20:40:50 +00:00
It turns out that it wasn't a failure to free the query, it was part of the stuff used to generate the query that wasn't getting free()d. In any event, the only leakage I detected was from a single subroutine, and the patch called 3405-query-fail-free.txt is designed to address that one condition.