Vorbis dev - Jan 2001 - Question re: vorbis_block_clear()

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.

> 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()?
If that's the way it is, it's a bug and I'll fix it.  Your basic
strategy is right, haven't seen the code to see if there are any
mistakes.
> 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?
It still has to reference the vorbis_dsp_state to get to configuration
information, but that's a read-only reference. 

vorbis_block_clear affects only the vorbis_block.  It doesn't touch
the vorbis_dsp_state.

Monty

--- >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.