コラッツ木検定ツールとゼルコバの木が完全連動するようになったので，効率的にテストできるようになったが，検証テストでテストカウント3200を指定したときにハングしてしまうという問題が出ている．出力されたADLファイルを見ると，ノード数は3827で，ゼルコバの木のカード数上限の7000まではまだまだある．テストカウント3000では多少時間は掛かるが問題なく描画できているので，原因を突き止めておく必要がある．⇒極大セグメント検定でハングしているようだ．
いや，極大セグメント検定からは抜けているが，三極検定でループしている模様だ．CompleteはTRUEになっているが，perfectがFALSEのままになっている．ループカウントオーバーというのは見ているが，ループを一周するのに相当時間が掛かっているようだ．ループカウントが3646を超えるとレッドラインオーバーが発生するが，それまでに日が暮れてしまいそうだ．REDLINE=10に変更し，強制的にブレークするようにして描画まで進んだが，まだ，どこかで詰まっているところがある．画面の半分しか描画できないだけでなく，タイトルバーをつかんでウィンドウをドラッグすることもできない．
いや，まだ，計算は完了していない．画面は以下のように変わった．
しかし，制御はまだ戻ってきていない．水平スプリットの検査に手間取っているようだ．⇒スプリット検査を止めたら抜けてきたが，画面は上と変わりない．左上隅に小さな集落がある他は，広い範囲にごく短いヤブが生い茂った状態だ．系統が２分解し，ノード１を先祖ノードとする始系列ともうひとつの系列に分かれている．後者の先祖ノードは#1825のようだ．#1825の親は#1369だが，カードで見ると親なしになっている．#1369の親は#1027で子どもは#7301だけになっている．
結局，#1369→#1825という親子関係が失われているということになる．ゼルコバの木のダンプで見ると，このサンプルのカード数は5045，結婚数は3645．この数は上で「ADLファイルを見ると，ノード数は3827」としているのよりも少ない．ソースコードを見ると，最大カード数は0x2000=8192，最大結婚数も同じ8192だ．MAXCHILD＝12となっているが，12人より子どもが大きいときには複数の結婚ページを使うことができたはずだ．MAXMARRIAGE 32となっているので，384人までの子どもを持つことができるはず…実際問題として，もっとも子どもが多いのは1の6人，いや，5にも6人の子どもがいる．
「ADLファイルを見ると，ノード数は3827」というのは，ADLファイルの行数が3827という意味であり，この数は結婚数と一致していなくてはならない．しかし，実際には3645というのだから，182個も少ない．これもかなりおかしい．結婚が切れているとしたらその子どもはすべて親なし，つまり先祖ノードになってしまうから，系列がその数だけ発生しなくてはならないと考えられるのだが…ともかく，ADLから変換したCSVを保全してチェックしてみることにしよう．⇒CSVでは
#1825,男,1825,,,,,,,,,,,,,,,,1,1,1,#1369,,1
#7301,男,7301,,,,,,,,,,,,,,,,1,1,1,#1369,,2
のようなレコードがあり，#1369→#1825という親子関係は活きている．#1369のもう一人の子どもである#1825は問題なく繋がっている．どういうことだろう？世代数には上限はなかったはずだが…始系列はmin=0, max=115とあるので，世代数では116世代ということになる．いや，この数字も奇妙だ．コラッツツールの画面ではTree height は96になっている．この数字が正しいとすれば，どこかで連結を誤っていることになる．このテストでは１～6399の奇数を検定したとなっている．
Total odd number count: 3200 というのは疑問のある数字だ．確かにテストされた奇数のカウントは3200だが，Total odd number には木に含まれるノード数を表示すべきではないか？いや，同じノードが何度も重複出現するため，それをこの場でカウントするのは無理だ．⇒Total odd number countを Tested odd number count に変更した．
問題のレコードは少なくともVBからはDLLに送信されている．TREEVIEW::sendUpdateDataではこのレコードを受信して処理している．LINKTABLE::ImportEndでは1825は父1369を持っている．⇒いや，違う．1825はImportEndでMakeMarriagePageに失敗している．⇒LINKTABLE::MakeMarriagePageの中で「上流で循環」が発生している．1825の曽祖父である1541の親が本来289のところ1825になっている．少なくともADL上ではこの間違いは起こっていない．CSVにもこの誤りはない．従って，インポート処理中の誤りと推定される．
どこかで誤動作しているのだろうか？LINKTABLE::ImportEndの2周目でこの値が入ってくる．⇒いや，違う．もっと前だ．ImportTableFuncで送信した1825の2番目の子ども9733のレコードを処理するところで誤動作している．LINKTABLE::GetRefnumが9733の参照番号を求めているのに対し，1541が返されている．上記したように，カードテーブルのサイズ上限は8192なのでそれを超える値に対し，ハッシュした代替値が返されたのだろう．⇒VB側でMAXPDB=7000になっていた．ただし，これは多分動作には影響していないと思う．おそらく，この後に本物の1541が登場し，その位置に座ってしまったのではないか？
どうも，この不良は手順が悪いためではないかという気がする．TREEVIEW::sendUpdateDataでは，breakNumberでは名前から参照番号を取り出しているが，この関数から呼び出しているGetRefnumでは，ハッシュ化を実行している．しかし，この参照番号はその場では登録されず，事後にまとめて処理されているため，ハッシュの衝突が発生しないので，重複登録が容易に発生する状況になっている．これを安全に実施するためには，breakNumberの中でカード登録を行うしかないのではないか？⇒対処した．これで一応画面は表示できたが，目を覆うような惨めな結果になった．
特にひどいのは，ルートノード1だ．画面の一番下にどこにもつながらない状態で孤立している．縦書きに戻してみよう．⇒三極検定のループカウント上限を10に設定した状態では上と同じ図面になってしまうが，上限を100まで上げたところ，ループカウント32で抜けてきた．
形状は以前「蝙蝠」と呼んでいたものとほぼ同型だ．カード数は5045点．カード数上限は8192となっているので，もう少し大きくしてみよう．テストカウント4000を試してみる．⇒三極検定のループカウント33で抜けてきた．カード数は6365になった．最大枝数は8，樹高は96．
前にテストカウント3000というサンプルを取っているので，取り直ししてみよう．⇒なぜだろう？レッドラインオーバーになってしまった．
障害の原因が左端に孤立したルートノード1であることは明らかだ．なぜ，こんなことが起きているのだろう？結婚枠をカラー表示してみると下図のようになる．
コラッツ特注版では結婚枠はつねに中吊りしているのだから，全体を左シフトして最上層の結婚枠中央に１が来るようにすればよいだけと思われるのだが… なぜそれができないのだろう？いや，もしかすると「結婚点の一致」という操作を止めていたかも…⇒試験的に止めていたこともあるが，戻している．CheckMargPointで毎回移動が発生している．移動量は変動があるが，つねに正で48960などの大きな数値だ．