On Mon, May 15, 2017 at 05:55:28PM +0000, Rob Meyers wrote: > Of course. > > We noticed when reading data from a named pipe the first 10 bytes would get > dropped.
from were are bytes droped ? this is the internal buffer, not something a user should touch directly. > I traced this to the affected code in fill_buffer(). The > assignment of "dst" was always set to the beginning of the buffer, and if The buffer pointer resets to the start if there is not enough space available to hold another packet. with your patch it resets either always or when the buffer is filled to the last byte randomly truncating a read. If the read function is incapable to fullfill the partial packet read that will not work out i think But i may be missing something of course > it hadn't been consumed yet the data would be overwritten. We could > reproduce this by setting up a server that writes to the named pipe in two > small (6 byte) messages with a 1 second gap between. Without the gap, or if > the data is sent as one message, there's no problem. It's in the > accumulation of data between messages to fulfill a read that this bug is > triggered. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
