やっと簡単な問題だ。初期ダウンロードのような長い操作中に発生しうる原因が見えた。TryLockのバグはDB関連の問題とは無関係だ。修正はtest8に含まれる。
32ビットLinux上で、絶え間ないリクエストの連続フラッドを送りつけることで、db::open/close例外を3回再現できた。wallet.datデータベースを定期的に閉じてフラッシュするだけでもdb::close例外が発生するようだ。Linuxではウォレットフラッシュ機能を無効にする。Linux上では、終了する準備ができるまでデータベースハンドルを閉じないようにする。これを無効にしてからは、今のところ例外は発生していない。
初期ブロックダウンロードの秩序立った実装も進めている。すべてのブロックを一度にリクエストする素朴な方法ではなく、一度に500件ずつバッチでリクエストするようにする。こうすることで、リトライタイムアウトの前にブロックを受信できるため、実際に受信できなかったり遅すぎたりしない限り、他のノードにリクエストすることはなくなるはずだ。変更はリクエストを受ける側にあるため、初期ブロックダウンロードの相手が新しいバージョンのノードになるまで、この機能は見えない。
test8を送る前にもう少しテストを続ける。
NewLibertyStandardのメール（2009年11月18日03:00 UTC）test7を、新しいデータディレクトリで開始した。ブロックのダウンロードが格段に速く始まった。これまでのLinuxビルドでは数分かかっていたが、今回は約15秒で済んだ。ブロックをダウンロードしている間に1回クラッシュし、ターミナルに以下のメッセージが出た。
../include/wx/thrimpl.cpp(50): assert “m_internal” failed in TryLock(): wxMutex::TryLock(): not initialized [in child thread] Trace/breakpoint trap
ログファイルを添付するが、ビットコイン再起動の前にバックアップを取り忘れたので、ログのどの時点でクラッシュが起きたかは分からない。
幸いセグメンテーション違反にはまだ遭遇していない。直前までのビルドでセグメンテーション違反の頻度には大きなばらつきがあったので、引き続き動かして、問題があれば知らせる。
サトシ・ナカモトのメール（2009年11月17日16:57 UTC）test 7：
念のため、実行前にデータディレクトリをバックアップしてほしい。
Db::open/Db::close「Bad file descriptor」例外の回避策だ。初期ブロックダウンロードも高速化される可能性がある。回避策は、データベースハンドルを開いたままプログラムの実行中ずっと保持しておくことで、実際これはより一般的なやり方でもある。常に閉じたり開いたりしなければ、エラーが発生する機会がなくなるはずだ。
唯一の例外はwallet.datで、書き込み完了後にトランザクションログをdatファイルにフラッシュするために閉じるようにしている。これにより、datファイルが単体で有効になる。Bitcoinの実行中に誰かがバックアップを取った場合、データベースのトランザクションログなしでもそれ自体で有効なwallet.datを取得できる。
これはデータベース処理の再構成なので、新たなデッドロックが見つかるかもしれない。通常、デッドロックが発生すると、UIの再描画が止まるか、まだGeneratingと表示されているにもかかわらずCPUを使用しなくなる。
