今日の来訪者数が568人になっている

こ,これはなんだ!?今日の来訪者数が568になっている.まだ,午後5時台だ.何が起きたのだろう?普段は行っても200を超えるくらいだ…

image

いま,見ると6時14分現在で625人に昇る.もし,これが本当なら,1日1000人も達成不可能な目標ではなくなる.にわかには信じ難い… 悪いことではないとは思うが… Googleアナリティックスの数字を見てみよう.こちらには,特に顕著な変化は現れていない.

image

All users=186という数字があるが,これは過去を含めたトータルの数字で山のピークでも40人だ.2つの統計の数字がかけ離れ過ぎているので,どちらも信頼できないという感じ… Googleアナリティックスにはコードを埋め込むという設定の仕方もあるようなので,いつかヒマになったらやってみることにしよう.

UNDOで「被参照カウント不一致」というエラーが出ている.CheckNringCountという検査ルーチンをベタ貼りして追跡し,UNDOSYSTEM::UndoRestoreが原因であることは(ほぼ)突き止めたが,まだ現場を押さえきれていない.

dump(char*)という関数の使い方を間違えていた.ほとんどのクラスではdump(char*)ではprintshortという関数の戻り値を返している.しかし,dumpで期待されているのは,引数のchar*にテキストを格納して復帰する動作である.⇒修正しなくてはならない.とんでもないしくじりがあったものだ… ⇒関係する箇所をすべて修正した.

参照カウント不一致がCountupReferenceによって引き起こされていることはほぼ間違いない.障害を起こしているのは,CARDTABLEとMARGTABLEと見られる.奇妙なのは,これらのテーブルに格納されているリンクはすべて接続であるはずなのに,参照とみなされているという点だ.⇒親番号が変化してしまっているためだ.基準ソートは実行しているが,カード並び替えではlookupを対象とする操作であり,リンクテーブルは操作していないはずなのだが… どこで変化してしまっているのだろう?SWOで追いかけてみよう.

snum=74のMARGLINKのpnumは1だが,snum=10のMARGTABLEのスロット9に入っている.ファイルはロードして基準ソートしただけなので,このオブジェクトは現物であると推定される.UndoRestoreの中でMARGTABLEがUndoCopyされた時点で不一致が生じている.つまり,Shadowのイメージではスロット10のオブジェクトのpnumが1ということになる.⇒確かに現物とイメージではまったく異なる内容になっている.現物ではスロット9には#129の結婚リンクが入っているが,イメージでは#74だ.前者は#1621→#2386で,後者は#1522→#1747だ.⇒NameNarabekaeの中でNAMESORT::SetNodeLinkというのをやっている.⇒いや,違う.「まず重みで昇順に並び替えを実施」した後に実施しているRenumberで書き換わっているようだ.しかし,これを実施しないとテーブルの整合性が崩れてしまう… この続きは明日やろう.


コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA