[Bugs] [Bug 1287517] Memory leak in glusterd

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1287517



--- Comment #40 from Roman Tereshonkov <tereshonkov.roman at gmail.com> ---
> if by looking into glusterd log's you are saying that memory allocated by glusterd_set_txn_opinfo call too many number of time compare to glusterd_clear_txn_opinfo then its wrong. its true that glusterd_set_txn_opinfo calling more number of time at remote node compare to glusterd_clear_txn_opinfo but it doesn't mean that every time its allocate memory. from the function (glusterd_set_txn_opinfo) you can see that if ret is non zero (means its unable to get txn opinfo from the dictionary) then only it will allocate memory and it happen only one's at the starting of transaction. 


By transaction I mean a sequence of commands with the same transaction id.

As I mentioned earlier every run of "volume status all" generates two different
transactions with different transaction ids.
glusterd_set_txn_opinfo is called with "transaction id" as argument and
allocates opinfo every time when there is no such transaction opinfo in
dictionary.
glusterd_clear_txn_opinfo is called with "transaction id" as argument and frees
opinfo with such id from dictionary glusterd_txn_opinfo.

In our case the glusterd_clear_txn_opinfo function is called only once with
"transaction id" corresponding to the second transaction.

As a provement you can add "dict_dump_to_log(priv->glusterd_txn_opinfo);" at
the end of function glusterd_clear_txn_opinfo to see the content of the
dictionary.
You will see that after every run of "volume status all" the dictionary
glusterd_txn_opinfo grows keeping all unallocated opinfo identified by the
every first transaction id.


By the way if you run "volume status VOLNAME" with existed VOLNAME then only
one transaction is generated and it looks like no memory leaks.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=5gMAdywYiO&a=cc_unsubscribe