public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Wladimir <laanwj@gmail.com>
To: Jannis Froese <s9jafroe@stud.uni-saarland.de>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] # error "Bitcoin cannot be compiled without assertions." <<<<NOT
Date: Fri, 6 Jun 2014 10:29:13 +0200	[thread overview]
Message-ID: <CA+s+GJDZ-F0obYRTkbt=MHMo60jH0jYo-3On_56rHtyguEU4pg@mail.gmail.com> (raw)
In-Reply-To: <538EF81D.9060301@stud.uni-saarland.de>

[-- Attachment #1: Type: text/plain, Size: 1108 bytes --]

On Wed, Jun 4, 2014 at 12:42 PM, Jannis Froese <
s9jafroe@stud.uni-saarland.de> wrote:

I think most concerns about the current use of asserts would be resolved if
> the currently used asserts would be changed to a nicer definition which is
> independent of NDEBUG, and a second class of debugging asserts would be
> introduced, which is exclusively for expensive, redundant checks and is
> disabled by NDEBUG.
>

Also, most assertion errors that happen to people running Bitcoin Core are
not caused by software bugs but database corruption errors (usually due to
unclean shutdown).

For example in case we detect missing/truncated block files or UTXO db
consistency we should, instead of raising an assertion error, propose a
-reindex - see also https://github.com/bitcoin/bitcoin/issues/2202 .

So instead of using assertions we need a fatal error function for those
problems which are probably recoverable in a certain specific way. In
principle starting a reindex wouldn't even need to take down the entire
process (though that's easier for implementation due to cleanup and
assumptions made).

Wladimir

[-- Attachment #2: Type: text/html, Size: 1731 bytes --]

  parent reply	other threads:[~2014-06-06  8:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-03 19:07 [Bitcoin-development] # error "Bitcoin cannot be compiled without assertions." <<<<NOT Ron
2014-06-04  9:51 ` Mike Hearn
2014-06-04 10:12   ` Wladimir
2014-06-04 10:15   ` Gregory Maxwell
2014-06-04 10:20     ` Mike Hearn
2014-06-04 10:31       ` Gregory Maxwell
2014-06-04 12:15       ` Jeff Garzik
2014-06-04 10:42     ` Jannis Froese
2014-06-04 10:51       ` Mike Hearn
2014-06-04 12:13       ` Wladimir
2014-06-06  8:29       ` Wladimir [this message]
2014-06-06  8:40         ` Pieter Wuille
2014-06-07  0:57           ` Jeff Garzik
     [not found] <mailman.192896.1401886427.2163.bitcoin-development@lists.sourceforge.net>
2014-06-04 19:13 ` [Bitcoin-development] " Ron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+s+GJDZ-F0obYRTkbt=MHMo60jH0jYo-3On_56rHtyguEU4pg@mail.gmail.com' \
    --to=laanwj@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=s9jafroe@stud.uni-saarland.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox