On Tue, Aug 12, 2014 at 07:56:36AM +0200, Christophe Gisquet wrote: > Hi, > > 2014-08-12 2:34 GMT+02:00 Michael Niedermayer <michae...@gmx.at>: > >> + if (pkt_size <= buf - orig_buf) { > > > > this isnt sufficient, there could be 1 byte space left, then the > > reallocate wouldnt run and encode_slice() would run into the extra > > padding and fail > > Yeah, you're right. I have no idea how big a slice can be, as that > seems the extra size check here. How about FF_MIN_BUFFER_SIZE ? > Then the growth would be FFMAX(FF_MIN_BUFFER_SIZE, buf - orig_buf) ?
the "serious undersizing" check already depends on the assumtation that FF_MIN_BUFFER_SIZE is larger than a slice, > > > I think either enough space should be allocated to begin with (like > > your patch 4) then the reallocation shouldnt be needed > > Yes, the intent of that code is to try and catch bugs like the one > fixed by patch 4. Even if it catches it, we want to fix the original > bug. > > > or the buffer could be allocated to an average size and reallocated > > when the encoder gets close to its end > > in which case reallocation also would not need a warning > > as it would be a normal operation > > I have mixed feeling over not warning (and asking a sample). Sure we > may catch most issues with reallocating, but we can't get a guarantee what i meant was that in case we knowingly allocate a smaller buffer than the max then reallocation would not be a "abnormal" condition and thus would not need a warning. smaller mallocs might be faster, so if for example a 50% sized buffer is enough for 99.9% of cases needing realloc only in 0.1% it might be faster to allocate less than the maximum but i made no benchmarks so it might be negligible ... > that the encode can complete (hence patch 1) in case of a serious > undersizing. Case in point: I had used a growth that was the maximum > between the quarter of the allocated size and twice the needed size, > and it crashed without patch 2. > > -- > Christophe > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel