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.
Regards,
Blair
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2355991
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-28 02:20:38 CEST