[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
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
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,
> > 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.
More information about the ffmpeg-devel