[vorbis-dev] Question re: vorbis_block_clear()

[Jeff Squyres]

I'm running into memory leak and read-from/write-to unallocated errors in
the cleanup phase of parallel oggenc.

I see in vorbis_block_clear() that it references some fields on the
vorbis_dsp_state that it cached during vorbis_block_init(), and
conditionally does some cleanup based on the values of those fields.

Does this fact effectively mean that you can't have multiple vorbis_block
instances outstanding?  i.e., can you only reliably vorbis_block_clear()
the *last* vorbis_block that went through vorbis_analysis()?

I ask because I separate the analysis from the output/cleanup in poggenc.
Hence, I can have a list of vorbis_block/ogg_packet pairs queued up for
later output and cleanup.  Invoking vorbis_block_clear() on these blocks
seems to result in verious forms of Badness (read from unallocated and the
like, since I didn't keep the corresponding vorbis_dsp_state instances
around).  But just free()ing these vorbis_blocks results in lots of memory
leaks, since the storage inside the vorbis_block is still allocated.

Any suggestions?

Monty: will the thread-safety stuff that you're working on fix this?
i.e., will vorbis_blocks no longer reference/depend on the
vorbis_dsp_state?  How far off is that stuff?

{+} Jeff Squyres
{+} squyres at cse.nd.edu
{+} Perpetual Obsessive Notre Dame Student Craving Utter Madness
{+} "I came to ND for 4 years and ended up staying for a decade"

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.