1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <laanwj@gmail.com>) id 1WspWb-0002Tt-2d
for bitcoin-development@lists.sourceforge.net;
Fri, 06 Jun 2014 08:29:21 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.182 as permitted sender)
client-ip=209.85.223.182; envelope-from=laanwj@gmail.com;
helo=mail-ie0-f182.google.com;
Received: from mail-ie0-f182.google.com ([209.85.223.182])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WspWZ-0001xc-Hx
for bitcoin-development@lists.sourceforge.net;
Fri, 06 Jun 2014 08:29:21 +0000
Received: by mail-ie0-f182.google.com with SMTP id x19so2048644ier.41
for <bitcoin-development@lists.sourceforge.net>;
Fri, 06 Jun 2014 01:29:13 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.43.155.16 with SMTP id lg16mr3604494icc.65.1402043353168;
Fri, 06 Jun 2014 01:29:13 -0700 (PDT)
Received: by 10.64.60.195 with HTTP; Fri, 6 Jun 2014 01:29:13 -0700 (PDT)
In-Reply-To: <538EF81D.9060301@stud.uni-saarland.de>
References: <1401822421.27942.YahooMailNeo@web124505.mail.ne1.yahoo.com>
<CANEZrP18nf0oK6fbnE59opXxfMdwiOOu4v99iGyXyGo_7NLuYA@mail.gmail.com>
<CAAS2fgTM30oFLGpkCwqM5Wf-Crmz5s05X-uWXAiGy9u43nbKvQ@mail.gmail.com>
<538EF81D.9060301@stud.uni-saarland.de>
Date: Fri, 6 Jun 2014 10:29:13 +0200
Message-ID: <CA+s+GJDZ-F0obYRTkbt=MHMo60jH0jYo-3On_56rHtyguEU4pg@mail.gmail.com>
From: Wladimir <laanwj@gmail.com>
To: Jannis Froese <s9jafroe@stud.uni-saarland.de>
Content-Type: multipart/alternative; boundary=001a11c2d95006827004fb26a885
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(laanwj[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WspWZ-0001xc-Hx
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] # error "Bitcoin cannot be compiled
without assertions." <<<<NOT
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 06 Jun 2014 08:29:21 -0000
--001a11c2d95006827004fb26a885
Content-Type: text/plain; charset=UTF-8
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
--001a11c2d95006827004fb26a885
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Jun 4, 2014 at 12:42 PM, Jannis Froese <span dir=3D"ltr"><<a href=3D=
"mailto:s9jafroe@stud.uni-saarland.de" target=3D"_blank">s9jafroe@stud.uni-=
saarland.de</a>></span> wrote:<br>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div text=
=3D"#000000" bgcolor=3D"#FFFFFF"><div>
=20
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.<br></div></div=
></blockquote><div><br></div><div>Also, most assertion errors that happen t=
o people running Bitcoin Core are not caused by software bugs but database =
corruption errors (usually due to unclean shutdown).<br>
<br></div>For example in case we detect missing/truncated block files or UT=
XO db consistency we should, instead of raising an assertion error, propose=
a -reindex - see also <a href=3D"https://github.com/bitcoin/bitcoin/issues=
/2202">https://github.com/bitcoin/bitcoin/issues/2202</a> .<br>
<br></div><div class=3D"gmail_quote">So instead of using assertions we need=
a fatal error function for those problems which are probably recoverable i=
n a certain specific way. In principle starting a reindex wouldn't even=
need to take down the entire process (though that's easier for impleme=
ntation due to cleanup and assumptions made).<br>
</div><div class=3D"gmail_quote"><div><br>Wladimir<br></div></div><br></div=
></div>
--001a11c2d95006827004fb26a885--
|
