Re: Patch for inf loop in rcsparse
Linas Vepstas <[email protected]> Tue, 25 Nov 2014 14:52:11 -0600
| Newsgroups | gmane.comp.version-control.subversion.cvs2svn.devel |
|---|---|
| Message-ID | <CAHrUA36xVga9gX-bHEed2iEA0Kb9W_70iv0qL4cMg1FVsVP3OQ@mail.gmail.com> |
------=_Part_1318_773009821.1416955128026 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit N/M I just checked. It hits a different bug .. I added comments to github On Tue, Nov 25, 2014 at 2:34 PM, Linas Vepstas <[email protected]> wrote: > 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=3091840 To unsubscribe from this discussion, e-mail: [[email protected]]. ------=_Part_1318_773009821.1416955128026 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">N/M I just checked. It hits a different bug .. I added com= ments to github<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail= _quote">On Tue, Nov 25, 2014 at 2:34 PM, Linas Vepstas <span dir=3D"ltr">&l= t;<a href=3D"mailto:[email protected]" target=3D"_blank">linasvepstas@= gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir= =3D"ltr"><div><div>I had exactly one malformed-cvs error message printed: s= ome file was tagged with multiple different version numbers.=C2=A0 This mes= sage was not printed until after my fixes. I did not get the impression tha= t it was related in any way, and it was easy to fix by manually editing the= Entries file.=C2=A0 (It was some cvs-experimentation file, and so was poss= ibly 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.<sp= an class=3D"HOEnZb"><font color=3D"#888888"><br><br></font></span></div><sp= an class=3D"HOEnZb"><font color=3D"#888888">--linas<br></font></span></div>= <div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><br><div= class=3D"gmail_quote">On Tue, Nov 25, 2014 at 3:01 AM, Michael Haggerty <s= pan dir=3D"ltr"><<a href=3D"mailto:[email protected]" target=3D"_blan= k">[email protected]</a>></span> wrote:<br><blockquote class=3D"gmail= _quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:= 1ex"><span>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><div><br> Michael<br> <br> --<br> Michael Haggerty<br> <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected].= edu</a><br> <br> </div></div></blockquote></div><br></div> </div></div></blockquote></div><br></div> ------=_Part_1318_773009821.1416955128026--