Re: fs-rep-sharing infinite loop (again)

C. Michael Pilato wrote:
> Hyrum K. Wright wrote:
>> In working on the fs-rep-sharing branch, I've stumbled into a problem with bdb
>> post-commit deltification. When loading r2555 of the Subversion repository, I
>> get what appears to be an infinite loop in read_rep_range() in
>> subversion/libsvn_fs_base/reps-strings.c, specifically in the inner loop which
>> collects reps needed to perform undeltifiacation. This occurs when processing
>> /trunk/subversion/libsvn_wc/log.c.
>>
>> I'm sending this here so that other interested parties can take a look, and so
>> that I don't forget the result of my analysis.
>
> [NOTE: I've not looked into the code yet]
>
> /trunk/subversion/libsvn_wc/log.c wasn't modified in r2555. But a branch
> version thereof was in r2554. The history of log.c on the branch at that
> point is short-lived -- it was the first modification to the file since the
> branchpoint. Here's a map of the ancestry around that time period:
>
>
> ,-------*------ branches/issue-749-dev
> / 2554
> -----*------*-------*-----*----*----------- trunk
> 2416 2452 2470 2523 2524
>
> Now, interestingly, r2524 (on trunk) reverted r2470 and r2452. So the
> contents of log.c are the same in r2416 and r2524, and likely share a
> representation on your branch:
>
> ,-------*------ branches/issue-749-dev
> / 2554
> -----*------*-------*-----*----*----------- trunk
> 2416 2452 2470 2523 2524
> ^ |
> | |
> `- - - - - - - - - - - - -'
>
> My guess is that the problem is actually caused by the handling of r2524,
> but maybe not seen until r2554 tries to get deltified (or perhaps
> re-deltified). But it's just a guess.

Yep. If you load up to r2524, you'll find that you can't now do an
incremental dump of r2524 without hitting the loop. And it isn't always the
log.c loop that you get stuck in. Other files are using shared reps, too,
such as libsvn_wc/adm_files.h.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand