On 11/25/2017 12:07 AM, Michael Niedermayer wrote:
> I do not know that but i would be surprised if null dereferences tests
> where unwelcome
>
> oss-fuzz will already report null derferences and OOM conditions, as
> well as undefined behavior. So in some sense various points on the map
> surround
On 11/25/2017 12:07 AM, Michael Niedermayer wrote:
> I do not know that but i would be surprised if null dereferences tests
> where unwelcome
>
> oss-fuzz will already report null derferences and OOM conditions, as
> well as undefined behavior. So in some sense various points on the map
> surround
2017-11-26 2:05 GMT+01:00 Derek Buitenhuis :
> On 11/26/2017 12:14 AM, Carl Eugen Hoyos wrote:
>> I am of course in favour of such checks but is there an allocator we support
>> that actually returns NULL on oom?
>
> Anything that doesn't use overcommit. Windows is the big obvious one here.
> Also
On 11/26/2017 12:14 AM, Carl Eugen Hoyos wrote:
> I am of course in favour of such checks but is there an allocator we support
> that actually returns NULL on oom?
Anything that doesn't use overcommit. Windows is the big obvious one here. Also
various UNIX-like things, and even Linux is not guaran
On Sun, Nov 26, 2017 at 01:14:31AM +0100, Carl Eugen Hoyos wrote:
> 2017-11-24 20:45 GMT+01:00 Derek Buitenhuis :
> > I've had this kicking around for like 4 years, maybe it can be of use to
> > some people.
> > I haven't done full scale fuzzing with this because laziness. I just
> > sometimes ru
2017-11-24 20:45 GMT+01:00 Derek Buitenhuis :
> I've had this kicking around for like 4 years, maybe it can be of use to some
> people.
> I haven't done full scale fuzzing with this because laziness. I just
> sometimes run it
> when I'm bored. It's not thread-safe, but it would be trivial to make
On 11/24/2017 11:35 PM, Derek *Buitenhuis* wrote:
> It would probably make an absolute ton of reports, since there are quite
> a few unchecked allocs in FFmpeg... might be kinda spammy.
That might not be the case any more, most of the checks have been added in
the Coverity effort of 2015 and cont
On Fri, Nov 24, 2017 at 11:41:06PM +, Derek Buitenhuis wrote:
> On 11/24/2017 11:35 PM, Michael Niedermayer wrote:
> > Maybe integrating this in:
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> >
> > would make sense
> >
> > That would run it automatically on ffmpeg maste
On 11/24/2017 11:35 PM, Michael Niedermayer wrote:
> Maybe integrating this in:
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>
> would make sense
>
> That would run it automatically on ffmpeg master HEAD on powerfull hw
Could make sense, yeah - wouldn't be that hard.
It woul
On Fri, Nov 24, 2017 at 07:45:46PM +, Derek Buitenhuis wrote:
> I've had this kicking around for like 4 years, maybe it can be of use to some
> people.
> I haven't done full scale fuzzing with this because laziness. I just
> sometimes run it
> when I'm bored. It's not thread-safe, but it woul
On 11/24/2017 8:09 PM, Paul B Mahol wrote:
> Do you have backtrace of this one?
Yes, but the alloc failure is not in lavfi:
my_posix_memalign:77 in libavutil/posixmemalign.c
av_malloc:89 in libavutil/mem.c
av_mallocz:240 in libavutil/mem.c
av_packet_alloc:53 in libavcodec/avpacket.c
av_bsf_alloc:
On 11/24/17, Derek Buitenhuis wrote:
> I've had this kicking around for like 4 years, maybe it can be of use to
> some people.
> I haven't done full scale fuzzing with this because laziness. I just
> sometimes run it
> when I'm bored. It's not thread-safe, but it would be trivial to make it so.
>
I've had this kicking around for like 4 years, maybe it can be of use to some
people.
I haven't done full scale fuzzing with this because laziness. I just sometimes
run it
when I'm bored. It's not thread-safe, but it would be trivial to make it so.
It's based off my old LD_PRELOAD hack from here
13 matches
Mail list logo
