[FFmpeg-devel] lurking bugs in the mmx-related assembler code (?)

u-h8zb at aetey.se u-h8zb at aetey.se
Mon Oct 3 11:14:36 EEST 2016


On Sun, Oct 02, 2016 at 10:59:31PM -0400, compn wrote:
> vp3 is a decoder written 10+ years ago by a dev who is no longer
> active in ffmpeg.
> 
> we have many decoders and encoders (and other code) in ffmpeg that have
> not been audited (to my knowledge).
> 
> i know this isnt an excuse for not looking at the code. just letting
> you know the history.

Sure, I know the code is old (it is even documented as such).

> please dont think carl's tone is unpleasant, maybe he is just
> incredulous.

Thanks for this comment. I am well aware of how hard it is to weight
emotion-loaded expressions, especially when someone else looks wrong in
one's expected area of competence.

> carl has tested and verified thousands of bugs for ffmpeg. carl also
> fixes some of them.

I was quite aware of Carl's qualities, but they are surely nice to mention.

> carl would like to reproduce the bug. reproducing the bug with an easy
> command line, on a dev computer usually makes the bug finding and fixing
> quicker.

Sure. This is though (in my very humble opinion) a special kind of bug,
where Carl did not have to chase the "offending code" in the C library
(it is not the C library which is at fault) but directly look at
libavcodec/x86/vp3dsp.asm and the places where it is used.

OTOH everything seems to go very well and I am looking forward to some
elegant solution, with confidence.

> > To give you an example of successful code auditing, the corresponding
> > UB-problem in libtheora was properly fixed without anybody at Xiph
> > having to install musl.
> > That's why I still believe that auditing the code is more useful than

This can look misleading, sorry for that.

I meant, auditing particular parts of the code, for the actual,
identified problem.

> > hunting once again the hard-to-pinpoint symptoms of the already known
> > cause.
> 
> do you have any suggestions for how the ffmpeg project could do
> successful code audits?

I would like to, but regrettably I do not have any bright ideas about this
"in general". Auditing is hard.

To look at the assembler routines and check for a particular UB,
whether the FPU state is restored before calling C library,
this has a limited scope and is what I suggested.

> i really dont see much enthusiasm for line by line code auditing within
> ffmpeg. in fact, i'd say people would rather re-write an entirely new
> piece of code than try to clean up the old code. this isnt a knock on
> anyone or any piece of code, just my observation.

I can only agree with every word.

Regards,
Rune



More information about the ffmpeg-devel mailing list