[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

svn commit: r27890 - Win32 Debug segfault

From: Paul Burba <pburba_at_collab.net>
Date: 2007-11-19 18:04:28 CET

> -----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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.