Daniel Shahaf <d...@daniel.shahaf.name> writes:
> [[[
> % $svn cleanup
> subversion/libsvn_wc/workqueue.c:672: (apr_err=235000)
> svn: E235000: In file 'subversion/libsvn_wc/workqueue.c' line 672: assertion
> failed (checksum != NULL)
> zsh: abort $SVN cleanup
> % svnqlite3-dump | grep -i queue
> CREATE TABLE WORK_QUEUE ( id INTEGER PRIMARY KEY AUTOINCREMENT, work
> BLOB NOT NULL );
> INSERT INTO "WORK_QUEUE" VALUES(5,(file-install
> filter.d/asf-svn-abuse-warn.conf 1 0 1 1));
> INSERT INTO "WORK_QUEUE" VALUES(6,(file-install
> filter.d/asf-svn-abuse-ban.conf 1 0 1 1));
> INSERT INTO "sqlite_sequence" VALUES('WORK_QUEUE',6);
> ]]]
>
> However, I haven't found a way to reproduce an 'svn upgrade' scenario
> that triggers the assertion.
I've been looking at this working copy. It appears to be an update from
r794489 to r795270 (which was probably HEAD at the time).
An update should mark directories 'incomplete' when opening them to make
changes during an update, this gets stored in the op-depth 0 row and is
set back to 'normal' when the directory is closed at the end of the
update.
What appears to have happened is that wc_db.c:open_directory has gone
wrong and put the 'incomplete' marker for 'filter.d' in op-depth 1
rather than op-depth 0. I can reproduce the problem as follows:
$ svnadmin create repo
$ svn mkdir -mm file://`pwd`/repo/A
$ svn import -mm repo/format file://`pwd`/repo/A/f
$ svn import -mm repo/format file://`pwd`/repo/A/g
$ svn co file://`pwd`/repo@2 wc
Now run update inside gdb:
$ gdb -arg svn up wc
(gdb) b update_editor.c:open_directory
(gdb) r
Breakpoint 1
(gbd) fin
Switch to another terminal and run:
$ sqlite3 wc/.svn/wc.db "update nodes set presence='normal' where
local_relpath='A'"
$ sqlite3 wc/.svn/wc.db "insert into nodes(wc_id, op_depth, local_relpath,
parent_relpath, kind, presence) values (1, 1, 'A', '', 'dir', 'incomplete')"
Back to gdb and
(gdb) c
SIGABRT
At this point "svn cleanup" will produce the same error as the original
report.
I have no idea how wc_db.c:open_directory managed to set 'incomplete' at
the wrong op_depth. It doesn't seem possible since 0 is hard-coded in
the SQL see STMT_UPDATE_BASE_NODE_PRESENCE_REVNUM_AND_REPOS_PATH.
Anyone got any ideas?
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
