Nice work, Detective Wuille! Patch for the deadlock issue:
https://github.com/bitcoin/bitcoin/pull/500 I took a different approach to fix from the one Pieter suggested, performing the database operation after the cs_mapaddresses deadlock is released. Please review to check my logic, it did survive my start/stop/restart... stress test. And I did review every place in the code that starts a database transaction, to look for similar issues, and they are all OK. RE: improving DEBUG_LOCKORDER: requires some thought. Deadlocks are still possible with TRY_CRITICAL_SECTION, if some codepaths TRY and some don't. On Tue, Sep 6, 2011 at 7:55 AM, Pieter Wuille <pieter.wui...@cs.kuleuven.be> wrote: > 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. -- -- Gavin Andresen ------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
