Le duodi 22 frimaire, an CCXXV, Michael Niedermayer a écrit :
> OOM is a security issue under some(1) circumstances, one can hit OOM due
> to too many pixels (or streams), this specific issue is fixed by the
> options
> (1) For example a server process that dies due to it. Even if restarted
> this
On 13.12.2016 16:41, Michael Niedermayer wrote:
> On Sun, Dec 11, 2016 at 10:38:44PM -0500, compn wrote:
>> On Sun, 11 Dec 2016 17:39:58 +0100
>> Nicolas George wrote:
>>
>>> This reverts commit 2f07830e69bd14eaba348eb739b9503e7eb7cd4b.
>>
>> would you rather the people doing the fuzzing use this
On Sun, Dec 11, 2016 at 10:38:44PM -0500, compn wrote:
> On Sun, 11 Dec 2016 17:39:58 +0100
> Nicolas George wrote:
>
> > This reverts commit 2f07830e69bd14eaba348eb739b9503e7eb7cd4b.
>
> would you rather the people doing the fuzzing use this feature as a
> separate patch so it does not contamin
On Mon, Dec 12, 2016 at 09:16:54PM +0100, wm4 wrote:
> On Mon, 12 Dec 2016 21:00:19 +0100
> Michael Niedermayer wrote:
>
> > On Mon, Dec 12, 2016 at 12:04:05PM +0100, Nicolas George wrote:
> > > Le primidi 21 frimaire, an CCXXV, Michael Niedermayer a écrit :
[...]
> > completely independant of
On Mon, 12 Dec 2016 21:00:19 +0100
Michael Niedermayer wrote:
> On Mon, Dec 12, 2016 at 12:04:05PM +0100, Nicolas George wrote:
> > Le primidi 21 frimaire, an CCXXV, Michael Niedermayer a écrit :
> > > You misunderstand
> > >
> > > I want to find code that allocates too much memory where it sh
On Mon, Dec 12, 2016 at 12:04:05PM +0100, Nicolas George wrote:
> Le primidi 21 frimaire, an CCXXV, Michael Niedermayer a écrit :
> > You misunderstand
> >
> > I want to find code that allocates too much memory where it should
> > not.
> > to give an example
> > there was long ago some code like
>
2016-12-11 19:27 GMT+01:00 Nicolas George :
> To give an example, I think Anton, with his "evil plans", is
> good at seeing the big picture
To me, this seems like exactly the kind of offense that are
constantly asking to avoid.
Carl Eugen
___
ffmpeg-dev
Le primidi 21 frimaire, an CCXXV, Michael Niedermayer a écrit :
> You misunderstand
>
> I want to find code that allocates too much memory where it should
> not.
> to give an example
> there was long ago some code like
>
> len = read()
> for (i x= alloc()
> x.whatever =read()
> ...
>
Le primidi 21 frimaire, an CCXXV, compn a écrit :
> would you rather the people doing the fuzzing use this feature as a
> separate patch so it does not contaminate master?
I would rather have the people doing the fussing stop for a few minutes
to think what they need exactly and implement it prope
On Sun, 11 Dec 2016 22:38:44 -0500
compn wrote:
> On Sun, 11 Dec 2016 17:39:58 +0100
> Nicolas George wrote:
>
> > This reverts commit 2f07830e69bd14eaba348eb739b9503e7eb7cd4b.
>
> would you rather the people doing the fuzzing use this feature as a
> separate patch so it does not contaminate
On Sun, 11 Dec 2016 17:39:58 +0100
Nicolas George wrote:
> This reverts commit 2f07830e69bd14eaba348eb739b9503e7eb7cd4b.
would you rather the people doing the fuzzing use this feature as a
separate patch so it does not contaminate master?
-compn
___
f
On Sun, 11 Dec 2016 17:44:31 +0100
Michael Niedermayer wrote:
> On Sun, Dec 11, 2016 at 05:39:58PM +0100, Nicolas George wrote:
> > This reverts commit 2f07830e69bd14eaba348eb739b9503e7eb7cd4b.
> >
> > It was rushed and not properly designed.
>
> I strongly object to this patchset
>
> we nee
On Sun, Dec 11, 2016 at 07:27:26PM +0100, Nicolas George wrote:
> Le primidi 21 frimaire, an CCXXV, Michael Niedermayer a écrit :
> > Well, we need these options for efficient fuzzing
>
> We need SOMETHING, maybe, but not specifically THESE.
>
> > There are multiple independant things these optio
On 11.12.2016 20:19, Nicolas George wrote:
> Le primidi 21 frimaire, an CCXXV, Andreas Cadhalpun a écrit :
>> No, that doesn't solve the problem. It takes much more time until the
>> address space limit is reached than checking the resolution before
>> starting to allocate the memory.
>
> So basic
Le primidi 21 frimaire, an CCXXV, Andreas Cadhalpun a écrit :
> No, that doesn't solve the problem. It takes much more time until the
> address space limit is reached than checking the resolution before
> starting to allocate the memory.
So basically, this option solves the problem of fuzzers runn
On 11.12.2016 19:27, Nicolas George wrote:
> Le primidi 21 frimaire, an CCXXV, Michael Niedermayer a écrit :
>> Fuzzers search and find issues like out of array accesses but also
>> hangs and oom conditions.
>> Fuzzers find hangs and OOM conditions by executing code until it runs
>> out of memory o
Le primidi 21 frimaire, an CCXXV, Andreas Cadhalpun a écrit :
> It was tested and works well for its purpose.
Unfortunately, the purpose itself is wrong.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On 11.12.2016 17:39, Nicolas George wrote:
> This reverts commit 2f07830e69bd14eaba348eb739b9503e7eb7cd4b.
I'm against reverting this.
> It was rushed and not properly designed.
It was tested and works well for its purpose.
Best regards,
Andreas
___
f
Le primidi 21 frimaire, an CCXXV, Michael Niedermayer a écrit :
> Well, we need these options for efficient fuzzing
We need SOMETHING, maybe, but not specifically THESE.
> There are multiple independant things these options solve
> I belive i explained all already, but
You were vague. We only st
On Sun, Dec 11, 2016 at 05:47:34PM +0100, Nicolas George wrote:
> Le primidi 21 frimaire, an CCXXV, Michael Niedermayer a écrit :
> > we need these limit paramters for fuzzing to be practical.
>
> Maybe, but we can take a few days to do it properly instead of rushing a
> badly-designed "fix" that
Le primidi 21 frimaire, an CCXXV, Michael Niedermayer a écrit :
> we need these limit paramters for fuzzing to be practical.
Maybe, but we can take a few days to do it properly instead of rushing a
badly-designed "fix" that does not fix anything and then being forced
into a maintenance nightmare b
On Sun, Dec 11, 2016 at 05:39:58PM +0100, Nicolas George wrote:
> This reverts commit 2f07830e69bd14eaba348eb739b9503e7eb7cd4b.
>
> It was rushed and not properly designed.
I strongly object to this patchset
we need these limit paramters for fuzzing to be practical.
[...]
--
Michael GnuPG
This reverts commit 2f07830e69bd14eaba348eb739b9503e7eb7cd4b.
It was rushed and not properly designed.
Signed-off-by: Nicolas George
---
doc/codecs.texi | 4
libavcodec/avcodec.h | 8
libavcodec/options_table.h | 1 -
libavcodec/ut
23 matches
Mail list logo
