[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Mergeinfo.db file kept open by apache after sql error

From: Daniel Rall <dlr_at_finemaltcoding.com>
Date: 2007-08-27 21:39:34 CEST

On Aug 26, 2007, at 1:05 AM, Lieven Govaerts wrote:

> During testing of the ra_serf code, and more specifically when running
> merge_tests 63 I encountered following error:
>
> CMD: svn.exe cp
> http://localhost/svn-test-work/repositories/merge_tests-63/A
> http://localhost/svn-test-work/repositories/merge_tests-63/A_copy -m
> "create a new copy of A"
> ACTUAL STDERR:
> ..\..\..\subversion\libsvn_ra_serf\util.c:462: (apr_err=160043)
> svn: SQL logic error or missing database
>
> Extract from apache's error log:
> [Thu Aug 23 10:20:36 2007] [error] [client 127.0.0.1] Could not MERGE
> resource
> "/svn-test-work/repositories/merge_tests-63/!svn/act/fd5ccbd0-caa5-
> f547-ab59-8c882bafcc13"
> into "/svn-test-work/repositories/merge_tests-63". [409, #0]
> [Thu Aug 23 10:20:36 2007] [error] [client 127.0.0.1] An error
> occurred
> while committing the transaction. [409, #160043]
> [Thu Aug 23 10:20:36 2007] [error] [client 127.0.0.1] SQL logic
> error or
> missing database [409, #160043]
>
> When I tried to delete the repository Windows wouldn't allow me to,
> indicating the file was still open by some process. That turned out to
> be the apache process.
>
> This was at 23/08, since then I rebuilt both svn client and server
> and I
> can't reproduce this issue anymore. So maybe the server has been fixed
> since, but equally likely it isn't.
>
> In mergeinfo-sqlite-index.c/svn_fs_mergeinfo__get_mergeinfo(), but
> also
> in svn_fs_mergeinfo__update_index and
> svn_fs_mergeinfo__get_mergeinfo_for_tree the call to sqlite3_close is
> not in the 'finally' path (in java terms), so whenever there's an
> error
> accessing the database it's not closed correctly.
>
> Does this make sense?

Thanks for the report, Lieven. I've added some simple error handling
improvements in r26340 which fix this problem.

I was wondering, though -- should we also attach the same sort of
connection cleanup code to a pool cleanup function? Or would that be
needless additional complexity?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 28 03:21:54 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.