On Thursday 19 May 2011 08:19 PM, Hyrum K Wright wrote:
On Thu, May 19, 2011 at 3:48 PM, Arwin Arni<ar...@collab.net>  wrote:
In our implementation of SVN_ERR_ASSERT, we do:

#define SVN_ERR_ASSERT(expr)                                            \
  do {                                                                  \
    if (!(expr))                                                        \
      SVN_ERR(svn_error__malfunction(TRUE, __FILE__, __LINE__, #expr)); \
  } while (0)

This ends up calling svn_error_abort_on_malfunction (inside
subversion/libsvn_subr/error.c) which calls abort() indiscriminately:

svn_error_t *
svn_error_abort_on_malfunction(svn_boolean_t can_return,
                               const char *file, int line,
                               const char *expr)
{
  svn_error_t *err = svn_error_raise_on_malfunction(TRUE, file, line, expr);

  svn_handle_error2(err, stderr, FALSE, "svn: ");
  abort();
  return err;  /* Not reached. */
}


Wouldn't this abort() regardless of maintainer-mode?
Shouldn't there be some difference between maintainer-mode and production?

What is the alternative?  The idea is to catch potential invalid
states in the code.  *Not* aborting would put the system in an
undefined condition and cause potential further damage.

Am I missing something here?

In the command line client, we are free to abort() when we want, and
that's what we do in this case.  When Subversion is used as a library,
abort()ing is Bad Behavior, as it may crash the process in which
Subversion is embedded, and has no knowledge of.  Because of this, we
give clients the ability to override the function called by
SVN_ERR_ASSERT(), so they can handle the error however they choose.

Fair enough. However, I noticed that there is no SVN_ERR_ASSERT inside our mod_dav_svn or mod_authz_svn code.
(In an attempt to not abort() from inside an httpd process?)

But mod_dav_svn calls some other svn library which may abort(). Wouldn't this end the server process? Is it okay for apache to die?

Regards,
Arwin Arni

Reply via email to