On Sat, 2009-02-28 at 13:08 +1100, Brad Hards wrote:
> On Saturday 28 February 2009 12:59:27 pm Chuck Bohling wrote:
> > There are quite a few places in libmapi where talloc_free is not being
> > called with mapi_response. And in some places, the data returned to the
> > user is from the unfreed mapi_response.
> >
> > For example, in GetPropsAll
> >         *properties =
> > mapi_response->mapi_repl->u.mapi_GetPropsAll.properties;
> >
> > That's not correct is it? Doesn't the data need to be copied and then
> > mapi_response freed? Has this been fixed or will it be fixed in .9?
> I'm not sure I understand the question
> 
> If there was a copy, then the user would be responsible for free()ing the 
> copy. If we return a pointer, the user would free the original data.
> 
> Perhaps you can explain the problem again?

It looks like we are not discussing the same source code. In trunk
GetPropsAll returns data this way:

        reply = &mapi_response->mapi_repl->u.mapi_GetPropsAll;
        properties->cValues = reply->properties.cValues;
        properties->lpProps = talloc_steal((TALLOC_CTX 
*)session,reply->properties.lpProps);
        
        talloc_free(mapi_response);
        talloc_free(mem_ctx);
        return MAPI_E_SUCCESS;

Which basically means that we relocate parent memory context from
properties.lpProps and its children to the session pointer and makes
user responsible for freeing properties->lpProps after he finishes using
it.

This avoids leaking memory for mapi_response and associated remaining
parameters not being free'd. 

It is however possible this kind of change has not been propagated to
the whole API. A review for libmapi-0.8.1 would be worthwhile, but I
first encourage you to move to trunk. I have fixed a *lot* of memory
leaks after 0.8 ROMULUS release.

Cheers,
Julien.

-- 
Julien Kerihuel
[email protected]
OpenChange Project Manager

GPG Fingerprint: 0B55 783D A781 6329 108A  B609 7EF6 FE11 A35F 1F79

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
devel mailing list
[email protected]
http://mailman.openchange.org/listinfo/devel

Reply via email to