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

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

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

Hello Carl Eugen, On Sun, Oct 02, 2016 at 04:01:21PM +0200, Carl Eugen Hoyos wrote: > > I do not expect that the ffmpeg developers take the trouble > > to install an extra build environment with a different libc, > > (If I could just understand this sentence: Is it meant as > an insult? How do

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

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

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

Hello Carl Eugen, On Sun, Oct 02, 2016 at 03:05:13AM +0200, Carl Eugen Hoyos wrote: > 2016-10-01 19:48 GMT+02:00 : > > I do not expect the ffmpeg developers to try to reproduce this. > > (Would you mind explaining this sentence to me? I > do not understand it.) I do not expect

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

On Sat, Oct 01, 2016 at 06:25:29PM -0400, Ronald S. Bultje wrote: > > We are not talking about what you and me "would like inside a standard > > library" but whether we can rely on the specified interfaces. The > > malloc() interface was apparently misunderstood as a promise to never > > do float.

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

Hello Ronald, On Sat, Oct 01, 2016 at 03:11:38PM -0400, Ronald S. Bultje wrote: > I'm not sure we want to go down the rabbit hole of allowing any code to be > executed inside frame en/decoding routines. Historically, IIRC, we have > disallowed float in user callbacks like request_frame also. > >

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

Hello, It looks like some general information is due: Musl libc is a high quality standard C library for Linux with emphasis on "quality" and "standard" http://www.musl-libc.org/ On Sat, Oct 01, 2016 at 12:31:05PM -0400, Ronald S. Bultje wrote: > > This means when malloc()/free()/... happens

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

Hello Moritz, On Sat, Oct 01, 2016 at 06:13:46PM +0200, Moritz Barsnick wrote: > On Sat, Oct 01, 2016 at 17:37:50 +0200, u-h...@aetey.se wrote: > > My troubleshooting > [...] > > behaves erratically on certain combinations > [...] > > Most often > > You are a busy troubleshooter, but you fail

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

On Sat, Oct 01, 2016 at 05:44:13PM +0200, wm4 wrote: > AFAIK most MMX code in FFmpeg does not run emms (i.e. keeps the FPU > state trashed) until returning to the API user. This means when malloc()/free()/... happens to be called internally, it corrupts the malloc structures, in a

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

Hello, Would someone familiar with the mmx assembler parts of ffmpeg look over and check that the fp-state is restored as needed? This is crucial with musl libc which uses floating point in its malloc() implementation. My troubleshooting strongly suggests that it is the mmx code which is the