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 ) 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 ; 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: <20110904115926.GA16476@ulyssis.org> Date: Tue, 6 Sep 2011 13:55:30 +0200 X-Google-Sender-Auth: u1KoFWVp-AspYE9d7QEITaExBa0 Message-ID: From: Pieter Wuille To: Gavin Andresen 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 11:55:37 -0000 On Sun, Sep 4, 2011 at 13:59, Pieter Wuille 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