[FFmpeg-devel] [PATCH 2/2] avcodec/g2meet: Check for end of input in jpg_decode_block()

Michael Niedermayer michael at niedermayer.cc
Wed Oct 2 16:21:46 EEST 2019


On Mon, Sep 30, 2019 at 08:07:30PM +0200, Tomas Härdin wrote:
> lör 2019-09-28 klockan 17:47 +0200 skrev Michael Niedermayer:
> > On Thu, Sep 12, 2019 at 11:09:16PM +0200, Tomas Härdin wrote:
> > > tor 2019-09-12 klockan 00:21 +0200 skrev Michael Niedermayer:
> > > > On Wed, Sep 11, 2019 at 11:18:47PM +0200, Tomas Härdin wrote:
> > > > > tis 2019-09-10 klockan 16:16 +0200 skrev Michael Niedermayer:
> > > > [...]
> > > > > I've said multiple times that worrying about these timeout things is
> > > > > mostly a waste of time since any serious user will know to put time
> > > > > limits on jobs. 
> > > > 
> > > > Everyone probably has timelimits on jobs but these timeouts are still
> > > > a big problem. And i think this was discussed before ...
> > > > 
> > > > I think if you just think about what timeout to use for each case
> > > > A. a web browser loading image, video and audio files
> > > 
> > > Presumably browser devs know how to use TBB and friends. They also
> > > don't use g2meet, or cinepak, or anything else that isn't H.26* or VP*
> > > etc. Closest thing is GIF
> > > 
> > > > > Resources would be better spent gearing the fuzzing
> > > > > toward finding memory corruption issues, since the harm from them is
> > > > > far more serious.
> > > > 
> > > > Then fixing the timeouts would be a priority as they hold the fuzzer
> > > > up from finding other issues.
> > > > Time spend waiting for a timeout is time the fuzzer cannot search for
> > > > other issues
> > > 
> > > I see this more as a fuzzer tuning thing. When I last did fuzzing with
> > > afl I certainly made sure to give it tiny samples and not a lot of time
> > > per round
> > > 
> > > Question: is the fuzzer really allowed to spend 120 seconds on a test
> > > case like this one? Or is that timing just an after-the-fact thing?
> > 
> > The fuzzer has a timeout of 25 seconds IIRC. Thats on the machiene
> > google runs it on. So local times (which is what would be listed in a
> > patch) will always differ a bit
> 
> OK, that sounds a bit more reasonable.
> 
> > So what shall we do about these 2 patches here ?
> > Ok to push or do you want me to do something else ?
> 
> Nah go ahead. They don't seem to hurt, beyond being a few more lines of
> code.

ok will apply

thanks

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20191002/bdac0631/attachment.sig>


More information about the ffmpeg-devel mailing list