You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Ethan Bradford <et...@swype.com> on 2011/11/15 02:22:22 UTC
Re: 1.7.1, Build 22161 line 672: assertion failed (checksum != NULL)
I upgraded a tree from 1.6.x directly to 1.7.1 and I'm getting this, so the
bug (or a similar one) definitely persists.
I've got very big trees, so checkouts take most of a day, so redoing the
checkout isn't so convenient.
> From: Stefan Sperling <stsp_at_elego.de>
> Date: Wed, 2 Nov 2011 12:13:03 +0100
> On Wed, Nov 02, 2011 at 06:58:47PM +0800, Kun Wang wrote:
> > I did not installed 1.7.0.
> > I updated my working copy using 1.7.1. And the working copy worked for
> > days...
> OK, thanks.
> This probably means that there is another bug in the upgrade code.
> A new checkout should work fine, though.
Re: 1.7.1, Build 22161 line 672: assertion failed (checksum != NULL)
Posted by Ethan Bradford <et...@swype.com>.
On Wed, Nov 16, 2011 at 2:03 AM, Philip Martin
<ph...@wandisco.com>wrote:
> Philip Martin <ph...@wandisco.com> writes:
>
> >> I hate to confess to such absent mindedness, but I may have "svn
> delete"ed
> >> this file. I see that I don't have a local copy of it, which supports
> that
> >> theory. If I did that, I didn't commit the change -- the repository
> still
> >> has the file.
> >
> > I'll have to think about that.
>
> This does explain some things. The client is not adding or modifying
> the file due to any change sent from server, it is merely restoring the
> missing file from its own metadata. That's a small step forward in
> understanding the problem.
>
> It's still not clear how the upgrade went wrong. It's not as simple as
> "svn rm file", "svn upgrade", "svn update" as that works (and would have
> created an op_depth>0 nodes row that we didn't see in the very first
> query you ran).
>
Yes, I tried that myself with a sub-directory including exactly the same
file.
>
> Perhaps it's something to do with the moved file? Perhaps you did
> something like:
>
> svn rm file-before-mv # or perhaps a mv?
>
Definitely no mv. Maybe an rm.
> # some other wc moves and commits the file
>
I'm pretty sure this isn't the case. There's been no activity for this
file since January, and I've done many global check-ins where I'd have
noticed local changes if I'd made them before January.
> svn update # getting a delete/delete tree conflict
> svn resolved # or revert?
> rm file-after-mv # a non-svn rm
> svn upgrade
>
> Perhaps you had two files with the same checksum (that's legitimate) and
> that caused the upgrade to fail? I'll experiment and see if I can
> reproduce it.
>
That is quite possible. This was a large sub-directory with many files.
Another thing which is unusual about our use of SVN is several very
large(~20MB) text files, though the particular file we've been
concentrating on was quite small.
>
> --
> Philip
>
Re: 1.7.1, Build 22161 line 672: assertion failed (checksum != NULL)
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
>> I hate to confess to such absent mindedness, but I may have "svn delete"ed
>> this file. I see that I don't have a local copy of it, which supports that
>> theory. If I did that, I didn't commit the change -- the repository still
>> has the file.
>
> I'll have to think about that.
This does explain some things. The client is not adding or modifying
the file due to any change sent from server, it is merely restoring the
missing file from its own metadata. That's a small step forward in
understanding the problem.
It's still not clear how the upgrade went wrong. It's not as simple as
"svn rm file", "svn upgrade", "svn update" as that works (and would have
created an op_depth>0 nodes row that we didn't see in the very first
query you ran).
Perhaps it's something to do with the moved file? Perhaps you did
something like:
svn rm file-before-mv # or perhaps a mv?
# some other wc moves and commits the file
svn update # getting a delete/delete tree conflict
svn resolved # or revert?
rm file-after-mv # a non-svn rm
svn upgrade
Perhaps you had two files with the same checksum (that's legitimate) and
that caused the upgrade to fail? I'll experiment and see if I can
reproduce it.
--
Philip
Re: 1.7.1, Build 22161 line 672: assertion failed (checksum != NULL)
Posted by Philip Martin <ph...@wandisco.com>.
Ethan Bradford <et...@swype.com> writes:
> I don't know what the server version is. cURL won't accept an svn: URL.
Ah! svnserve. Then "telnet server.com 3690" will get the handshake
which will tell us something.
> Using the repo browser I can see the whole history. There are just two
> versions of this file, none more recent than 3323. I think 3936 is a red
> herring -- that was perhaps the tip revision for the whole repository when
> the update was attempted. (The current tip is 4013.)
Yes. 3936 is the revision to which you were updating.
> I hate to confess to such absent mindedness, but I may have "svn delete"ed
> this file. I see that I don't have a local copy of it, which supports that
> theory. If I did that, I didn't commit the change -- the repository still
> has the file.
I'll have to think about that. The nodes row was presence=normal. I
wonder if the update was creating a tree conflict? Unlikely if there
are no more recent changes than 3323.
sqlite3 .svn/wc.db "select tree_conflict_data from actual_node"
>> Thanks for your help so far!
>>
>
> I'm happy to help, and I appreciate your time. Just to be clear, I
> wouldn't dream of taking so much of your time just to solve my local
> problem. You're digging into this to figure out the bug with change to the
> 1.7.1 version (or maybe "svn update" within the 1.7.1 version), right?
Yes.
> Since I will likely need to do another checkout anyhow, I'm happy to try
> experiments which might be destructive to my local copy.
We may be able to recover it. Please make a copy of the wc.db file
first. The following instructions assume there is no tree conflict.
First we look at the workqueue, to confirm there is just one row.
sqlite3 .svn/wc.db "select * from work_queue"
Next look at the parent dir:
sqlite3 .svn/wc.db "select op_depth, local_relpath, presence from nodes where local_relpath='DBBuild/Wordlists/Belarusian'"
to confirm there is just one row with op-depth=0 and presence=normal or
presence=incomplete. If the presence is something else then stop, the
instuctions below do not apply.
If presence is normal then set the parent dir to presence=incomplete:
sqlite3 .svn/wc.db "update nodes set presence='incomplete' where local_relpath='DBBuild/Wordlists/Belarusian'"
Now remove the corrupt file row:
sqlite3 .svn/wc.db "delete from nodes where local_relpath='DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED]'"
sqlite3 .svn/wc.db "delete from actual_node where local_relpath='DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED]'"
Remove the now unversioned file (except you say it doesn't exist so skip
this step).
rm 'DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED]'
Remove the workqueue:
sqlite3 .svn/wc.db "delete from work_queue"
Run cleanup to remove locks:
svn cleanup
The working copy should be fixed; the next update will pull the missing
file.
--
Philip
Re: 1.7.1, Build 22161 line 672: assertion failed (checksum != NULL)
Posted by Ethan Bradford <et...@swype.com>.
To test whether dealing with the "SVN DELETE" was the problem, I copied
that directory from another computer in 1.6 format, did "SVN DELETE" on
that file, and then updated the format to to 1.7.1. The update happened
w/o error, and the updated directory seems to work fine. So I wasn't able
to repro the problem there.
One difference with the previous test is that for this test, Belarusian was
the root directory (so it keeps its .svn subdirectory). Before, it was a
child of the directory I updated.
On Tue, Nov 15, 2011 at 5:21 PM, Ethan Bradford <et...@swype.com>wrote:
> On Tue, Nov 15, 2011 at 4:28 PM, Philip Martin <philip.martin@wandisco.com
> > wrote:
>
>> Ethan Bradford <et...@swype.com> writes:
>>
>> >> sqlite3 .svn/wc.db "select * from work_queue"
>> >
>> > 3|(file-install 59
>> > DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED] 1 0 1 1)
>> >
>> >> sqlite3 .svn/wc.db "select * from nodes where
>> >
>> local_relpath='DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED]'"
>> >
>> >
>> 1|DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED]|0|DBBuild/Wordlists/Belarusian|1|Trunk/DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED]|3936|normal|||file||infinity|||3323|1294867663142001|Erik.Larsson|504|1294985508149158||
>> >
>> > So there's no checksum (according to other entries, it would be the
>> field
>> > just after "infinity").
>>
>> That's very odd. Do you know which version of Subversion is running on
>> the server? Running something like "curl -D - REPO_URL" might help find
>> out.
>>
>
> I don't know what the server version is. cURL won't accept an svn: URL.
> I can't figure out how to get the version out of the "repro browser",
> which is the most direct serverconnection in the toolset I know.
>
>>
>> Are there other files with no checksum?
>>
>> sqlite3 .svn/wc.db "select count(*) from nodes where checksum is null and
>> kind='file'"
>>
>
> The answer to that query is "1", so that's the only pattern. (Old
> fashioned searches through the dumped list of nodes confirms this.)
>
>>
>> If there are other files then is there any pattern in the filenames?
>> All in the same directory? All modified in the same commit? etc.
>>
>> sqlite3 .svn/wc.db "select local_relpath from nodes where checksum is
>> null and kind='file'"
>>
>>
>> Can you describe the recent activity in the working copy? Do you
>> normally update the whole working copy or do you update subtrees?
>
>
> Normally I update a large subtree (several levels up from this file).
>
>
>> Did
>> you commit changes in the Belarusian directory just before the update?
>>
>
> No, I haven't committed changes from that directory in months. Nobody
> else has either.
>
>>
>> The NODES row shows that the update was trying to install revision 3936
>> of the file. The filename is "BelarusianForceFreq.txt[MOVED]"; has this
>> file been moved/copied within the repository?
>
>
> We moved these files to another repository, so that SVN couldn't (as far
> as we could figure out) understand the move. So we renamed the the files
> on the source side to keep their history conveniently available.
>
>
>> The last modified
>> revision of the file is 3323, would you have committed that revision
>> from this working copy?
>>
>
> That is the last revision, and I didn't commit it from this computer. (It
> was inf
>
>>
>> Do you know the revision before the update? It's possible that you can
>> identify it using
>>
>> sqlite3 .svn/wc.db "select revision from nodes where revision != 3936"
>>
>> or perhaps
>>
>> sqlite3 .svn/wc.db "select revision from nodes where
>> parent_relpath='DBBuild/Wordlists/Belarusian'"
>>
>> or perhaps you can guess the approximate revision based on dates?
>>
>> If you can identify the (approx?) revision before the update then
>> running "svn log -vq URL" will allow you to see the sort of changes the
>> update would have been making. I want to know what the update did to
>> this file, did it just modify the content of the file, or add the file,
>> or replace another file of the same name? Perhaps the whole directory
>> was being added?
>>
>
> Using the repo browser I can see the whole history. There are just two
> versions of this file, none more recent than 3323. I think 3936 is a red
> herring -- that was perhaps the tip revision for the whole repository when
> the update was attempted. (The current tip is 4013.)
>
> I hate to confess to such absent mindedness, but I may have "svn delete"ed
> this file. I see that I don't have a local copy of it, which supports that
> theory. If I did that, I didn't commit the change -- the repository still
> has the file.
>
>
>> Thanks for your help so far!
>>
>
> I'm happy to help, and I appreciate your time. Just to be clear, I
> wouldn't dream of taking so much of your time just to solve my local
> problem. You're digging into this to figure out the bug with change to the
> 1.7.1 version (or maybe "svn update" within the 1.7.1 version), right?
>
> Since I will likely need to do another checkout anyhow, I'm happy to try
> experiments which might be destructive to my local copy.
>
>
>> --
>> Philip
>>
>
>
Re: 1.7.1, Build 22161 line 672: assertion failed (checksum != NULL)
Posted by Ethan Bradford <et...@swype.com>.
On Tue, Nov 15, 2011 at 4:28 PM, Philip Martin
<ph...@wandisco.com>wrote:
> Ethan Bradford <et...@swype.com> writes:
>
> >> sqlite3 .svn/wc.db "select * from work_queue"
> >
> > 3|(file-install 59
> > DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED] 1 0 1 1)
> >
> >> sqlite3 .svn/wc.db "select * from nodes where
> >
> local_relpath='DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED]'"
> >
> >
> 1|DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED]|0|DBBuild/Wordlists/Belarusian|1|Trunk/DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED]|3936|normal|||file||infinity|||3323|1294867663142001|Erik.Larsson|504|1294985508149158||
> >
> > So there's no checksum (according to other entries, it would be the field
> > just after "infinity").
>
> That's very odd. Do you know which version of Subversion is running on
> the server? Running something like "curl -D - REPO_URL" might help find
> out.
>
I don't know what the server version is. cURL won't accept an svn: URL.
I can't figure out how to get the version out of the "repro browser",
which is the most direct serverconnection in the toolset I know.
>
> Are there other files with no checksum?
>
> sqlite3 .svn/wc.db "select count(*) from nodes where checksum is null and
> kind='file'"
>
The answer to that query is "1", so that's the only pattern. (Old
fashioned searches through the dumped list of nodes confirms this.)
>
> If there are other files then is there any pattern in the filenames?
> All in the same directory? All modified in the same commit? etc.
>
> sqlite3 .svn/wc.db "select local_relpath from nodes where checksum is null
> and kind='file'"
>
>
> Can you describe the recent activity in the working copy? Do you
> normally update the whole working copy or do you update subtrees?
Normally I update a large subtree (several levels up from this file).
> Did
> you commit changes in the Belarusian directory just before the update?
>
No, I haven't committed changes from that directory in months. Nobody else
has either.
>
> The NODES row shows that the update was trying to install revision 3936
> of the file. The filename is "BelarusianForceFreq.txt[MOVED]"; has this
> file been moved/copied within the repository?
We moved these files to another repository, so that SVN couldn't (as far as
we could figure out) understand the move. So we renamed the the files on
the source side to keep their history conveniently available.
> The last modified
> revision of the file is 3323, would you have committed that revision
> from this working copy?
>
That is the last revision, and I didn't commit it from this computer. (It
was inf
>
> Do you know the revision before the update? It's possible that you can
> identify it using
>
> sqlite3 .svn/wc.db "select revision from nodes where revision != 3936"
>
> or perhaps
>
> sqlite3 .svn/wc.db "select revision from nodes where
> parent_relpath='DBBuild/Wordlists/Belarusian'"
>
> or perhaps you can guess the approximate revision based on dates?
>
> If you can identify the (approx?) revision before the update then
> running "svn log -vq URL" will allow you to see the sort of changes the
> update would have been making. I want to know what the update did to
> this file, did it just modify the content of the file, or add the file,
> or replace another file of the same name? Perhaps the whole directory
> was being added?
>
Using the repo browser I can see the whole history. There are just two
versions of this file, none more recent than 3323. I think 3936 is a red
herring -- that was perhaps the tip revision for the whole repository when
the update was attempted. (The current tip is 4013.)
I hate to confess to such absent mindedness, but I may have "svn delete"ed
this file. I see that I don't have a local copy of it, which supports that
theory. If I did that, I didn't commit the change -- the repository still
has the file.
> Thanks for your help so far!
>
I'm happy to help, and I appreciate your time. Just to be clear, I
wouldn't dream of taking so much of your time just to solve my local
problem. You're digging into this to figure out the bug with change to the
1.7.1 version (or maybe "svn update" within the 1.7.1 version), right?
Since I will likely need to do another checkout anyhow, I'm happy to try
experiments which might be destructive to my local copy.
> --
> Philip
>
Re: 1.7.1, Build 22161 line 672: assertion failed (checksum != NULL)
Posted by Philip Martin <ph...@wandisco.com>.
Ethan Bradford <et...@swype.com> writes:
>> sqlite3 .svn/wc.db "select * from work_queue"
>
> 3|(file-install 59
> DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED] 1 0 1 1)
>
>> sqlite3 .svn/wc.db "select * from nodes where
> local_relpath='DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED]'"
>
> 1|DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED]|0|DBBuild/Wordlists/Belarusian|1|Trunk/DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED]|3936|normal|||file||infinity|||3323|1294867663142001|Erik.Larsson|504|1294985508149158||
>
> So there's no checksum (according to other entries, it would be the field
> just after "infinity").
That's very odd. Do you know which version of Subversion is running on
the server? Running something like "curl -D - REPO_URL" might help find
out.
Are there other files with no checksum?
sqlite3 .svn/wc.db "select count(*) from nodes where checksum is null and kind='file'"
If there are other files then is there any pattern in the filenames?
All in the same directory? All modified in the same commit? etc.
sqlite3 .svn/wc.db "select local_relpath from nodes where checksum is null and kind='file'"
Can you describe the recent activity in the working copy? Do you
normally update the whole working copy or do you update subtrees? Did
you commit changes in the Belarusian directory just before the update?
The NODES row shows that the update was trying to install revision 3936
of the file. The filename is "BelarusianForceFreq.txt[MOVED]"; has this
file been moved/copied within the repository? The last modified
revision of the file is 3323, would you have committed that revision
from this working copy?
Do you know the revision before the update? It's possible that you can
identify it using
sqlite3 .svn/wc.db "select revision from nodes where revision != 3936"
or perhaps
sqlite3 .svn/wc.db "select revision from nodes where parent_relpath='DBBuild/Wordlists/Belarusian'"
or perhaps you can guess the approximate revision based on dates?
If you can identify the (approx?) revision before the update then
running "svn log -vq URL" will allow you to see the sort of changes the
update would have been making. I want to know what the update did to
this file, did it just modify the content of the file, or add the file,
or replace another file of the same name? Perhaps the whole directory
was being added?
Thanks for your help so far!
--
Philip
Re: 1.7.1, Build 22161 line 672: assertion failed (checksum != NULL)
Posted by Ethan Bradford <et...@swype.com>.
> sqlite3 .svn/wc.db "select * from work_queue"
3|(file-install 59
DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED] 1 0 1 1)
> sqlite3 .svn/wc.db "select * from nodes where
local_relpath='DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED]'"
1|DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED]|0|DBBuild/Wordlists/Belarusian|1|Trunk/DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED]|3936|normal|||file||infinity|||3323|1294867663142001|Erik.Larsson|504|1294985508149158||
So there's no checksum (according to other entries, it would be the field
just after "infinity").
On Tue, Nov 15, 2011 at 9:33 AM, Philip Martin
<ph...@wandisco.com>wrote:
> Ethan Bradford <et...@swype.com> writes:
>
> >> Do you have the sqlite3 tool available to query the 1.7 working copy?
> >>
> >> sqlite3 .svn/wc.db "select count(*) from nodes where op_depth > 0"
> >>
> >
> > I installed sqlite3 to check this. The answer it gets is 0.
>
> Fine. Next:
>
> sqlite3 .svn/wc.db "select * from work_queue"
>
> There may be multiple lines. You should see something like:
> 6|(file-install A/f 1 0 1 1)
>
> "A/f" is just an example, in your case it will be the path of a file in
> your wc. So
>
> sqlite3 .svn/wc.db "select * from nodes where local_relpath='A/f'"
>
> You may see a checksum like:
>
> $sha1$7ab6a41b5d9bc8fad70cc0314c142c91feab4686
>
> or it may be missing. If present:
>
> sqlite3 .svn/wc.db "select * from pristine where checksum like
> '%ab6a41b5d9bc8fad70cc0314c142c91feab4686"
>
> or
>
> sqlite3 .svn/wc.db "select * from pristine where
> checksum='\$sha1\$ab6a41b5d9bc8fad70cc0314c142c91feab4686"
>
> they should be the same (one escapes the '$' characters, the other drops
> them).
>
> --
> Philip
>
Re: 1.7.1, Build 22161 line 672: assertion failed (checksum != NULL)
Posted by Philip Martin <ph...@wandisco.com>.
Ethan Bradford <et...@swype.com> writes:
>> Do you have the sqlite3 tool available to query the 1.7 working copy?
>>
>> sqlite3 .svn/wc.db "select count(*) from nodes where op_depth > 0"
>>
>
> I installed sqlite3 to check this. The answer it gets is 0.
Fine. Next:
sqlite3 .svn/wc.db "select * from work_queue"
There may be multiple lines. You should see something like:
6|(file-install A/f 1 0 1 1)
"A/f" is just an example, in your case it will be the path of a file in
your wc. So
sqlite3 .svn/wc.db "select * from nodes where local_relpath='A/f'"
You may see a checksum like:
$sha1$7ab6a41b5d9bc8fad70cc0314c142c91feab4686
or it may be missing. If present:
sqlite3 .svn/wc.db "select * from pristine where checksum like '%ab6a41b5d9bc8fad70cc0314c142c91feab4686"
or
sqlite3 .svn/wc.db "select * from pristine where checksum='\$sha1\$ab6a41b5d9bc8fad70cc0314c142c91feab4686"
they should be the same (one escapes the '$' characters, the other drops them).
--
Philip
Re: 1.7.1, Build 22161 line 672: assertion failed (checksum != NULL)
Posted by Ethan Bradford <et...@swype.com>.
Thank you for investigating this, Philip. Answers below.
On Tue, Nov 15, 2011 at 2:06 AM, Philip Martin
<ph...@wandisco.com>wrote:
> Ethan Bradford <et...@swype.com> writes:
>
> > I upgraded a tree from 1.6.x directly to 1.7.1 and I'm getting this, so
> the
> > bug (or a similar one) definitely persists.
> >
> > I've got very big trees, so checkouts take most of a day, so redoing the
> > checkout isn't so convenient.
>
> What did the 1.6 working copy look like? Was it a sparse working copy?
>
I did not have a sparse working copy -- I had a full recursive checkout.
> Did it have any local modifications?
It had a couple of local mods, though I don't remember what exactly.
Nothing I need to keep.
> Any switched subdirectories?
No, I don't know what this is, so I probably didn't do it.
> Any uncommitted moves, copies or deletes?
>
No, I'm pretty sure I don't.
>
> Do you have the sqlite3 tool available to query the 1.7 working copy?
>
> sqlite3 .svn/wc.db "select count(*) from nodes where op_depth > 0"
>
I installed sqlite3 to check this. The answer it gets is 0. (I checked
that it is basically working. ".tables" shows a reasonable set of tables.
"select * from nodes" yields quite a bit.)
I should add that this data was recently moved to this computer from my old
laptop (which precipitated my move to SVN version 1.7). I mostly access
through TortoiseSVN.
>
> --
> Philip
>
Re: 1.7.1, Build 22161 line 672: assertion failed (checksum != NULL)
Posted by Philip Martin <ph...@wandisco.com>.
Ethan Bradford <et...@swype.com> writes:
> I upgraded a tree from 1.6.x directly to 1.7.1 and I'm getting this, so the
> bug (or a similar one) definitely persists.
>
> I've got very big trees, so checkouts take most of a day, so redoing the
> checkout isn't so convenient.
What did the 1.6 working copy look like? Was it a sparse working copy?
Did it have any local modifications? Any switched subdirectories? Any
uncommitted moves, copies or deletes?
Do you have the sqlite3 tool available to query the 1.7 working copy?
sqlite3 .svn/wc.db "select count(*) from nodes where op_depth > 0"
--
Philip