あと一人で総訪問者数が３万人に達する．この幸運をつかむラッキーな人はどこの誰だろう？気付いたらスナップショットを送ってください．撮れた！わたしじゃないよ．現在オンライン中の人数が2になっている…
これはつまり，スナップショットが撮れたからその人が当人とは限らないということだね．プログラムのデバッグてのはこんなものではないかと思う… しかし，こういう瞬間に立ち会えるということは，ラッキーな人は一人じゃないってことかもしれないね．いままでこんなことは一度も経験したことがない… 少し運が向いてきたのかな？
▲BUG20-12-02 01-34-26.ZELを#195 ghostnodeで起動して，PAIRLIST::CheckNormalizedSectionで(pbox->getpairlist() != this)という理由で停止した
障害の発生している地点は昨日とは異なるが，同じ状態で停止している．⇒修正が徹底していなかった．deleteElementではdeleteの場合とnodl_floatの場合を処理しているが，nodl_floatではデストラクタの出番はないため，親リストの内部処理でdataCountDownを実施しなくてはならない．⇒pairbox.cppに未修正の論理が残っていた．これで「blackflagを廃止する＠20201203」の修正は一応通ったことになる．
これまでdataCountDownを直接呼び出していたところはすべてdeleteElementの呼び出しで置き換えた．また，unsettledのセット・リセットはdeleteElementで行っているので，呼び出し側では不要となる．blackflagはまったく使われていないので，「blackflagを廃止する＠20201203」を現状でフィックスしてよいだろう．PAIRLISTではあと5箇所nodl_floatが使われている．うち一つはPAIRLISTそのものが対象だが，他の4つはdeleteElementに置き換える可能であることを確認してみよう．⇒問題なさそうだ．
PAIRLISTにはまだdataCount()を直接操作しているところがいくつか残っている．これらをすべて共通処理として隠蔽したい．⇒その前に「参照チェックリストの廃止」を片付けてしまおう．この参照リストはデバッグ用にシステムに1個だけ設置されているが，すでに完全参照リスト管理を持っているので不要になっている．このリストはNODULEの特殊スロットにリンクされているが，間違い易いので廃止しておくのが賢明だ．バックアップを取ってから始めることにしよう．⇒実装した．問題なく動作するようになった．
この修正は後戻りしない修正とし，バックアップを取った上で「nodl_floatをdeleteElementで置換＠20201204」と「XPAND_ANCHORを廃止する＠20201204」をフィックスすることにする．このバックアップは「ZELKOVA 2020-12-04 改訂」として保全した．⇒修正完了した．dataCount()を操作しているところが12箇所ある．リストアップしてみよう．
- PAIRBOX::MoveSamePoint
▲PAIRBOX::MoveSamePointの論理に誤りがある この関数ではノード対（共有端点リスト）を別の共有端点リストに移動しているが，移動元リストのdatacountをインクリメントしている．明らかにこれは誤りだ．⇒修正した．
▲LIST::remove, _removeを廃止する DATALIST::remove, _removeも廃止できる
この修正の影響範囲は予想外に大きい．GENELIST，NODELIST，EDGELIST，TRIBELISTなど軒並みLIST::removeを使っていた．修正後に走らせてエラーは出ていないが，これらの修正に関わるオブジェクトのデストラクタではdataCountDownを呼び出すようにしなくてはならない．nlistとNLISTのすべての派生クラスで対応する修正が必要だ．⇒いや，すでにほとんど入っている．⇒入っていないものもある．nlist<MARGBOX>とnlist<Bobject>だ．前者はTOPOLOGYのSymmetryListやTooYoungListとして使われている．後者はMARGBOX::SymmetricActionの中で一時的に生成/使用されている．現用サンプルではこの辺りの仕掛けはまったく作動していないようだ．
▲ZTシステム構成図7.ZELを開こうとしてPAIRLIST::ResetPairIndexでデータカウント不一致が発生した．再起動して新たに開こうとしたら，今度はcheckdatacount→nextboxで停止した．ノード対とノード対リストでチャンネルの不一致が起きている．
このエラーは少なくとも「LIST：_removeを廃止する＠20201204」の修正とは無関係だ．つまり，それ以前から発生していたものと思われる．すでに「後戻りしない修正点」を超えてしまっているので，戻ることもできない．⇒この障害はPAIRLISTのデストラクタの中で起きている．つまり，PAIRLIST自体がすでに削除中の状態になっている．しかも，このループに入る前にはcancelが実行されているので，リストは完全に空になっていなくてはならない．
確かに，datacountはゼロだし，listtopは空になっている．それでは何をやっているのか？⇒後続リストの繋ぎ替えということをやっているようだ．確かに後続リストというのは存在している．要素は1個だけだ．ResetPairIndexに入る直前にPindexを書き換えているので，不一致になるのは当たり前だ．⇒こういうのはあまりよくないと思う．Pindexの値を引数で与えるようにしておこう．
ResetPairIndexを実行する前の状態ですでにデータ数不一致は起きている．これはTribeRelocationの出口近くのFoldingChannelsで起きているので，おそらくこの関数の中で失敗しているのだろう．⇒TRIBELIST：FoldingChannelsに入るところですでに不良が起きている．⇒ReduceMultiCardで起きているようだ．MoveChannelToで失敗している．⇒PAIRLIST::takeoutが間違っているようだ．⇒deleteElementを実行してdatacountが変化していない．⇒DATALIST::findが仮想関数になっていなかった．しかも，PAIRLISTは自前のfind関数を持っていない！いや，持ってはいるが，シグネーチャが一致しない．⇒仮想関数をオーバーライドして固有の関数を呼び出すようにした．
▲TRASHCAN::ReuseWasteで((int)Lastnum() != NEWOBJECTCNT)により停止した．lastnum=247111，NEWOBJECTCNT=247112でNEWOBJECTCNTの方が1多い．ということは通番を持たないオブジェクトがどこかにいるということになるのだが… NEWOBJECTCNTはTRASHCAN::ReuseWasteでカウントされる．lastnumをカウントアップしているのはsetNringで，以下のコマンドで新規番号が生成される．NRING_INSERT，NRING_REUSE，NRING_EMBED．
やはり，curnodは廃止する以外ないのではないか？operator new がネストして実行されている．SWOの中でcheckdatacountを実行しているが，この中でnextboxを実行してcurnodが更新され，参照の付け替えが起こるので参照リスト管理で新しい参照リストが生成される．リスト末尾も参照だが，検査中には変化しない… operator newの間はcheckdatacountしないというのが一番確実なのではないか？unsettled をnoduleクラス全体に適用できるようにするというのがよいと思う．
いや，少し勘違いしている．unsettledというのは環境ではなく，個物の状態でそれも個体ではなく，親ノードの状態だ．operator new という状態を伝達するには，何か環境を示す変数が必要になる．一番簡単なのはグローバル変数を作ってやればそれまでだが…いずれにしても，nextのような動作で参照が発生するというのはよくないと思う．curnodは即刻廃止すべきなのではないか？⇒やってみることにしよう．一度バックアップを取っておいた方がよかろう．
「LIST：curnodを廃止する＠20201124」という仕掛りのオプションがある．⇒片付いた．以下の関数を廃止した．
- nodule *insert(nodule *listnod, void *dp = NULL)
- nodule *next(void)
- void *listnext(void)
- void *listbefore(void)
見通しをよくするために，以下の3つのオプションは即フィックスすることにする．
- LIST：_removeを廃止する＠20201204 22箇所
- ResetPairIndexに引数を渡す＠20201204 5箇所
- LIST：curnodを廃止する＠20201124 30箇所
終わった！バックアップを取っておこう．
▲LIST::appendは廃止する．curnod廃止によりLIST::putと同義になったため．⇒まったく使われていなかった．
▲PAIRLIST::removeも廃止できる．