[Theora-dev] Experimental decoder

[Tristan Wibberley]

<40F09A4C.7060501 at vt.edu>
Message-ID: <1089543888.867.40.camel at localhost>

On Sun, 2004-07-11 at 02:39, Timothy B. Terriberry wrote:
> More testing is, by all means, useful. If I had to guess I'd say this
> was an encoder bug. It'd be nice to have the exact source and encoding
> paramters, as it will likely require re-encodes to debug.

I've encoded a stream the exhibits a lot of psychodelic colours, and player_example
segfaults with this:

Ogg logical stream 300bcb8c is Theora 352x208 25.00 fps video
Encoded by derf's experimental encoder library Jul  7 2004
Ogg logical stream 39b452c6 is Vorbis 2 channel 48000 Hz audio.

Program received signal SIGSEGV, Segmentation fault.
0x0804f90e in oc_dec_ac_coeff_unpack (_dec=0x8088158, _zzi=1,
_huff_idxs=0xbffff3a0, _ntoks_left=0xbffff3b0)
at ../lib/decode.c:902
902           _dec->dct_tokens[_zzi][ti++]=(char)token;
(gdb) p _dec->state.nfrags
$10 = 1716
(gdb) p ti
$11 = 511141

Hm, that value of ti looks way too high (from my reading of the source).

(gdb) p pli
$12 = 0
(gdb) p _ntoks_left[pli][_zzi]
$13 = 283
(gdb) p cfi
$14 = 99
(gdb) p eobs
$15 = -2146972505

that could be it :)

(gdb) p _dec->eob_runs[_zzi]
$16 = 0

When playing outside the debugger, I get:

Ogg logical stream 300bcb8c is Theora 352x208 25.00 fps video
Encoded by derf's experimental encoder library Jul  7 2004
Ogg logical stream 39b452c6 is Vorbis 2 channel 48000 Hz audio.
Fatal signal: Segmentation Fault (SDL Parachute Deployed)
free(): invalid pointer 0x80efc40!
free(): invalid pointer 0x80f68d8!
Segmentation fault

Those pointers look good, so it could be a clobbered heap in the player making
_ntoks_left[pli][_zzi] be too big, or that being too big and clobbering the heap :(

I did another run, this time, strangely, ti = 511140, but the other numbers are
the same.

I can't see myself yet what's causing this, but I hope this information can help.
I'm afraid I don't know where to put asserts in the decoder/encoder to see if this
can be caught, but I'll keep reading the source :)

I did notice that this looks iffy though:

if(skip<0)eobs-=skip;
else{
run_counts[skip-1]++;
cfi++;
}

since (unless skip can never be 0) it could do (*(run_counts - 1))++; that would
increment cfi twice instead of once on this platform (PC - though I haven't checked
the assembler yet).

--
Tristan Wibberley