[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SVN_ERR_ASSERT calls abort() in non-maintainer-mode

From: Hyrum K Wright <hyrum_at_hyrumwright.org>
Date: Thu, 19 May 2011 16:49:18 +0200

On Thu, May 19, 2011 at 3:48 PM, Arwin Arni <arwin_at_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.

-Hyrum
Received on 2011-05-19 16:49:49 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.