[Theora-dev] Re: [Theora] Small memory leak...

Ralph Giles giles at xiph.org
Wed Oct 26 13:51:46 PDT 2005


On Wed, Oct 26, 2005 at 09:23:59AM +0200, Mat wrote:
> 
> Hi all.
> In  lib\encoder_toplevel.c , row 1123-1128:
> 
> #ifndef LIBOGG2
>  /* So we're expecting the application with free this? */
>  op->packet=malloc(oggpack_bytes(opb));
>  memcpy(op->packet, oggpack_get_buffer(opb), oggpack_bytes(opb));
>  oggpack_writeclear(opb);
> #else

Right. As the comment says, the caller has to free this to avoid 
leaking (but not if building against libogg2). This is contrary
to what the API docs says:

  op 	An ogg_packet structure to fill. libtheora will set all elements 
	of this structure, including a pointer to the encoded comment data.
	The memory for the comment data is owned by libtheora.

So for now, you should just free it yourself, but I've opened 
http://trac.xiph.org/cgi-bin/trac.cgi/ticket/726 against the
ambiguity. Suggested resolutions welcome.

> I tried also:
>    op->packet=_ogg_malloc(oggpack_bytes(opb));

You're correct that this should be an _ogg_malloc(). I've committed the 
change to svn. In host-based use there's not a lot of difference, we 
just use the libogg wrapper for the convienience of those who want to
replace the memory management.

> But I got always this leak.
> How should I free that space ?
>    _ogg_free(op->packet);
> In the end of my application doesn't work... segmentation fault.
> I can't go on if I don't solve this so help me please...

This is the correct way to free it (assuming the linker finds _ogg_free, 
anyway.) It's hard to tell without seeing your code, but is the 
op->packet you free at the end the same one theora_encode_comment() 
allocated, or have you reused the op struct in other calls since?
That might explain the segfault.

> In alternative I could avoid this function if possible... but I don't 
> know how.

No, it's required to produce an encoded stream, you just have to find 
where you're leaking the buffer.

HTH, 
 -r


More information about the Theora-dev mailing list