<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014-12-11 14:34 GMT+01:00 Miroslav Lichvar <span dir="ltr"><<a href="mailto:mlichvar@redhat.com" target="_blank">mlichvar@redhat.com</a>></span>:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On Thu, Dec 11, 2014 at 11:12:25AM +0100, Martijn van Beurden wrote:<br>
> Op 11-12-14 om 10:53 schreef Martijn van Beurden:<br>
> > Op 11-12-14 om 10:05 schreef Miroslav Lichvar:<br>
> >> but I'd rather see the real seeking bug fixed instead<br>
> ><br>
> > I think I might have a fix [...]<br>
<br>
So the problem is that FLAC__stream_decoder_process_single returns<br>
error before it finds a valid frame?<br></blockquote><div><br></div><div><div>I'm not sure whether we mean the same thing, but I think the problem is that seek_to_absolute_sample_ calls FLAC__stream_decoder_process_single, which calls read_frame_, which calls read_subframe_, which calls either read_subframe_fixed_ or read_subframe_lpc_, which call read_residual_partitioned_rice_. The return false set there is propagated all the way down.</div><div><br></div><div>So, because the decoding of the frame is aborted upon finding a situation in which a heap overflow might be in order (but which will usually just be a bogus header), the decoder considers the seeking proces failed.<br></div></div><div><br></div><div>This is only a problem with seeking and not with normal decoding, because in a valid stream, the decoder doesn't have to look for a header (so it doesn't have the chance to run into a fake one) because the next header is always right after the previously decoded frame.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
> Another solution might be to 'just try again' somewhere else<br>
> when seeking fails, but maybe there are good reasons not to do<br>
> so? The decoder might get stuck in a loop?<br>
<br>
I think that would be a reasonable solution.<br>
<br>
In one iteration of the root-finding algorithm, don't give up when<br>
decoding fails, but try also a limited number of different positions<br>
(say 10) dividing the interval between the lower and upper bound<br>
evenly. Does that make sense?</blockquote><div><br></div><div>Yes, I think it does.</div></div></div></div>