You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think we should introduce new APIs to increment/decrement the ref value of a Sdb. This can be very useful in radare2 where sdb are passed around and sometimes it's not clear which component will be the first to release a given Sdb.
This seems the case with RBinFile, which has a ->sdb field which is not freed in r_bin_file_free because it is already freed by someone else. This leads to memory leaks in some cases and in general I think it is not good practice to have some fields of a data structure owned by something else.
The text was updated successfully, but these errors were encountered:
Agree. Same is hapoening in anal with all the bb and fcn info that can be shared across miltiple structures and result in crash or leaks. Debugging reference counting is a pain in the ass but at least it will allow us to handle those chaotic meshed uses of multiple sdbs being referenced as namespaces or between multiple places. I see refcounting also helpful for multithread to avoid races when using unowned structs
On 24 Oct 2019, at 12:41, Riccardo Schirone ***@***.***> wrote:
I think we should introduce new APIs to increment/decrement the ref value of a Sdb. This can be very useful in radare2 where sdb are passed around and sometimes it's not clear which component will be the first to release a given Sdb.
This seems the case with RBinFile, which has a ->sdb field which is not freed in r_bin_file_free because it is already freed by someone else. This leads to memory leaks in some cases and in general I think it is not good practice to have some fields of a data structure owned by something else.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
I think we should introduce new APIs to increment/decrement the ref value of a Sdb. This can be very useful in radare2 where sdb are passed around and sometimes it's not clear which component will be the first to release a given Sdb.
This seems the case with RBinFile, which has a
->sdb
field which is not freed inr_bin_file_free
because it is already freed by someone else. This leads to memory leaks in some cases and in general I think it is not good practice to have some fields of a data structure owned by something else.The text was updated successfully, but these errors were encountered: