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

Re: Weirdness while testing 1.4.0-rc2 (svnserve processes that don't die)

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2006-07-16 04:09:52 CEST

Garrett Rooney wrote:
> On 7/14/06, C. Michael Pilato <cmpilato@collab.net> wrote:
>> I've tested 1.4.0-rc2 like so:
>> (fsfs|bdb) x (dav|svn|local) + py + pl
>> Everything passes, except one permutation. I'm seeing weirdness while
>> testing 1.4.0-rc2 over svnserve with BDB backends. But it's different
>> weirdness than I saw with rc1. Basically, it appears that svnserve
>> processes get created but never die. See the attached output.
>> Garrett, can you reproduce the same?
> I'm not seeing the problem here, although my test environment is
> running on FreeBSD, not Linux, so maybe that's it? Has anyone else
> run the svnserve tests on bdb 4.4?
> If you attach to the svnserve processes in gdb what are they doing?

Sorry for the delay. Couldn't get to this until I know I had a block of
time big enough to rebuild with debugging enabled. Anyway, here's a stack
trace from one process (it's exemplary of all the other processes I bothered
to check):

#0 0xb7feb402 in ?? ()
#1 0xb7daf13e in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0
#2 0xb7dabd9b in _L_mutex_lock_32 () from /lib/tls/libpthread.so.0
#3 0xbf8ecde8 in ?? ()
#4 0xb7e1d6a8 in ?? () from /usr/local/apache2/lib/libapr-1.so.0
#5 0x09f6dd10 in ?? ()
#6 0x09f6eda0 in ?? ()
#7 0xbf8ecde8 in ?? ()
#8 0xb7e0e5b7 in apr_thread_mutex_lock (mutex=0x9f6d56c)
    at locks/unix/thread_mutex.c:92
#9 0xb7e0e5b7 in apr_thread_mutex_lock (mutex=0x9f6d568)
    at locks/unix/thread_mutex.c:92
#10 0xb7f8306c in svn_fs_bdb__close (bdb_baton=0x9f6eda0)
    at subversion/libsvn_fs_base/bdb/env.c:443
#11 0xb7f88f2a in cleanup_fs (fs=0x9f6d5a0)
    at subversion/libsvn_fs_base/fs.c:185
#12 0xb7f88f9b in cleanup_fs_apr (data=0x9f6d5a0)
    at subversion/libsvn_fs_base/fs.c:291
#13 0xb7e108b9 in pool_clear_debug (pool=0x9f67340, file_line=Variable
"file_line" is not available.
    at memory/unix/apr_pools.c:2034
#14 0xb7e10b57 in pool_destroy_debug (pool=0x9f67340,
    file_line=0xb7e1afdd "memory/unix/apr_pools.c:1269")
    at memory/unix/apr_pools.c:1457
#15 0xb7e1088f in pool_clear_debug (pool=0x9f65828,
    file_line=0xb7e1afdd "memory/unix/apr_pools.c:1269")
    at memory/unix/apr_pools.c:1369
#16 0xb7e10b57 in pool_destroy_debug (pool=0x9f65828,
    file_line=0xb7e1afdd "memory/unix/apr_pools.c:1269")
    at memory/unix/apr_pools.c:1457
#17 0xb7e10c34 in apr_pool_terminate () at memory/unix/apr_pools.c:1269
#18 0xb7e10f41 in apr_terminate () at misc/unix/start.c:82
#19 0xb7c91467 in exit () from /lib/tls/libc.so.6
#20 0x0804b84a in main (argc=4, argv=0xbf8ed0b4)
    at subversion/svnserve/main.c:743

Unfortunately, I still don't have time to debug this right now, and likely
won't until Monday.

C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 16 04:11:24 2006

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.