0.3.8でBitcoin生成が壊れた？
何か問題が発生しているのではないかと疑い始めていた。システムがコインの生成をやめたように見えたからである。1日あたり約1ブロックだったのが、1週間でゼロになった。
IRCでArtForzが、空のウォレットディレクトリで互いにのみ接続された2つのノードだけの隔離テストネットを実行してみることを提案した。クアッドコアのシステムを2台用意してセットアップした。合計8000 khash/秒以上のハッシュレートでありながら、約90分間ブロックが1つも生成されていない。これは問題の証拠と言えるだろうか、それともさらなる不運に過ぎないのだろうか？
システムはLinux 64ビットで、1台はIntelクアッドQ6600、もう1台はAMDクアッドPhenom II 940である。
公式0.3.8 Linux 64bitバイナリでDebian sid上で「楽しい」gdbセッションをしたところだ。 同じバグ。SHA256Transformからの戻り値の出力状態が常に初期状態と同じだ。 で…公式0.3.8 64bit Linuxバイナリ（bin/64にあるもの）で本当にブロックを生成した人はいるのか？ ああ、それとsvnの変更ログをざっと見たところ、そのバグはおそらくr118 = 0.3.6から存在していた。 ああ、それと公式バイナリをstripするのが良いアイデアだと思ったのは一体誰だ？ディスアセンブラでSHA256Transformを探すのに30分も無駄にした。
Quote from: ArtForz on August 09, 2010, 12:31:45 AM
公式0.3.8 Linux 64bitバイナリでDebian sid上で「楽しい」gdbセッションをしたところだ。 同じバグ。SHA256Transformからの戻り値の出力状態が常に初期状態と同じだ。 で…公式0.3.8 64bit Linuxバイナリ（bin/64にあるもの）で本当にブロックを生成した人はいるのか？ ああ、それとsvnの変更ログをざっと見たところ、そのバグはおそらくr118 = 0.3.6から存在していた。 ああ、それと公式バイナリをstripするのが良いアイデアだと思ったのは一体誰だ？ディスアセンブラでSHA256Transformを探すのに30分も無駄にした。
いい仕事だ！サトシにPMを送る頃だな。
苦労への報酬として5.01を送った。
32ビットLinuxビルドは自分でビルドしようとしない人にとっては問題ないようだ。正しくビルドされた64ビット版よりも数パーセント遅いだけだ。
そのフラグはSSE2を持っていないかもしれない古い32ビットマシン向けに入れられたのだろう。残念ながら、SSE2なしの64ビットx86_64というものは存在しないので、条件付きコンパイルにより中身が空になり、何もしない関数が生成された。
Quote from: lfm on August 09, 2010, 10:04:43 AM
32ビットLinuxビルドは自分でビルドしようとしない人にとっては問題ないようだ。正しくビルドされた64ビット版よりも数パーセント遅いだけだ。
そのフラグはSSE2を持っていないかもしれない古い32ビットマシン向けに入れられたのだろう。残念ながら、SSE2なしの64ビットx86_64というものは存在しないので、条件付きコンパイルにより中身が空になり、何もしない関数が生成された。
cmakeなどを使うべきだというもう一つの論拠だ。
SSE2はわずか2%の高速化しか追加せず、互換性の問題に見合わないと判断した。より安全なオプションを選ぼうとしていた。
Crypto++が実行時にSSE2を使用するかどうかを決定しているようには見えない。ブロックカウントパラメータを決定するためにSSE2を検出する箇所が1つあるが、SSE2関連の部分はすべてコンパイル時の#ifdefであり、実行時にどのように切り替わるかわからない。見ている場所が間違っているのかもしれない。
すべてのmakefileでSSE2を有効にすべきだろうか？ 64ビットでコンパイルする人がいる場合はそうしなければならないようだ。
Linux 0.3.8リリースの64ビット部分を再コンパイルする。
Quote from: satoshi on August 09, 2010, 06:50:41 PM
SSE2はわずか2%の高速化しか追加せず、互換性の問題に見合わないと判断した。より安全なオプションを選ぼうとしていた。
Crypto++が実行時にSSE2を使用するかどうかを決定しているようには見えない。ブロックカウントパラメータを決定するためにSSE2を検出する箇所が1つあるが、SSE2関連の部分はすべてコンパイル時の#ifdefであり、実行時にどのように切り替わるかわからない。見ている場所が間違っているのかもしれない。
すべてのmakefileでSSE2を有効にすべきだろうか？ 64ビットでコンパイルする人がいる場合はそうしなければならないようだ。
Linux 0.3.8リリースの64ビット部分を再コンパイルする。
非SSE2マシンではクライアントがクラッシュするから、その点は理解できる。 実際にはどちらが簡単かによる。互換性を壊すような機能を有効にすると、痛い目に遭うのは非技術系のクライアントユーザーだけだ。彼らの視点からすると、なぜか動かないとしか思えない。
ビルドのメモを充実させた方がいいと思う。例えば（64ビットシステムでコンパイルする場合は、この部分を必ず行うこと）のように。
一つのソースブランチで複数のオペレーティングシステムにクロスコンパイルするのは常に厄介な話だ。 Grin
Quote from: lachesis on August 09, 2010, 03:45:39 PM
Quote from: lfm on August 09, 2010, 10:04:43 AM
32ビットLinuxビルドは自分でビルドしようとしない人にとっては問題ないようだ。正しくビルドされた64ビット版よりも数パーセント遅いだけだ。
そのフラグはSSE2を持っていないかもしれない古い32ビットマシン向けに入れられたのだろう。残念ながら、SSE2なしの64ビットx86_64というものは存在しないので、条件付きコンパイルにより中身が空になり、何もしない関数が生成された。
cmakeなどを使うべきだというもう一つの論拠だ。
その通りだ。
最終的にはビルドに関するすべての煩わしさを解消し、win/unix 32/64ビットのすべてのプラットフォームの組み合わせで信頼できるビルド手順を確立するつもりだ。
そういえば、現在Windows向けのx64ビルドに取り組んでいるが、64ビットMSVCではX86_SHA256_HashBlocks関数がプロジェクトに存在しない外部定義に委ねられていることに気づいた。元のCryptoPPライブラリでは別のasmモジュールにあるようだ。Windows上でx64をビルドしている人たちは、C言語ソースのshaバージョンを使用するようにdefineを設定しているのだろうか？
再ビルドした64ビット版のLinux用0.3.8.1をアップロードした。難易度1でテストを実行し、ブロックが生成された。