On 5/11/05, Julian Foad <julianfoad@btopenworld.com> wrote:
> [Making this thread more visible and following up.]
>
> Philip Martin wrote:
> > I decided to have a look at our existing uses of "goto cleanup", just
> > to see how many had SVN_ERRs that bypassed the cleanup.
> >
> > These look like real errors:
> >
> > - libsvn_wc/adm_crawler.c:svn_wc_crawl_revisions2
> > fails to call reporter->abort_report
> >
> > - libsvn_ra_dav/util.c:parsed_request
> > fails to destroy neon structures
> >
> > - libsvn_fs_base/fs.c:base_create
> > - libsvn_fs_base/fs.c:base_open
> > fails to call cleanup_fs
> >
> > - libsvn_client/commit.c:svn_client_commit
> > fails to call editor->abort_edit
>
> Philip fixed those in r14667.
>
> > Leaving a subpool isn't really a problem, so these are not bugs:
> >
> > - libsvn_wc/questions.c:svn_wc_text_modified_p
> > - libsvn_wc/props.c:svn_wc_props_modified_p
> > fails to delete a subpool
>
> I can't see why those functions should be using sub-pools: I can't see any
> repetition or very large memory allocations. Can we get rid of their sub-pools?
Well, if we're allocating really large chuncks of memory, we sometimes
use subpools to deallocate it before returning from the routine. I
think it's nice form to make sure large unused memory chunks are
released from memory if they serve as routine-internal storage. (Large
as in 128k or so...)
> > I don't understand the significance of this one:
> >
> > - libsvn_wc/status.c:close_edit
> > fails to clear traversal_info
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 11 20:22:53 2005