On 2008-06-17 13:12:11 +0100, Julian Foad wrote:
> It's impossible to know in advance whether some unexpected condition
> (leading to a failed assertion) is "really bad". Assertions are to catch
> conditions that "can't happen". If you tried to analyse the code to find
> how one of those conditions could happen, you would either find nothing
> or you would find a bug and fix it.
There are cases where you can know. For instance, let's say that
some memory allocation function puts a marker at the end of each
block. If some assertion fails because the marker has changed,
then this probably means memory corruption that occurred somewhere
in the program, which is in general really bad.
> No. You're thinking there is only one level of function call involved.
> In reality an assertion is likely to fail in a deeply nested function
> after the higher level functions have set up lots of state. However,
> most of this state is local to the functions involved, so it's still
> pretty safe to clean up a few important things like a connection to the
> repository, and ignore all the rest of the state that was set up (mostly
> in pools and local variables).
This may be OK if the clean-up is based on different data than those
related to the failed assertion. But this is not always clear, in
particular if the user does "silly" things that may end up corrupting
the working copy. I don't know what you do exactly in the clean-up
part, but if this involves removing temporary files, doing that after
a failed assertion may be dangerous.
I don't know if this is related, but let's take an example. The user
creates a file svn-commit.tmp (after all, this is a filename like any
other) and does "svn add svn-commit.tmp", then for some reason, he
removes the file. In general a "svn ci" should fail, but the temporary
file for the log message happens to be svn-commit.tmp (I wonder if
this is a correct behavior from svn, but well...). The user writes
the log message, thus svn-commit.tmp can be committed with no errors.
But after that, svn removes the file. Everything occurred without any
error from svn. Yet, the working copy is in an incorrect state (the
svn-commit.tmp file is missing). Here, no data has been lost (svn up
retrieves the file), but can you be sure that after a failed assertion
(e.g. because you ended up in some unexpected state), a clean-up won't
break things even more?
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-18 03:21:29 CEST