On Aug 28, 2007, at 4:39 AM, Lieven Govaerts wrote:
> Quoting Daniel Rall <dlr@finemaltcoding.com>:
>
>>
>> On Aug 26, 2007, at 1:05 AM, Lieven Govaerts wrote:
> ..
>>> 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.
>
> That should do it. One small remark: What do you think of renaming the
> MAYBE_CLEANUP macro to CLEANUP_ON_ERROR, extending it
> to take the 'err' variable as parameter and move to a
> common include file so we can use it throughout whole the code?
> I've found
> hundreds of instances where we use this pattern, might as well make
> it more
> standard.
That's not a bad idea -- I cribbed the pattern from libsvn_wc. I
guess this would live in a header file under include/private/?
>> 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?
>
> As far as I see in the code we open & close the db connection in
> the scope of
> one function, there's no handover of ownership involved. I don't
> think there's
> much value to registering a cleanup function right now, if we're
> sure we handle
> all return paths correctly.
*nod* Sounds fair to me.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 29 10:47:24 2007