You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Shahaf <d....@daniel.shahaf.name> on 2008/12/03 12:44:08 UTC
Sending attachments broken? (was: [PATCH] BDB error_info threading
issue causing core dumps)
Blair,
Your attachment didn't go through; it was replaced by the body of the
message, complete with its URL in the archives. (It's not just you; the
same happened to John's patch yesterday.) I'd suggest that in the
meantime, you paste or inline your patch, if you want us to read it. :)
Daniel
(I'm attaching at 13-byte hello.txt file to this message)
Blair Zajac wrote on Tue, 2 Dec 2008 at 18:05 -0800:
> The multi-threaded RPC svn server we've been working on is getting core dumps
> using the BDB backend. I think our server is different than any of the other
> svn servers (mod_dav_svn, svnserve) in that we cache opened svn_fs_t,
> svn_fs_txn_t and other objects between RPC calls to save IO. The server can
> serve a second RPC request with a different thread that created the svn_fs_t and
> svn_fs_txn_t's, which is leading to the problem
>
> Using svn 1.5.1 with apr 1.2.2 we can get the following stack trace:
>
> Program terminated with signal 11, Segmentation fault.
> #0 apr_pool_destroy (pool=0xf87d8348f87d8948) at memory/unix/apr_pools.c:752
> 752 while (pool->child)
> (gdb) bt
> #0 apr_pool_destroy (pool=0xf87d8348f87d8948) at memory/unix/apr_pools.c:752
> #1 0x00002aaaacd2fe7b in apr_pool_destroy (pool=0x4bec82)
> at memory/unix/apr_pools.c:753
> #2 0x00002aaaabf55def in svn_fs_bdb__wrap_db (fs=<value optimized out>,
> operation=0x2aaaabf71876 "opening 'nodes' table", db_err=0)
> at subversion/libsvn_fs_base/bdb/bdb-err.c:93
> #3 0x00002aaaabf5fcca in open_databases (fs=0xc352830, create=0, format=1,
> path=<value optimized out>, pool=<value optimized out>)
> at subversion/libsvn_fs_base/fs.c:552
> #4 0x00002aaaabf602aa in base_open (fs=0xc352830,
> path=0xccba078 "/opt/vnp3-production-db/repositories/pipe.lax/db",
> pool=0xccb9f88, common_pool=0xc068808)
> at subversion/libsvn_fs_base/fs.c:731
> #5 0x00002aaaabb29eb2 in svn_fs_open (fs_p=0xccb9ff8,
> path=0xccba078 "/opt/vnp3-production-db/repositories/pipe.lax/db",
> fs_config=0x0, pool=0xccb9f88) at subversion/libsvn_fs/fs-loader.c:396
> #6 0x00002aaaab916187 in get_repos (repos_p=0x50417ee8,
> path=<value optimized out>, exclusive=0, nonblocking=0, open_fs=1,
> pool=0xccb9f88) at subversion/libsvn_repos/repos.c:1322
> #7 0x000000000056a17c in SvnUtil::get_svn_repos_and_fs (
> repos_name=@0xc5106d0, context=@0xc5106a8, pool=@0xc5106c8)
> at SvnUtil.cpp:131
>
> In frame #2, we see these garbage values:
>
> #2 0x00002aaaabf55def in svn_fs_bdb__wrap_db (fs=<value optimized out>,
> operation=0x2aaaabf71876 "opening 'nodes' table", db_err=0)
> at subversion/libsvn_fs_base/bdb/bdb-err.c:93
> 93 svn_error_clear(bfd->bdb->error_info->pending_errors);
> (gdb) p bfd->bdb->error_info
> $1 = (bdb_error_info_t *) 0xc28fca0
> (gdb) p *bfd->bdb->error_info
> $2 = {pending_errors = 0x5ace50, user_callback = 0x100000001,
> refcount = 204658481}
>
> The following patch appears to fix the issues.
>
> There also appears to be some reference counting bugs in the bdb_error_info_t
> refcount field that I believe should be removed that will fix a memory leak, but
> that's separate from this issue.
>
> [[[
> In a multi-threaded environment using BDB, if one thread opens a repository,
> saves the svn_fs_t, completes its work, and a second thread starts working with
> the svn_fs_t, then the underlying bdb_env_baton_t's error_info points to the
> first thread's bdb_error_info_t's. Additionally, if the second thread then
> closes the BDB with svn_fs_bdb__close(), it'll free the error_info field that
> the first thread is expecting to be valid.
>
> Remove the error_info field from the bdb_env_baton_t and introduce a new
> function for accessing it to ensure that the thread calling using the
> bdb_error_info_t always works with its own copy.
>
> * subversion/libsvn_fs_base/bdb/env.h
> (bdb_env_baton_t):
> Remove the error_info field.
> (svn_fs_bdb__get_error_info):
> New function to get a bdb_error_info_t from a bdb_env_baton_t.
>
> * subversion/libsvn_fs_base/bdb/env.c
> (svn_fs_bdb__get_error_info):
> New function that wraps get_error_info() but takes a bdb_env_baton_t
> instead of a bdb_env_t.
> (convert_bdb_error):
> No longer set the error_info field in the bdb_env_baton_t.
> (svn_fs_bdb__close):
> Use get_error_info() to get the bdb_error_info_t instead of
> getting it directly from the structure.
>
> * subversion/libsvn_fs_base/bdb/bdb-err.h
> (SVN_BDB_ERR):
> Use svn_fs_bdb__get_error_info() to get the bdb_error_info_t instead of
> getting it directly from the structure.
>
> * subversion/libsvn_fs_base/bdb/bdb-err.c
> (svn_fs_bdb__dberr),
> (svn_fs_bdb__dberrf),
> (svn_fs_bdb__wrap_db):
> Use svn_fs_bdb__get_error_info() to get the bdb_error_info_t instead of
> getting it directly from the structure.
> (create_env):
> No longer set the error_info field in the bdb_error_info_t.
>
> * subversion/libsvn_fs_base/fs.c
> (base_bdb_set_errcall):
> Use svn_fs_bdb__get_error_info() to get the bdb_error_info_t instead of
> getting it directly from the structure.
>
> Patch by: Michael Zhang <mz...@imageworks.com>
> Reviewed by: blair
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=978637
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=978862
trying one attachment
Posted by Neels Janosch Hofmeyr <ne...@elego.de>.
<Message Body>
I am illustrating current behaviour of attachments sent to the dev@ list.
Please excuse this...
~Neels
</Message Body>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=981994
Re: Sending attachments broken?
Posted by Neels Janosch Hofmeyr <ne...@elego.de>.
Hi all,
I've seen another case of wrong attachment behaviour when absolutely *not*
signing the message with PGP/MIME. (I did get a copy of the same message
back which looks perfectly fine, so it's definitely the tigris stuff.)
I sent *two* attachments (neither being PGP stuff), and the *first*
attachment was replaced by a copy of the message body, while the *second*
attachment stayed intact.
That's the same as with PGP/MIME signing. PGP/MIME adds an attachment to the
message. So if I had another attached file to the message, the PGP
attachment makes two attachments. The first attachment gets overwritten...
This leads me to assume that the number of attachments is the key, not the
PGPness of it. There's at least some indexing fault with two attachments.
Let's try one with three.
~Neels
C. Michael Pilato wrote:
> Daniel Shahaf wrote:
>> Blair,
>>
>> Your attachment didn't go through; it was replaced by the body of the
>> message, complete with its URL in the archives. (It's not just you; the
>> same happened to John's patch yesterday.) I'd suggest that in the
>> meantime, you paste or inline your patch, if you want us to read it. :)
>>
>> Daniel
>> (I'm attaching at 13-byte hello.txt file to this message)
>
> And, of course, your attachment went through just fine, Daniel.
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=981993
Re: Sending attachments broken?
Posted by "C. Michael Pilato" <cm...@collab.net>.
Daniel Shahaf wrote:
> Blair,
>
> Your attachment didn't go through; it was replaced by the body of the
> message, complete with its URL in the archives. (It's not just you; the
> same happened to John's patch yesterday.) I'd suggest that in the
> meantime, you paste or inline your patch, if you want us to read it. :)
>
> Daniel
> (I'm attaching at 13-byte hello.txt file to this message)
And, of course, your attachment went through just fine, Daniel.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=978885