Jonathan Gilbert wrote:
> At 10:25 AM 4/29/2007 +0200, Folker Schamel wrote:
>> Stefan KEg wrote:
>>> If there's any chance that the apr pools can clean up something, then
>>> the subversion lib should return an error and not call abort() at all.
>>> Because that's a situation which I would consider as manageable, and
>>> such situations should never call abort(). IMHO, abort() should only be
>>> used as the absolutely last resort, if really there's absolutely *no*
>>> other way to recover.
>> What situation could that be?
>
> Though it's not part of Subversion's code base, one example that pops to
> mind is a corrupt memory heap; what can malloc() and free() do if whatever
> structure it is in memory tracks blocks is hopelessly corrupted by stray
> pointers elsewhere in the application? That's a perfectly good situation to
> raise such an "uncatchable" error.
>
> Of course, a damaged heap makes almost any code execution impossible, but I
> can't think that there'd be many things within Subversion that could
> irreparably prevent all future calls into Subversion's API within that
> process from behaving correctly...
I think, even if further API calls wouldn't be possible,
returning an error FATAL_ERROR_DONT_CALL_ANY_API_FUNCTION_ANYMORE
is better than abort(), because - as Stefan mentioned -
this gives the application the possibility to handle this situation
(e.g. re-initialize the Subversion library).
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 29 22:15:46 2007