> -----Original Message-----
> From: glasser@tigris.org [mailto:glasser@tigris.org]
> Sent: Friday, November 16, 2007 9:42 PM
> To: svn@subversion.tigris.org
> Subject: svn commit: r27890 - in trunk: .
> subversion/include/private subversion/libsvn_fs_base
> subversion/libsvn_fs_fs subversion/libsvn_fs_util
>
> Author: glasser
> Date: Fri Nov 16 18:42:27 2007
> New Revision: 27890
>
> Log:
> Merge sqlite-node-origins branch to trunk.
>
> There is now a sqlite table for node_origins in the same
> database file as mergeinfo (though perhaps it should be moved
> for concurrency
> reasons) and support code in libsvn_fs_util. FSFS uses it
> (BDB uses a BDB table); it is currently only filled at CACHE
> MISS time, though it should be straightforward to fill it at
> commit time as well.
>
>
> Added:
> trunk/subversion/include/private/svn_fs_node_origins.h
> - copied unchanged from r27889,
> /branches/sqlite-node-origins/subversion/include/private/svn_f
s_node_origins.h
> trunk/subversion/include/private/svn_fs_sqlite.h
> - copied unchanged from r27889,
> /branches/sqlite-node-origins/subversion/include/private/svn_f
s_sqlite.h
> trunk/subversion/libsvn_fs_util/node-origins-sqlite-index.c
> - copied unchanged from r27889,
Hi David,
I get a segfault on my Win32 Debug (and only Debug) build in
libsvn_fs_fs/lib.c:svn_fs_fs__id_rev() when doing a URL->WC copy.
+ id 0x00000000 {vtable=??? fsap_data=??? } const
svn_fs_id_t *
> libsvn_fs-1.dll!svn_fs_fs__id_rev(const svn_fs_id_t *
id=0x00000000) Line 67 + 0x3 bytes C
libsvn_fs-1.dll!fs_node_origin_rev(long * revision=0x0111ce10,
svn_fs_root_t * root=0x0113c0a8, const char * path=0x010e0f98,
apr_pool_t * pool=0x0111cdd0) Line 2953 + 0x23 bytes C
libsvn_fs-1.dll!svn_fs_node_origin_rev(long *
revision=0x0111ce10, svn_fs_root_t * root=0x0113c0a8, const char *
path=0x0111ce08, apr_pool_t * pool=0x0111cdd0) Line 761 + 0x1b bytes
C
libsvn_repos-1.dll!svn_repos_node_location_segments(svn_repos_t
* repos=0x0106ea00, const char * path=0x01118780, long peg_revision=1,
long start_rev=1, long end_rev=0, svn_error_t * (svn_location_segment_t
*, void *, apr_pool_t *)* receiver=0x0035dd60, void *
receiver_baton=0x0012f984, svn_error_t * (int *, svn_fs_root_t *, const
char *, void *, apr_pool_t *)* authz_read_func=0x00000000, void *
authz_read_baton=0x00000000, apr_pool_t * pool=0x01070320) Line 953 +
0x15 bytes C
<snipping the rest of the stack...it doesn't appear relevant
here>
The cause is in
libsvn_fs_util/nodes-origins-sqlite-index.c:get_origin(). The line,
*node_rev_id = (const char *) sqlite3_column_text(stmt, 0);
works and sets the node_rev_id, but when sqlite3_finalize() is called
*node_rev_id is set to an empty sting:
/* A flow-control helper macro for sending processing to the 'cleanup'
label when the local variable 'err' is not SVN_NO_ERROR. */
#define MAYBE_CLEANUP if (err) goto cleanup
static svn_error_t *
get_origin(const char **node_rev_id,
sqlite3 *db,
const char *node_id)
{
sqlite3_stmt *stmt;
int sqlite_result;
SVN_FS__SQLITE_ERR(sqlite3_prepare
(db,
"SELECT node_rev_id FROM node_origins "
"WHERE node_id = ?",
-1, &stmt, NULL), db);
SVN_FS__SQLITE_ERR(sqlite3_bind_text(stmt, 1, node_id, -1,
SQLITE_TRANSIENT), db);
sqlite_result = sqlite3_step(stmt);
if (sqlite_result != SQLITE_DONE && sqlite_result != SQLITE_ROW)
return svn_error_create(SVN_ERR_FS_SQLITE_ERROR, NULL,
sqlite3_errmsg(db));
else if (sqlite_result == SQLITE_ROW)
*node_rev_id = (const char *) sqlite3_column_text(stmt, 0);
else
*node_rev_id = NULL;
SVN_FS__SQLITE_ERR(sqlite3_finalize(stmt), db);
^^^ After this *node_rev_id is "" ^^^
return SVN_NO_ERROR;
}
Then in libsvn_fs_fs/tree.c:fs_node_origin_rev(), svn_fs_fs__id_parse()
parses the empty string and returns NULL, which svn_fs_fs__id_rev()
chokes on.
if (cached_origin_id_str != NULL)
{
*revision =
svn_fs_fs__id_rev(svn_fs_fs__id_parse(cached_origin_id_str,
strlen(cached_origin_id_str),
pool));
return SVN_NO_ERROR;
}
Avoiding the larger question of why this is a Win32 debug only problem,
shouldn't svn_fs__get_node_origin() be allocating *origin_id in it's
pool? Something similar to the attached patch maybe? That fixes the
problem for me, but I'm uncertain if there is something else wrong here.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 19 18:04:41 2007