Re: [fossil-users] Infinite loop on merge

2016-09-08 Thread Jan Nijtmans
2016-09-08 1:32 GMT+02:00 Ross Berteig:
> So my testing does not block releasing 1.35.1.
>
> I have no strong opinion about whether such an update is required, but the
> most recent regression does seem like it causes real problems if tripped
> over.

I agree, but it's not up to me to decide. Upcoming SQLite 3.14.2 might
be an additional excuse to do a fossil 1.35.1 release (although I don't
think fossil is actually affected by any of the fixed bugs since SQLite 3.13)

Regards,
   Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Infinite loop on merge

2016-09-07 Thread Ross Berteig

On 9/7/2016 1:15 AM, Jan Nijtmans wrote:


Would this be enough reason to do a quick 1.35.1 release? Two
regressions are already found plaguing 1.35 for situations
which worked fine in 1.34. Branch "branch-1.35" is ready,
the only thing missing there is updating changelog.wiki.


I built and tested branch-1.35 with MinGW and MSYS on Windows 10 Pro 
using the zlib from the tree with and without SSL support. Exactly two 
test cases report failures: merge-utf-79-23 and merge-utf-79-32. Nearly 
all released versions of fossil I've examined have a similar pair of 
failed test cases.


So my testing does not block releasing 1.35.1.

I have no strong opinion about whether such an update is required, but 
the most recent regression does seem like it causes real problems if 
tripped over.


On the pair of failed tests: nearly all released versions of fossil have 
failed a trial of the merge-utf-*-{23,32} cases. This is a family of 
merge tests built using source files drawn from the fossil test suite 
itself, which are hammered with random edits, merged, and validated. The 
use of the random number generator fuzzes through a lot of cases. 
Today's failure is the 79th fuzzing of utf.test. I strongly suspect that 
this exposes an edge case in the merge logic when dealing with (likely) 
broken UTF characters in one or more of the changes being merged.


Figuring out what is really going on there has been on my back burner 
for a while now, I may have to give in to curiosity (despite what that 
does to cats) and try to understand it one of these days.


--
Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/
+1 626 303 1602
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Infinite loop on merge

2016-09-07 Thread Jan Nijtmans
2016-09-07 5:17 GMT+02:00 Joel Bruick:
> This is the right fix. It ensures that each commit is only added to the
> queue by the recursive SELECT once instead of an exponential number of times
> based on how many merge commits it finds along the way, which is what caused
> your problem. I don't know why I used UNION ALL there, but it's definitely
> wrong.

Well, I noticed the lock-up as well, some weeks ago but didn't
bother to dig into it because I could do what I wanted to
do by merging the other way. Glad that it's fixed now! Thanks!

Would this be enough reason to do a quick 1.35.1 release? Two
regressions are already found plaguing 1.35 for situations
which worked fine in 1.34. Branch "branch-1.35" is ready,
the only thing missing there is updating changelog.wiki.

Regards,
 Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Infinite loop on merge

2016-09-06 Thread Joel Bruick

Hi Andy,


On 9/6/2016 3:26 PM, Andy Goth wrote:
That seems to fix it. Thank you very much for the astonishingly fast 
turnaround. There may be unintended consequences since we haven't 
done much analysis yet, so I checked your change in on the 
merge-rename-lockup branch pending further testing.


On Tue, Sep 6, 2016 at 2:20 PM, Richard Hipp > wrote:


On 9/6/16, Andy Goth > wrote:
>
> The repository is private, sorry, but I should be able to help with
> debugging.
>

Just a guess:

Index: src/merge.c
==
--- src/merge.c
+++ src/merge.c
@@ -395,11 +395,11 @@
   }
   if( zPivot ){
 vAncestor = db_exists(
   "WITH RECURSIVE ancestor(id) AS ("
   "  VALUES(%d)"
-  "  UNION ALL"
+  "  UNION"
   "  SELECT pid FROM plink, ancestor"
   "   WHERE cid=ancestor.id  AND pid!=%d
AND cid!=%d)"
   "SELECT 1 FROM ancestor WHERE id=%d LIMIT 1",
   vid, nid, pid, pid
 ) ? 'p' : 'n';



This is the right fix. It ensures that each commit is only added to the 
queue by the recursive SELECT once instead of an exponential number of 
times based on how many merge commits it finds along the way, which is 
what caused your problem. I don't know why I used UNION ALL there, but 
it's definitely wrong.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Infinite loop on merge

2016-09-06 Thread Richard Hipp
On 9/6/16, Andy Goth  wrote:
>
> The repository is private, sorry, but I should be able to help with
> debugging.
>

Just a guess:

Index: src/merge.c
==
--- src/merge.c
+++ src/merge.c
@@ -395,11 +395,11 @@
   }
   if( zPivot ){
 vAncestor = db_exists(
   "WITH RECURSIVE ancestor(id) AS ("
   "  VALUES(%d)"
-  "  UNION ALL"
+  "  UNION"
   "  SELECT pid FROM plink, ancestor"
   "   WHERE cid=ancestor.id AND pid!=%d AND cid!=%d)"
   "SELECT 1 FROM ancestor WHERE id=%d LIMIT 1",
   vid, nid, pid, pid
 ) ? 'p' : 'n';

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Infinite loop on merge

2016-09-06 Thread Andy Goth
The latest trunk is broken (w.r.t. the merge in question), as is apparently
everything starting with 41c2220934. Version 1.34 is good, as is the
version immediately before 41c2220934. I see no reason to downgrade to
anything before 1.34, since that's what I've been using successfully since
its release.

On Tue, Sep 6, 2016 at 2:11 PM, Richard Hipp  wrote:

> On 9/6/16, Andy Goth  wrote:
> >
> > Today I upgraded from Fossil 1.34, and it
> > looks like I'm going to have to switch back.
> >
>
> Try using trunk before you downgrade to 1.33 or 1.32.
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>



-- 
Andy Goth | 
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] Infinite loop on merge

2016-09-06 Thread Richard Hipp
On 9/6/16, Andy Goth  wrote:
>
> Today I upgraded from Fossil 1.34, and it
> looks like I'm going to have to switch back.
>

Try using trunk before you downgrade to 1.33 or 1.32.
-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users