Re: Patch for inf loop in rcsparse

Michael Haggerty <[email protected]> Tue, 25 Nov 2014 09:59:05 +0100
Newsgroups gmane.comp.version-control.subversion.cvs2svn.devel
Message-ID <[email protected]>
On 11/21/2014 07:29 PM, Linas Vepstas wrote:
> I tripped over an inf loop in the cvs2svn_rcsparse part of the code.
> The fix seems to be a simple cut-n-paste of an error check done a few
> dozen lines earlier.  The patch is:
>=20
>=20
> --- a/cvs2svn_rcsparse/default.py.orig    2014-11-21 12:18:02.880417060 -=
0600
> +++ b/cvs2svn_rcsparse/default.py    2014-11-21 12:26:59.226222392 -0600
> @@ -88,6 +88,10 @@ class _TokenStream:
>=20
>          # we stopped at the end of the buffer, so we may have a partial =
token
>          buf =3D self.rcsfile.read(self.CHUNK_SIZE)
> +        if buf =3D=3D '':
> +          # signal EOF by returning None as the token
> +          del self.buf   # so we fail if get() is called again
> +          return None
>          lbuf =3D len(buf)
>          idx =3D end =3D 0
>=20
> Without this, this particular block gets stuck in an infinite loop.
> Presumably, this is a rare, data-dependent ocurance ...

Thanks for the email. Yes, it appears that the bug is triggered when a
token in an RCS file falls exactly on a CHUNK_SIZE boundary. Since
CHUNK_SIZE is 100 kb, it is not surprising that nobody has reported this
problem before.

I changed your patch a little bit because if an EOF occurs at this
point, part of a token has already been read, so it is not correct to
return None (even though it probably makes no difference in practice).
So instead I return the token that has been read so far and set up the
instance to return None on the next call to get().

I pushed the fix to GitHub at

    https://github.com/mhagger/cvs2svn branch "rcsparse-eof-handling"

Please let me know if this fix works for you.

Yours,
Michael

--=20
Michael Haggerty
[email protected]

------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=3D1667&dsMessageId=3D=
3091817

To unsubscribe from this discussion, e-mail: [[email protected]=
s.org].