今日は、終わりが近いさる仕事を片づけようと強く心に決めて仕事場に出てきました。昨晩は、ちょっとMagSite1のソースをいじりすぎて、今朝は寝坊。遅めの時間でしたが、朝の日課としてメールを読んだりしていました。
そこにユーザー様からの1通のメールが。
りすと亭の正規のレジスト番号を入力しているのに、それが正規の番号と認識されないエラーメッセージがイベントログに記録されているようです。
最初の感想は、そんな馬鹿な、というものでした。
番号の認識プログラムは、Visual Basic 2.0の時代に作成して、そのままJavaに書き換えられ、C#に変わってずっと使ってきたものです。そう簡単に変なことにはならないはずです。
そのようなわけで、番号がおかしい可能性が高いだろう、ということで番号のチェックを行いました。
完璧です。
全く問題のない完全なりすと亭のための番号です。
ということは、プログラムの問題でしょうか。
さっそく、そのレジスト番号を開発環境に設定して走らせると、あっさりと番号をはね除けました。
いったい何が問題なのか。プログラムをトレースして調べていくと、計算したCRC値が負数の場合に正しい番号を誤っていると判断することが分かりました。この判定の比較は、intとuintの比較になっていました。これにより、ビット表現が同一であっても、正負の相違が存在する場合には、異なると判定されていたわけです。
原因は分かりましたが、なぜこんなソースになったのか分かりません。元のJavaのソースは全て符号付きで処理されています。符号付き整数と符号無しに整数の混用は危険だというのは当然のことですから、自分で書き換えたのではないような気がします。しかし、絶対に無いとも言い切れません。JavaからC#への変換に使用したのは、おそらくMicrosoft Java Language Conversion Assistant Beta 1です。Beta 1ですから、これが不完全で安全ではない変換を行った可能性もあります。とはいえ、作業手順が全てSourceSafeに記録されているか分からない(一段落してから最初のチェックインを行った可能性もある)ので、完全に突き止めることはできませんでした。
しかし、今回の問題への対策は完了しています。今回の問題に対するプログラムの動作の確実性、安全性は、得られたものと思います。もう大丈夫とは思いますが、万一、レジスト番号が正しく認識されない問題がある場合は連絡を下さい。
さて、対策が完了して、インストールパッケージを作成してテストサーバに入れてみました。しかし、どうもおかしい。レジスト番号を設定してサービスをスタートすると、うまくスタートしません。かなり焦りました。ですが、サーバをリブートしたところ、正常に動くようになりました。原因は分かりませんが、何かの理由で不整合が出ていたのでしょう。原因が分からないのは気持ちが悪いですが、とりあえずりすと亭のバグでは無さそうなので、様子見です。
