epg_at_tigris.org writes:
> Author: epg
> Date: Wed Apr 16 13:36:22 2008
> New Revision: 30642
>
> Log:
> * subversion/svnserve/serve.c
> "Fix" segfault by not giving log_fs_warning its own pool, instead
> letting it allocate unbounded for the life of the child...
>
> Modified:
> branches/svnserve-logging/subversion/svnserve/serve.c
>
> Modified: branches/svnserve-logging/subversion/svnserve/serve.c
> URL: http://svn.collab.net/viewvc/svn/branches/svnserve-logging/subversion/svnserve/serve.c?pathrev=30642&r1=30641&r2=30642
> ==============================================================================
> --- branches/svnserve-logging/subversion/svnserve/serve.c Wed Apr 16 13:24:30 2008 (r30641)
> +++ branches/svnserve-logging/subversion/svnserve/serve.c Wed Apr 16 13:36:22 2008 (r30642)
> @@ -272,7 +272,6 @@ log_fs_warning(void *baton, svn_error_t
> if (server->log_file == NULL)
> return;
>
> - svn_pool_clear(b->pool);
> timestr = svn_time_to_cstring(apr_time_now(), b->pool);
> remote_host = svn_ra_svn_conn_remote_host(conn);
> remote_host = (remote_host ? remote_host : "-");
> @@ -2936,7 +2935,7 @@ svn_error_t *serve(svn_ra_svn_conn_t *co
>
> warn_baton.server = &b;
> warn_baton.conn = conn;
> - warn_baton.pool = svn_pool_create(pool);
> + warn_baton.pool = pool;
> svn_fs_set_warning_func(b.fs, log_fs_warning, &warn_baton);
>
> SVN_ERR(svn_fs_get_uuid(b.fs, &uuid, pool));
I don't understand what's going on here. It seems that merely
allocating a subpool out of pool here in serve() causes the
server to segfault on all lock tests. gdb thinks the core file
represents infinitely recurring apr_pool_destroy calls, so I
can't even find where the fault occurs. Ideas?
FAIL: lock_tests.py 1: lock a file and verify that it's locked
FAIL: lock_tests.py 2: commit a file and keep lock
FAIL: lock_tests.py 3: commit a file and release lock
FAIL: lock_tests.py 4: commit a locked file with a prop change
FAIL: lock_tests.py 5: lock a file and verify lock breaking behavior
FAIL: lock_tests.py 6: lock a file and verify lock stealing behavior
FAIL: lock_tests.py 7: examine the fields of a lockfile for correctness
FAIL: lock_tests.py 8: verify behavior when a lock in a wc is defunct
FAIL: lock_tests.py 9: verify svn:needs-lock read-only behavior
FAIL: lock_tests.py 10: verify svn:needs-lock behavior with defunct lock
FAIL: lock_tests.py 11: verify lock removal on a deleted path
FAIL: lock_tests.py 12: lock and unlock some files
FAIL: lock_tests.py 13: verify removal of a directory with locks inside
FAIL: lock_tests.py 14: verify status of lock in working copy
FAIL: lock_tests.py 15: verify status of stolen lock
FAIL: lock_tests.py 16: verify status of broken lock
FAIL: lock_tests.py 18: lock an out-of-date file and ensure failure
FAIL: lock_tests.py 19: update handles svn:needs-lock correctly
FAIL: lock_tests.py 20: verify svn:needs-lock behavior with revert
FAIL: lock_tests.py 21: examine the fields of a lock from a URL
FAIL: lock_tests.py 22: lock/unlock several files in one go
FAIL: lock_tests.py 23: lock/unlock switched files
FAIL: lock_tests.py 24: lock and unlock a file with an URI-unsafe name
FAIL: lock_tests.py 25: svn:needs-lock and svn:executable, part I
FAIL: lock_tests.py 26: svn:needs-lock and svn:executable, part II
FAIL: lock_tests.py 27: commit file with xml-unsafe name and release lock
FAIL: lock_tests.py 28: verify info path_at_X or path -rY return repos lock
FAIL: lock_tests.py 29: (un)lock set of files, one already (un)locked
FAIL: lock_tests.py 30: show correct lock info on moved path
FAIL: lock_tests.py 31: ls locked path needing URL encoding
FAIL: lock_tests.py 32: verify unlocking with wrong lock token
FAIL: lock_tests.py 33: verify recursive info shows lock info
FAIL: lock_tests.py 34: unlock file locked by other user
FAIL: authz_tests.py 12: test authz for locking
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-16 22:38:38 CEST