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@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@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.