On 08/01/15 23:03, Martin Storsjö wrote:
> On Thu, 8 Jan 2015, Luca Barbato wrote:
>
>> On 02/01/15 18:58, Martin Storsjö wrote:
>>> On Fri, 2 Jan 2015, Luca Barbato wrote:
>>>
>>>> On 02/01/15 17:04, Martin Storsjö wrote:
>>>>> On Fri, 2 Jan 2015, Martin Storsjö wrote:
>>>>>
>>>>>> On Fri, 2 Jan 2015, Luca Barbato wrote:
>>>>>>
>>>>>>> CC: libav-sta...@libav.org
>>>>>>> ---
>>>>>>>
>>>>>>> It is a really ridiculous corner case but happens in real life.
>>>>>>>
>>>>>>> libavformat/aviobuf.c | 4 ++--
>>>>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>>>
>>>>>>> diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
>>>>>>> index 6923b78..b7786f7 100644
>>>>>>> --- a/libavformat/aviobuf.c
>>>>>>> +++ b/libavformat/aviobuf.c
>>>>>>> @@ -125,8 +125,8 @@ static void flush_buffer(AVIOContext *s)
>>>>>>> {
>>>>>>> if (s->buf_ptr > s->buffer) {
>>>>>>> if (s->write_packet && !s->error) {
>>>>>>> - int ret = s->write_packet(s->opaque, s->buffer,
>>>>>>> - s->buf_ptr - s->buffer);
>>>>>>> + int len = FFMIN(s->buf_ptr - s->buffer,
>>>>>>> s->buffer_size);
>>>>>>> + int ret = s->write_packet(s->opaque, s->buffer, len);
>>>>>>> if (ret < 0) {
>>>>>>> s->error = ret;
>>>>>>> }
>>>>>>> --
>>>>>>> 2.1.0
>>>>>>
>>>>>> Hmm, looks like a pretty nasty issue if this happens - if this
>>>>>> happens
>>>>>> I think we might need to add a similar FFMIN() in a number of
>>>>>> different places as well. Can you pinpoint where the pointers end up
>>>>>> being set out of bounds?
>>>>
>>>> from what I could see you have avio_w8 doing
>>>>
>>>> write
>>>> pointer++
>>>> check if (pointer is >= end) and flush
>>>>
>>>> Flush uses start-pointer to decide the amount to write down.
>>>>
>>>> I'm not 100% sure when avio_seek do not trigger a flush when it
>>>> position itself right at the last byte of the buffer (the code is
>>>> sufficiently convoluted to warrant a refactor).
>>>
>>> Ok, that sounds like the potential cause, or if avio_write or some other
>>> function only needs a (pointer >= end) check at the end.
>>>
>>
>> I'd merge this patch and refactor later.
>
> Hmm, with this patch, doesn't it mean that the one byte written by
> avio_w8 is dropped/ignored/forgotten, so you basically write a corrupted
> output stream?
Apparently not and it itself is interesting since it should work as you
stated.
> Also, can you share what calling code causes this, i.e. what muxer does
> it happen with?
The code is an evil contraption to author DVD ifo, you can find it on my
github (as most of my code).
> Is it reproducible easily?
Sadly not, happened only on a 8GB image with some incredibly lucky layout.
lu
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
