TD and jrmithdobbs ran into this with version 0.6rc1.

What happened:

Block 170060 has an invalid-under-new-rules BIP16 transaction. That block is rejected by 0.6rc1 unless you run with the -paytoscripthashtime= argument to move the BIP16 acceptance date.

There is a fairly long alternative chain fork at that point, because a couple of mining pool operators who were supporting BIP16 didn't restart their bitcoind's with the new BIP16 deadline.

The 0.6rc1 code will save both chains to disk, but rejects the longer as invalid. So far, so good.

The bug: If you upgrade or set -paytoscripthashtime to the correct date then the next found block will trigger a really big reorg operation. And with the settings we're using for Berkeley DB, that re-org fails because the database code runs out of locks.

Workarounds: recompile bitcoin so bdb allocated more locks. Or re-download the blockchain.

Short-term fix: Add a command-line flag so anybody who runs into this issue can just re-run with more locks.

Long-term fix: Rework the block re-org code so it doesn't create one massive database transaction.