On May 27, 2009, at 7:18 PM, Blair Zajac wrote:
> Hyrum K. Wright wrote:
>> On May 27, 2009, at 3:24 PM, Davyd McColl wrote:
>>> Good day
>>>
>>> I have some C++ code which uses the svn_fs_* functions. I've
>>> noticed a bit of an oddity, and I'm hoping that someone can just
>>> tell me that I'm forgetting to do something. It seems that when I
>>> try to perform functions on dirs or files in the repo, if I
>>> specify a path that doesn't exist in the repo, I don't just get
>>> failure for the called function -- I also get a segfault in
>>> apr_terminate() when the last call is made to apr_terminate() (as
>>> I understand it, the last call in a stack of apr_initalize()[N]
>>> apr_terminate()[N] is the one called...
>>>
>>> A simple code example:
>>>
>>> const char *szPath = "/";
>>> apr_initialize();
>>> apr_pool_t *pt = svn_pool_create(NULL);
>>> svn_fs_initialize(pt);
>>> svn_repos_t *repo;
>>> svn_repos_open(&repo, argv[REPO_ARG], pt);
>>> svn_fs_t *fs = svn_repos_fs(repo);
>>> svn_fs_root_t *root;
>>> svn_fs_revision_root(&root, fs, 1, pt);
>>>
>>> apr_pool_t *ptSub = svn_pool_create(pt);
>>> apr_hash_t *hash;
>>> svn_fs_dir_entries(&hash, root, szPath, ptSub);
>>>
>>> svn_pool_destroy(ptSub);
>>> svn_pool_destroy(pt);
>>> apr_terminate();
>>> return 0;
>>>
>>> With szPath set to "/" as above, all works as expected and the
>>> application exits cleanly. However, if szPath were set to a path
>>> not available in the repo at the revision set (for example, if I
>>> set the path to "/foobar"), then not only does the
>>> svn_fs_dir_entries() call fail (yes, I know I'm not checking for
>>> the error here, but I know it does fail -- and I really couldn't
>>> expect otherwise for a path not in the repo...), but when the
>>> time comes for the apr_terminate() call, the application segfaults.
>>>
>>> I'm using subversion-1.6.1, compiled from source on my own
>>> machine with Visual Studio 2008. I'm assuming that there's some
>>> crucial step that I'm missing out in the code above and would
>>> dearly appreciate any constructive thoughts on the problem
>> You've already named the crucial step you are missing: you aren't
>> checking for errors.
>> Subversion errors need to be checked for, and handled, if
>> appropriate. By not handling any returned errors, you are
>> effectively leaking the error memory for any error returned. To
>> help ensure API users (include Subversion's own code) properly
>> handle errors, Subversion is configured to crash on cleanup in
>> debug mode if an error is left unhandled somewhere in the code.
>> My guess is that this is what is happening to your code.
>> If you are sure you want to ignore the returned errors, which I
>> don't recommend, you can wrap each function which returns an error
>> with a call to svn_error_clear().
>
> Hyrum,
>
> Is there a way to figure out where the unhandled error came from?
> I'm seeing a similar core dump in our code base which is pretty
> large (it reimplements svnserve) so figuring out where we are
> leaking an error won't be easy.
I don't know of an easy way off hand. I usually run into this when
doing development, where my current delta and the number places I
could potentially drop an error is relatively small.
It might help to look at where the code is aborting, find our which
error is causing it to abort, and then examine that error. The
message and the error code may give you a hint about where it is
coming from. (As may the new stack tracing stuff recently introduced
on Subversion trunk.)
Just a thought,
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2356011
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-28 04:54:46 CEST