<前の日記(2005-06-01) 次の日記(2005-06-04)> 最新

おおいわのこめんと (2005-06-02)


2005-06-02

[Comp] GCC-3.3

どうも先日から某チャット用biffツールである Xitalkbiff が正常に動作していなかったので、おっかしいなぁ、と思っていたところ、デバッグ情報がチャットサーバのほうに垂れ流しになっていたらしい (x_x)。我ながら大迷惑。

内輪作成の TCP/IP デバッグツール server/connect でダミーサーバを作って試してみると、 確かに第1接続先にデバッグ情報が出力されている。 この状態で /proc/PID/fd を覗いてみても、0〜2がターミナルで、 3〜5がソケット、と平常通り。 その出力された文字列を strace の出力結果から grep すると、 確かに fd=4 に向かってログメッセージを吐いている。 デバッグ出力は vfprintf(stderr, ...) 使ってるのになぜ……。

仕方がないので、3年くらい放置したソースを眺め直す。 同じメッセージを今度はソースファイル中で検索してみると……

dprintf(4, "Draw|Calc (%d,%d)\n", draw, get);

……4? ええと、さっきの strace 記録でもそうだが、fd=0〜2 は標準入出力で、3がXサーバへの接続ソケットだから、チャットサーバは 4 から。 ……4!?

もしやと思って nm ./xitalkbiff | grep dprintf してみたら、出てきましたよなんか。

08049820 T _Z7dprintfiPcz
         U dprintf@@GLIBC_2.0

………。man dprintf

………やってられっか (-_-)

上の man にも書いてあるとおり、dprintf ってこの手の関数に良く使う名前だと思うんですけどねぇ。 で、xitalkbiff の dprintf は

void dprintf(int d, char *p, ...)
{
  va_list ap;
  if(d & Debug_Level) {
    va_start(ap, p);
    vfprintf(stderr, p, ap);
    va_end(ap);
  }
}

となっている。つまり、デバッグフラグはビットの集合になっていて、任意の情報の組合わせを選べるようになっている。 したがって第1引数は 1, 2, 4, 8, 16, ...。 で、今回、1と2はほとんど実害なくて、8以上はどうせエラーになるだけなので、 結局4だけが問題を引き起こしていたわけですな。やってられんすぎ。 gcc 2.95 で問題が起きなかったのは多重定義関数の優先選択順の仕様の違いかな。 p に const つけると挙動が変わったりするのだろうか……。 何れにしても標準ライブラリの名前が酷すぎるのが原因なんですが。

ついでなので、この問題と、もう1つ gcc-3.3 で起こっていた問題 *1 を解決して、 2年ぶりの新バージョンリリースとなりました。

ぶーぶー。

*1 こっちは……ちょっと微妙だけどたぶん仕様に厳密になったとかそういう 関係で露呈した問題のようにも思える。 プロトタイプ宣言と関数本体定義の両方でデフォルト引数を宣言していた。

[TrackBack URL: http://www.oiwa.jp/~yutaka/tdiary/trackback.rb/20050602 (note: TrackBacks are moderated: spams will not be shown.) ]

大岩 寛 (おおいわ ゆたか) <yutaka@oiwa.jp.nospam ... remove .nospam> .

Copyright © 2005-2014 Yutaka OIWA. All rights reserved.
Posted comments and trackbacks are copyrighted by their respective posters.

記事の内容について (Disclaimer / Terms and Conditions)