At some stage (possibly commit r17268) oggpack_writecopy started to fail with some strings longer than 256 bytes and all strings longer than 512 bytes. Also it thrashes the stack with very long strings. Lithopsian
Actually, I'm certain r17270 is the culprit. I misapplied an overflow check correction pattern in line 202. I have a question about 'it thrashes the stack with very long strings'; is this an observed behavior, or are you looking at the code? I see that unaligned copies are being allocated inefficiently (I'll fix that too), but I'm not certain that matches your complaint. Monty On Wed, Apr 23, 2014 at 12:03 PM, Ian Nartowicz <ian at nartowicz.co.uk> wrote:> At some stage (possibly commit r17268) oggpack_writecopy started to fail with > some strings longer than 256 bytes and all strings longer than 512 bytes. Also > it thrashes the stack with very long strings. > > Lithopsian > _______________________________________________ > ogg-dev mailing list > ogg-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/ogg-dev
Or actually, 17268 did break it, then 17270 broke it worse :-) Monty On Thu, Apr 24, 2014 at 2:04 PM, Monty Montgomery <monty at xiph.org> wrote:> Actually, I'm certain r17270 is the culprit. I misapplied an overflow > check correction pattern in line 202. > > I have a question about 'it thrashes the stack with very long > strings'; is this an observed behavior, or are you looking at the > code? I see that unaligned copies are being allocated inefficiently > (I'll fix that too), but I'm not certain that matches your complaint. > > Monty > > > > On Wed, Apr 23, 2014 at 12:03 PM, Ian Nartowicz <ian at nartowicz.co.uk> wrote: >> At some stage (possibly commit r17268) oggpack_writecopy started to fail with >> some strings longer than 256 bytes and all strings longer than 512 bytes. Also >> it thrashes the stack with very long strings. >> >> Lithopsian >> _______________________________________________ >> ogg-dev mailing list >> ogg-dev at xiph.org >> http://lists.xiph.org/mailman/listinfo/ogg-dev
This bug should be fixed in r19119. The commit also adds unit tests that exercise copies across allocation boundaries. Give it a try, let me know if anything looks wrong behaviorally or otherwise. Monty On Wed, Apr 23, 2014 at 12:03 PM, Ian Nartowicz <ian at nartowicz.co.uk> wrote:> At some stage (possibly commit r17268) oggpack_writecopy started to fail with > some strings longer than 256 bytes and all strings longer than 512 bytes. Also > it thrashes the stack with very long strings. > > Lithopsian > _______________________________________________ > ogg-dev mailing list > ogg-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/ogg-dev
Looks good. Works on all my test strings up to 1MB. And about 30 times faster than looping on very long strings. --ian On Thu, 24 Apr 2014 17:02:17 -0400 Monty Montgomery <monty at xiph.org> wrote:>This bug should be fixed in r19119. The commit also adds unit tests >that exercise copies across allocation boundaries. > >Give it a try, let me know if anything looks wrong behaviorally or otherwise. > >Monty > >On Wed, Apr 23, 2014 at 12:03 PM, Ian Nartowicz <ian at nartowicz.co.uk> wrote: >> At some stage (possibly commit r17268) oggpack_writecopy started to fail with >> some strings longer than 256 bytes and all strings longer than 512 bytes. >> Also it thrashes the stack with very long strings. >> >> Lithopsian >> _______________________________________________ >> ogg-dev mailing list >> ogg-dev at xiph.org >> http://lists.xiph.org/mailman/listinfo/ogg-dev