No subject

/*Determines the number of blocks or coefficients to be skipped for a given
token value.
_token:      The token value to skip.
_extra_bits: The extra bits attached to this token.
Return: A positive value indicates that number of coefficients are to be
skipped in the current block.
Otherwise, the negative of the return value indicates that
number of
blocks are to be ended.
0 will never be returned, so that at least one coefficient in one
block will always be decoded for every token.*/
int oc_dct_token_skip(int _token,int _extra_bits){

i.e., skip is never 0 by design. Part of the assumptions are that you
can only ever have at most one token per coefficient.

However, try changing oc_token_skip_eob6 (internal.c:121) to read:
static int oc_token_skip_eob6(int _token,int _extra_bits){
-  if(!_extra_bits)return -INT_MAX;
+  if(!_extra_bits)return -(INT_MAX>>1);
return -_extra_bits;
}
(The purpose of this code is described in section 7.7.1 of the spec.
Step 7(b) is not implemented literally, since that routine doesn't know
the number of coded blocks, much less the array TIS, which is never
explicitly constructed in my decoder implementation. It just returns a
really big number instead.)

This should prevent overflow in decoder.c:895
while(cfi+eobs<_ntoks_left[pli][_zzi]){

Alternatively that could be rewritten
while(eobs<_ntoks_left[pli][_zzi]-cfi){
But I'm not positive that's the only place using eobs could overflow. I
thought I checked, but clearly I missed at least one. Let's get rid of
all of them at once.

That should at least make the decoder fail somewhere _different_, and
hopefully make it stop segfaulting (part of the design goals are to
never segfault, even on completely invalid input). The real question is:
why did the decoder think there was an EOB run of length 0? The encoder
should never produce one.