Memory leak on m_i_gen_elem_out of DecodeTree about opencsd HOT 4 CLOSED

Hi,

You are correct in that setGenTraceElemOutI() needs to store:
m_i_gen_elem_out = i_gen_trace_elem;

but the client must test and delete the object.
In this case the C-API handler code must test for a current set interface and delete a GenTraceElemCBObj if found

Mike

from opencsd.

Hi Mike,

In my usage the client is the caller of ocsd_dt_set_gen_elem_outfn and ocsd_destroy_dcd_tree defined in opencsd_c_api.h. The ocsd_dt_set_gen_elem_outfn allocates a GenTraceElemCBObj instance for function setGenTraceElemOutI:

OCSD_C_API ocsd_err_t ocsd_dt_set_gen_elem_outfn(const dcd_tree_handle_t handle, FnTraceElemIn pFn, const void *p_context)
{

    GenTraceElemCBObj * pCBObj = new (std::nothrow)GenTraceElemCBObj(pFn, p_context);
    if(pCBObj)
    {
        ((DecodeTree *)handle)->setGenTraceElemOutI(pCBObj);

But without assigning it to m_i_gen_elem_out, the GenTraceElemCBObj object cannot be released by ocsd_destroy_dcd_tree. That is, following usage can reproduce the leakage:

dcd_tree_handle_t dcdtree_handle;

dcdtree_handle = ocsd_create_dcd_tree(...);
ocsd_dt_set_gen_elem_outfn(dcdtree_handle, ...);
ocsd_destroy_dcd_tree(dcdtree_handle)

dcdtree_handle = ocsd_create_dcd_tree(...);
ocsd_dt_set_gen_elem_outfn(dcdtree_handle, ...);
ocsd_destroy_dcd_tree(dcdtree_handle);

And seems for such a caller, the opencsd_c_api.h doesn't expose a C-API to access and delete the GenTraceElemCBObj directly?

from opencsd.

The assignment of :-
m_i_gen_elem_out = i_gen_trace_elem;
occurs in ocsd_dcd_tree.cpp -> DecodeTree::setGenTraceElemOutI(),

A check for a previous assignment an release of the old GenTraceElemCBObj must then take place in ocsd_c_api.cpp -> ocsd_dt_set_gen_elem_outfn() before any new object is allocated.

Thus the creation and destruction of these internal C-API layer objects takes place in the same area of code.

This will be fixed in the next release of the library

from opencsd.