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

[u-h8zb at aetey.se]

Thanks Michael,

On Sun, Oct 02, 2016 at 02:25:30AM +0200, Michael Niedermayer wrote:
> beyond malloc() what else is there ?
> 
> string functions ?
> these are in fact not unlikely to use SIMD of some sort
> same for memcpy/move()
> 
> also there are callbacks like av_log() we should document any
> requirements that apply to them or ensure no such requirements exist
> 
> exact backtraces of where issues occur would be interesting to better
> understand how much code is affected by this

Regarding backtraces of the ill effects, I made an effort when I earlier
hit the same issue with libtheora (the fpu corruption seemed to affect
consistency in picking malloc buckets). The noticeable problems happened
with a delay, eventually causing accesses to quite random places in the
address space, often without any troubles for a while. Hideous and out
of the application code, it is the libc which must be carefully traced.

As for how much of ffmpeg code is affected, I can't tell.
The vp3/theora decoder is certainly in this group but there may be more.
The exact place where the corruption happens is hard to point out,
this depends too much on the particular situation.

> > What if we simply document the requirement that C standard library
> > functions are assumed to not modify the x87 FPU state unless
> > specifically designated to handle floating-point numbers?
> 
> thats like saying that we require undefined behavior to be defined
> in a specific way. We can do this but thats like saying we support
> only a subset of POSIX platforms and that subset could shrink at
> any time if implementations change

Exactly.

> If all else fails we could add a emms call behind #if in
> av_malloc() and detect affected libcs but thats IMHO a ugly hack
> but better than declaring "non support"

This would help to somewhat boost performance on those libraries and
versions which e.g. are known not to touch fpu, but I wonder if this
gain is worth the trouble.

Thanks again.

I hope you find a reasonable solution, without undue complication of
the code and preserving the performance.

Regards,
Rune