[OSASK 3054] from OSASK BOARD

[Itou_Tetsuya <mone !Atmark! imasy.or.jp>]

このメールは、OSASK伝言板に書き込まれた内容です。
この書き込みに返事を書く場合は、下のURLから書き込みを行なって下さい。


http://www.imasy.or.jp/~mone/osask/index.cgi?REFER=3c53f9ff_9196

From: 川合秀実
Message-ID: 3c53f9ff_9196
Date: 2002/01/27 22:00
Subject: nlink.c

>http://nikq.nothing.sh/osask/
>に関連ファイルをアップロードしておきました。
>gzipの関係でうまくダウンロードできなかった
>場合のために、coff.lzhにもまとめてあります。

　ありがとうございます。早速ダウンロードしました。そして、例によってanon
ymousさんがどなただったのかもようやく分かりました(笑)。すみません、今回
もお世話になります。なお、僕はcoff.lzhをダウンロードしました。

>テストは以下のように行っています。
>>nlink.exe  !Atmark! guigui00.rul helloc4.o
>すると、nlink.c 1004行目
>*image++ = 0;
>で落ちます。スタックをトレースしていくと
>453行目での呼び出しが原因のようです。

　追試してみました。確かに、

>addr:774
>align:0 -> 0
>addr:-1609825526

の出力を最後に、死んでしまいました。

　まず、nlink.cの1004行目は、

　　return symbolconv0(n, obj);

なので、これで落ちているとしたらlink0()の外になってしまいます。だからこ
れは書き間違いでしょう。

　僕はこのnlink.cを

#define __attribute__(x)

の一文を追加して無理矢理コンパイルしてみました。そうしたら、おお、あっさ
りとphase2まで進みました。そして理由を調べてみました。分かりました。非常
にくだらない問題です。

　51行目で、struct OBJFILESTRのflagsというメンバーを定義していますが、こ
いつをcharではなく、unsigned charにしてやってください。これでおそらく解
決します。

　ようするにcharへ0xffを代入すれば、それは-1になります。そして、そのせい
で、1014行目のfor文が常に成立してしまい、ストッパーを無視してありもしな
いデーターを元に作業を続けて落ちていたわけです。したがって、呼び出しもと
にはまったく罪がありません。

　そんなわけで、結論は２．のようです。

[OSASK 3051]へのレスです。

>> link0()がメモリリークを起こしているなら、エラー個所はlink0()内にあるはずです。
>確かにそうなんですが、
>link0のコール部分で渡している
>imageのアドレスがすでに領域侵犯を
>しているとgdbに指摘されてしまったので
>呼び出し側が原因かと思いました。

　それは引数がimageに渡される前の状態で警告しているとか、そういう問題で
しょう。デバッガにはよくあることです。