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...
Jonathan Gilbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 29 16:43:13 2007