Jason Wong wrote on Thu, Feb 16, 2012 at 11:42:42 -0800:
> On Wed, Feb 15, 2012 at 6:15 PM, Daniel Shahaf <danielsh_at_elego.de> wrote:
> > Jason Wong wrote on Wed, Feb 15, 2012 at 10:20:23 -0800:
> >> On Wed, Feb 8, 2012 at 6:22 PM, Nico Kadel-Garcia <nkadel_at_gmail.com> wrote:
> >> > On Wed, Feb 8, 2012 at 7:42 PM, Daniel Shahaf <danielsh_at_elego.de> wrote:
> >> >> Daniel Shahaf wrote on Thu, Feb 09, 2012 at 01:46:45 +0200:
> >> >>> Jason Wong wrote on Wed, Feb 08, 2012 at 15:32:05 -0800:
> >> >
> >> >>> Get xxd.exe from http://www.vim.org/ and cat.exe and sed.exe from
> >> >>> http://gnuwin32.sf.net (or from Cygwin). Delete from the script the
> >> >>> line that uses the 'head' command.
> >> >>
> >> >> There is a second use of 'head', which you shouldn't delete. So
> >> >> instead, just get head.exe from the same place as the other two, or use
> >> >> the following kind of statement:
> >> >
> >> > Or install CygWin and run the scripts from inside CygWin. This does
> >> > present end-of-line issues, so be very careful about using "svn:eol
> >> > native" properties.
> >> >
> >> >>
> >> >> my $line = do {
> >> >> open FOO, "perl -V 2>&1 |";
> >> >> <FOO>;
> >> >> };
> >> >>
> >> >> Lastly, there's a 'sed' invocation that uses single-quoted arguments.
> >> >> All it does is "print the input up to the first empty line" --- feel
> >> >> free to implement it differently. (One way:
> >> >>
> >> >> my @lines = split /\n/, `command | goes | here`;
> >> >> $_ and print or last for @lines;
> >> >>
> >> >> Both of these examples could do with some error checking.)
> >> >>
> >> >> Daniel
> >> >> (yes, there's also a neater way to do this without split(). but it's
> >> >> not a Perl class here)
> >>
> >> Hello.
> >>
> >> Sorry for the delay. Here is an update of what I have done since
> >> the last time I posted.
> >>
> >> I have run "svn log -q ^/" on the respository and it came back with
> >> no missing revisions.
> >>
> >
> > I stand corrected, then. I've confirmed on another instance of the bug
> > that 'svn log -q ^/' does not behave abnormally when the bug is present.
> > Sorry for the misinformation.
> >
> > Question to devs: what operation will walk the predecessor links for
> > the root fspath? (and can therefore be used to identify instances of
> > the bug)
> >
> >> Since I first posted, each of the projects we have tried to build
> >> that had failed have since successfully been built without any changes
> >> on our side.
> >>
> >
> > What is the significance of this? I don't know how your build process
> > interacts with Subversion.
> >
> >> I was having an issue with converting the script to run in windows as
> >> I was only getting the first line returned so I set up cygwin.
> >>
> >> I ran the script against both of the revisions (61815 and 61852) in
> >> mentioned in the Apache error log and the output was the same for
> >> each.
> >>
> >> Commands:
> >> dump-noderev.pl /repository
> >> /project/binaries/release/phase1/iteration/81/trunk 61815
> >> dump-noderev.pl /repository
> >> /project/binaries/release/phase1/iteration/81/trunk 61852
> >>
> >> Output:
> >> id: 9-45362.0-61242.r61424/0
> >> type: dir
> >> pred: 9-45362.0-60310/0
> >
> > Are you sure that's the value of the pred: field? It contains only
> > one ".", instead of two.
> >
>
> I missed a part of it, you are right. here is the full pred line:
> pred: 9-45362.0-60310.r60310/0
>
Okay. Did /project/binaries/release/phase1/iteration/81/trunk_at_61852, or
anything under it, change between r60311 and r61423? (I'm intentionally
using the peg rev notation here --- these id's do not change when
a parent of the path in question gets copied.)
> >> count: 43
> >> text: 58741 121716266 218 218 74eb31e90880ba1345fc49252ca6efe6
> >> cpath: /project/binaries/release/phase1/iteration/81/trunk
> >> copyfrom: 61423 /project/binaries/release/phase1/iteration/80/trunk
> >>
> >> Is this information helpful? Let me know if this tells you anything. Thanks
> >>
> >
> > The fact that the output is identical suggests that the
> > /project/binaries/release/phase1/iteration/81/trunk tree hasn't changed
> > between those two revisions (or that there was a directory replace above
> > it).
> >
> > However, this is the error you report:
> >
> > [Tue Jan 31 11:37:23 2012] [error] [client 9.31.13.109] predecessor count for the root node-revision is wrong: found 61815, committing r61852 [409, #160004]
> >
> > The metadata this error complains about will be output by these two
> > commands:
> >
> > ./dump-noderev.pl /repository / 61851
> ------------------------------
>
> id: 0.0.r61851/33470
> type: dir
> pred: 0.0.r61850/3844
> count: 61818
> text: 61851 32225 1232 1232 7555349571e297c23e647cc2441d5b8f
> cpath: /
> copyroot: 0 /
> minfo-cnt: 25685
> ------------------------------
>
> > ./dump-noderev.pl /repository / 61852
> ------------------------------
>
> id: 0.0.r61852/27663
> type: dir
> pred: 0.0.r61851/33470
> count: 61819
> text: 61852 26417 1233 1233 712fec619d55677e67aca8f7aa4ceb97
> cpath: /
> copyroot: 0 /
> minfo-cnt: 25685
> --------------------------------
>
The output from these two tells me two things:
1. The minfo-cnt value is reasonable (within a typical ballpark).
That's relevant since minfo-cnt abnormalities were seen in another
instance of the bug.
2. Everything else looks correct: the 'id:'/'pred:' headers are accurate,
and the 'count:' header was incremented correctly. The 'count:' header
does, however, indicate that your repository has _in the past_ triggered
an instance of the bug.
In a bit more detail: the value of the 'count:' header should be equal to
the revision number given as the third argument to dump-noderev.pl.
(That revision number is also embedded in the 'id:' header, and is
practically guaranteed to be embedded in the 'text:' header as well.)
So, there are two things you can do to help us identify the bug:
1. Hunt for past instance of the bug, identify what revisions triggered
it, and try and identify a common pattern to those revisions. (This
basically calls for running 'dump-noderev.pl $REPOS /' in a loop and
looking for non-sequential 'count:' or 'pred:' headers in the output for
a pair of successive revisions.)
2. Look for new instances of the bug. You could periodically scan for
new instances of the bug, or implement a post-commit hook such as the
following (written for unix-like systems, sorry):
[[[
# look for a corruption or two
minfo_cnt() {
dump-noderev.pl $REPOS / "$1" | sed -ne 's/minfo-cnt: //p'
}
PREV_REV=`expr $REV - 1`
if expr `minfo_cnt $PREV_REV` - `minfo_cnt $REV` | grep ....... >/dev/null; then
# echo an error to stderr and mail the admin
exit 1
fi
skipped_root_noderevs() {
expr $1 - `dump-noderev.pl $REPOS / $1 | sed -ne 's/^count: //p'`
}
if [ "`skipped_root_noderevs $PREV_REV`" -ne "`skipped_root_noderevs $REV`" ]; then
# echo an error to stderr and mail the admin
exit 2
fi
]]]
> >
> >> Jason.
> >
> > Cheers,
> >
> > Daniel
> >
>
> Hi Daniel
>
> Thanks for the quick reply. I have posted the results from the two
> commands you have asked me to run above as well as the full pred
> value that was incomplete.
>
> Let me know if you need any other information.
> Thanks.
>
Replied above. The summary is that you have indeed ran into the bug,
but for some reason not in r61852 but sometime before that, (and why
did r61852 trigger the syslog error anyway? Good question) and now
we're at the point of trying to identify the cause of the bug --- at
least circumstantially.
> Jason
Thanks for your help so far,
Daniel
Received on 2012-02-16 21:14:46 CET