Re: Patch for inf loop in rcsparse
Linas Vepstas <[email protected]> Tue, 25 Nov 2014 14:34:40 -0600
| Newsgroups | gmane.comp.version-control.subversion.cvs2svn.devel |
|---|---|
| Message-ID | <CAHrUA35MvDBmkHuSVtj43-+-NDBGv00DrrJB+A1_MWUEir-K=A@mail.gmail.com> |
------=_Part_1315_1622995084.1416955063336 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I had exactly one malformed-cvs error message printed: some file was tagged with multiple different version numbers. This message was not printed until after my fixes. I did not get the impression that it was related in any way, and it was easy to fix by manually editing the Entries file. (It was some cvs-experimentation file, and so was possibly put into this invalid state on purpose). I'll try to give the fix a whirl later this week, but am insanely behind in my work. --linas On Tue, Nov 25, 2014 at 3:01 AM, Michael Haggerty <[email protected]> wrote: > On 11/25/2014 09:59 AM, Michael Haggerty wrote: > > 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: > >> > >> > >> --- 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: > >> > >> # we stopped at the end of the buffer, so we may have a > partial token > >> buf = self.rcsfile.read(self.CHUNK_SIZE) > >> + if buf == '': > >> + # signal EOF by returning None as the token > >> + del self.buf # so we fail if get() is called again > >> + return None > >> lbuf = len(buf) > >> idx = end = 0 > >> > >> 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. > > Actually, thinking about this for a moment more, the bug you saw > probably happens if a token appears exactly at the end of any RCS file > and doesn't have to do with the CHUNK_SIZE. But I think such an RCS file > would be malformed, and *that* is why the bug is rare in practice. > > Michael > > -- > Michael Haggerty > [email protected] > > ------------------------------------------------------ http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1667&dsMessageId=3091839 To unsubscribe from this discussion, e-mail: [[email protected]]. ------=_Part_1315_1622995084.1416955063336 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div>I had exactly one malformed-cvs error message pr= inted: some file was tagged with multiple different version numbers.=C2=A0 = This message was not printed until after my fixes. I did not get the impres= sion that it was related in any way, and it was easy to fix by manually edi= ting the Entries file.=C2=A0 (It was some cvs-experimentation file, and so = was possibly put into this invalid state on purpose).<br><br></div>I'll= try to give the fix a whirl later this week, but am insanely behind in my = work.<br><br></div>--linas<br></div><div class=3D"gmail_extra"><br><div cla= ss=3D"gmail_quote">On Tue, Nov 25, 2014 at 3:01 AM, Michael Haggerty <span = dir=3D"ltr"><<a href=3D"mailto:[email protected]" target=3D"_blank">m= [email protected]</a>></span> wrote:<br><blockquote class=3D"gmail_quo= te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"= ><span class=3D"">On 11/25/2014 09:59 AM, Michael Haggerty wrote:<br> > On 11/21/2014 07:29 PM, Linas Vepstas wrote:<br> >> I tripped over an inf loop in the cvs2svn_rcsparse part of the cod= e.<br> >> The fix seems to be a simple cut-n-paste of an error check done a = few<br> >> dozen lines earlier.=C2=A0 The patch is:<br> >><br> >><br> >> --- a/cvs2svn_rcsparse/default.py.orig=C2=A0 =C2=A0 2014-11-21 12:= 18:02.880417060 -0600<br> >> +++ b/cvs2svn_rcsparse/default.py=C2=A0 =C2=A0 2014-11-21 12:26:59= .226222392 -0600<br> >> @@ -88,6 +88,10 @@ class _TokenStream:<br> >><br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # we stopped at the end of the b= uffer, so we may have a partial token<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 buf =3D self.rcsfile.read(self.C= HUNK_SIZE)<br> >> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 if buf =3D=3D '':<br> >> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # signal EOF by returning None= as the token<br> >> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 del self.buf=C2=A0 =C2=A0# so = we fail if get() is called again<br> >> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return None<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 lbuf =3D len(buf)<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 idx =3D end =3D 0<br> >><br> >> Without this, this particular block gets stuck in an infinite loop= .<br> >> Presumably, this is a rare, data-dependent ocurance ...<br> ><br> > Thanks for the email. Yes, it appears that the bug is triggered when a= <br> > token in an RCS file falls exactly on a CHUNK_SIZE boundary. Since<br> > CHUNK_SIZE is 100 kb, it is not surprising that nobody has reported th= is<br> > problem before.<br> <br> </span>Actually, thinking about this for a moment more, the bug you saw<br> probably happens if a token appears exactly at the end of any RCS file<br> and doesn't have to do with the CHUNK_SIZE. But I think such an RCS fil= e<br> would be malformed, and *that* is why the bug is rare in practice.<br> <div class=3D"HOEnZb"><div class=3D"h5"><br> Michael<br> <br> --<br> Michael Haggerty<br> <a href=3D"mailto:[email protected]">[email protected]</a><br> <br> </div></div></blockquote></div><br></div> ------=_Part_1315_1622995084.1416955063336--