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
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2355930
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-27 22:45:50 CEST