On Sun, Nov 26, 2017 at 01:14:31AM +0100, Carl Eugen Hoyos wrote: > 2017-11-24 20:45 GMT+01:00 Derek Buitenhuis <derek.buitenh...@gmail.com>: > > 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: > > > > https://gist.github.com/dwbuiten/7101755 > > > > Optionally takes two env vars, MALLOC_SEED (the seed), and MALLOC_FAILPROB > > for the > > probability of failing. > > > > I've been running it directly integrated inside FFmpeg's allocator because > > it makes > > it easier to run under gdb to find where it actually crashes, if the stack > > trace of > > the failure is not enough info/context. > > > > Currently FFmpeg has a lot of unchecked allocations - just one single FATE > > run with > > this found: > > I am of course in favour of such checks but is there an allocator we support > that actually returns NULL on oom?
try ulimit -S -v 10000 and then try to malloc() more [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel