Memory leak when adding a row...

[Frank Fock]

Michael,

Thanks for your bug report. Your observation is correct
and your solution for it is nearly complete. The
MibTable::undo_set_request method needs also to be fixed:

int MibTable::undo_set_request(Request* req, int& ind)
{
	MibLeaf* o;
	delete_rows.clear();
	int result = SNMP_ERROR_SUCCESS;
	for (int i=0; i < req->subrequests(); i++) {	
		if ((o = find(req->get_oid(i))) != 0) {
			int status = o->undo_set_request(req, i);
			if ((!result) && (status != SNMP_ERROR_SUCCESS))
			    result = status;
		}
	}
         // nothing to undo!
	return result;
}

It is not a locking problem, because a table can
obviously only be locked once. What was missing was
the cleanup for the other leafs in the table.

An update that includes this and another memory leak
fix for deserializing some leaf objects will be available
on Thursday.

Best regards,
Frank

Michael Grimes wrote:
> I believe I have discovered a memory leak that occurs when a row is 
> created.  I am
> sending a set request that contains 6 columns for the same index.  The 
> row status
> column is set to create and go.  Ultimately, the MibLeaf::set method is 
> called to set the
> column values.  In this method, undo is set to value->clone().  This is 
> the memory
> that is never deleted.  The undo for the 1st column in the request gets 
> deleted, but
> the remaining 5 columns do not.  In the Mib::process_prepare_set_request 
> method, it appears
> that only the 1st sub-request gets locked (req->set_locked(i, entry)).  
> Later, when the
> method Mib::process_cleanup_set_request is called, only the locked entry 
> gets a call to
> it's cleanup_set_request, where it's undo is eventually deleted.  I was 
> able to fix this leak
> by making the following change:
> 
> void MibTable::cleanup_set_request(Request* req, int& ind)
> {
>    MibLeaf *o;
> 
>    for (int i = 0; i < req->subrequests(); i++)
>    {
>       if ((o = find(req->get_oid(i))) != 0)
>       {
>          o->cleanup_set_request(req, i);
>       }
>    }
> 
>    delete_rows.clear();
> }
> 
> This removed the leftover undo's.  However, this is probably not the 
> preferred fix.
> I believe the problem is related to the locking.
> 
> Thanks for your help,
> Michael