assertion in trunk on an upgraded-by-rc1 working copy Re: Issue #3823 fixed but externals_tests.py#file_external_update_without_commit still XFail

[Daniel Shahaf <d....@daniel.shahaf.name>]

Johan Corveleyn wrote on Sun, Jun 05, 2011 at 20:40:34 +0200:
> Fetching external item into
> 'svn-test-work\working_copies\externals_tests-29\A2\iota':
> svn: E235000: In file '..\..\..\subversion\libsvn_wc\workqueue.c' line
> 672: assertion failed (checksum != NULL)

We ran into this assertion on one of the local working copies on
svn.apache.org, while doing 'svn upgrade && svn update' of an update
that adds two new files (with properties; r795270 in the /repos/infra
repository) using an 1.7.0-rc1 'svn' binary.  The working copy was
at format 10 before the upgrade.

If I rsync the working copy to my workstation and run 'cleanup' on it
using my trunk@HEAD build, I can reproduce the assertion:

[[[
% $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.


Does that sound like a bug in rc1 that have been fixed or like an
outstanding bug in trunk?  I can share the failing-to-cleanup working
copy privately (27KB .tar.gz).

Thanks,

Daniel

Re: assertion in trunk on an upgraded-by-rc1 working copy Re: Issue #3823 fixed but externals_tests.py#file_external_update_without_commit still XFail

[Daniel Shahaf <d....@daniel.shahaf.name>]

Daniel Shahaf wrote on Sun, Sep 04, 2011 at 19:52:58 +0300:
> Johan Corveleyn wrote on Sun, Jun 05, 2011 at 20:40:34 +0200:
> > Fetching external item into
> > 'svn-test-work\working_copies\externals_tests-29\A2\iota':
> > svn: E235000: In file '..\..\..\subversion\libsvn_wc\workqueue.c' line
> > 672: assertion failed (checksum != NULL)
> 
> We ran into this assertion on one of the local working copies on

There are no externals in the context I ran into the assertion in.

Re: assertion in trunk on an upgraded-by-rc1 working copy Re: Issue #3823 fixed but externals_tests.py#file_external_update_without_commit still XFail

[Philip Martin <ph...@wandisco.com>]

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