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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
