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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1R0uFd-0001vD-Ha
for bitcoin-development@lists.sourceforge.net;
Tue, 06 Sep 2011 11:55:37 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.182 as permitted sender)
client-ip=209.85.216.182; envelope-from=pieter.wuille@gmail.com;
helo=mail-qy0-f182.google.com;
Received: from mail-qy0-f182.google.com ([209.85.216.182])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1R0uFc-0003Ma-DI
for bitcoin-development@lists.sourceforge.net;
Tue, 06 Sep 2011 11:55:37 +0000
Received: by qyk9 with SMTP id 9so3682242qyk.13
for <bitcoin-development@lists.sourceforge.net>;
Tue, 06 Sep 2011 04:55:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.24.132 with SMTP id v4mr3831486qcb.193.1315310130991; Tue,
06 Sep 2011 04:55:30 -0700 (PDT)
Sender: pieter.wuille@gmail.com
Received: by 10.229.89.12 with HTTP; Tue, 6 Sep 2011 04:55:30 -0700 (PDT)
In-Reply-To: <20110904115926.GA16476@ulyssis.org>
References: <CABsx9T1juB-0hr9NW=PoO5eh_Aqhzkiv3tnXTSTsjBKiy4y0JA@mail.gmail.com>
<20110904115926.GA16476@ulyssis.org>
Date: Tue, 6 Sep 2011 13:55:30 +0200
X-Google-Sender-Auth: u1KoFWVp-AspYE9d7QEITaExBa0
Message-ID: <CAPg+sBjy1FANzv5N7P4kx0Djqz-P2XbqQAFTxnK-MVu8erja+g@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@cs.kuleuven.be>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.5 (-)
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
(pieter.wuille[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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: 1R0uFc-0003Ma-DI
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] 0.4rc1 known bugs
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: Tue, 06 Sep 2011 11:55:37 -0000
On Sun, Sep 4, 2011 at 13:59, Pieter Wuille
<pieter.wuille@cs.kuleuven.be> wrote:
> I've compiled bitcoind with Gavin's DEBUG_LOCKORDER, and fixed two potential
> reported deadlock issues (see https://github.com/sipa/bitcoin/commits/lockfixes).
My mistake: these are not actual potential deadlocks, as all locking
of cs_vRecv/cs_vSend
happens inside TRY_CRITICAL_SECTION blocks. Gavin, maybe you can add the rule to
your debug code that ignores critical sections which are only locked
through TRY_...?
>> + sipa found what looks like a deadlock between the addr-handling and
>> IRC-join-handling code.
Regarding the actual deadlock between IRC seeding and AddAddress:
Internally, DB also uses pthreads to implement the txn_begin()/commit() scheme,
though I'm not sure with which granularity. These need to be taken into account
when searching for deadlocks, but are obviously not detected by
DEBUG_LOCKORDER.
In particular here, the processing of "addr" created a db transaction for the
entire message, while only locking cs_mapAddresses inside AddAddress. For
IRC seeded addresses however, no db tx was precreated, and AddAddress first
locked cs_mapAddress, and then did the database write (causing a lock) inside.
A solution: in main.cpp, ProcessMessage, case "addr":
// Store the new addresses
CAddrDB addrDB;
+ CRITICAL_BLOCK(cs_mapAddresses) {
addrDB.TxnBegin();
int64 nNow = GetAdjustedTime();
int64 nSince = nNow - 10 * 60;
}
}
addrDB.TxnCommit(); // Save addresses (it's ok if this fails)
+ }
if (vAddr.size() < 1000)
which makes sure that cs_mapAddresses is always entered before starting
a database transaction.
However, there may be similar issues in other place where TxnBegin is called
explicitly. Also, maybe there are other solutions, like changing BDB parameters
that make the db transaction fail instead of block, for example.
--
Pieter
|
