Re: [Mjpeg-developer] jpeg-mmx problems

[Burkhard P. <pl...@ip...>]

William M. Brack wrote:
> I think I have found three problems in the sources of jpeg-mmx-0.1.6.  The
> symptom was that software running without problems under libjpeg failed
> (usually with a segfault) when using libjpeg-mmx, and Valgrind reported
> illegal memory accesses.

Very good that someone looks into this. We had, indeed, some problems, which
seem to come from a corrupted stack.

> 1) jdcolor.c, at about line 265 - an extra 'pushl  %%ebx' (i.e. no matching popl)

Hmmm, in the CVS version, I get:

# grep pushl jdcolor.c | wc -l
0

> 
> 2) jidctint.c, about line 1538, same problem

Here we have (CVS again):

Line 1545:         "pushl           %%ebx\n\t"
Line 2848:         "popl %%ebx                  \n\t"

pushl and popl are in the same function, so this should be ok.

> 3) jdcolor.c, about line 350 - the instruction 'movq %%mm3,6%0' -
>    This is a little more complicated.  If the output buffer is not a
>    mutiple of 8 bytes, this instruction can "spill over" the allocated size.
>    I have not come up with an appropriate fix - I just bypassed the problem
>    by assuring my buffer was larger than needed.

That's the YCbCr->RGB conversion. At least libquicktime doesn't use RGB
at all, so this could not have caused our crashes.
But the fact, that the RGB buffer must be larger than 3*width*height should
be documented.
For YCbCr, this isn't critical, since for this case, libjpeg always needs
buffers, which are a multiple of the DCT size.

But looking for push and pop might be a good idea to fix the jpeg-mmx
problems. If I knew assembler, I could do it :)

Cheers

Burkhard

-- 
_____________________________
Dr.-Ing. Burkhard Plaum
Institut fuer Plasmaforschung
Pfaffenwaldring 31
70569 Stuttgart
Tel.: +49 711 685-2187
Fax.:            -3102