09/05/01 00:30:08
今更だけど、なんで scim のバグがとれにくいのか思い出した。
-g つけてコンパイルすると、core 吐かなくなるからだ。
ほんと微妙なタイミングでバグってるんだろうな…
で、printf とか使って、一行ずつ各値を表示させて null とかないか調べてたんだけど、
それもタイミングを変えてしまうので、結局どこが原因なのか突き止められなかった。
ほんとはもっといい方法があるんだろうけど…
614:名無しさん＠お腹いっぱい。
09/05/01 01:43:28
>>613
> -g つけてコンパイルすると、core 吐かなくなるからだ。
> ほんと微妙なタイミングでバグってるんだろうな…
gcc なら -g でタイミングが変わるような改変は無いは
ずだけど…（そもそもコード自体に変化は無いと思う）。
考えられるとしたら（UNIX のメモリイメージには明る
くないけど） rodata な部分への参照が何らかのタイミ
ングではみ出していて、デバッグ情報のおかげでそれが
はみ出さなくて済んでいるとか？
615:名無しさん＠お腹いっぱい。
09/05/01 01:49:47
シンボル情報の無い core で落ちた辺りのアセンブリコー
ドをメモっておいて、シンボル情報のある方で objdump
--disassemble して比較するとか。
といってもリロケーション情報が無いから難しいか…。
gdb プログラム
で起動しておいて break main して run すると main
入り口で止まるから、その状態で disassemble するっ
てのは？
616:名無しさん＠お腹いっぱい。
09/05/01 01:50:58
-gをつけるのと-O,-O2を取るのを区別せずに言ってるだけかも
617:名無しさん＠お腹いっぱい。
09/05/01 01:54:38
>>614
そうなんすか。そうかも知れんす。っていうか自分もその辺全然知らないんで…
まあでもそんな感じなんすよ。
bus error だったか、segmentation fault だったか、それさえ忘れてしまいましたし…
でも何かそんな感じなんすよね…
618:名無しさん＠お腹いっぱい。
09/05/01 02:05:20
>>615
確か大体どの部分で落ちるかは確か見当がついていたので、
その辺になると一行ずつ実行させるようにgdbでやってたんですが、
もううろ覚えで何か分からんのですけど、確か並行するスレッドの方に問題がありそうな気がして、
結局難しすぎて止めたような記憶が…
今となってはちょっと確かめる時間もないので、なんもできないんすよね…
ちなみに自作のGTKプログラムと合わせてデバッグしてたんすが、
こうすると確実に落ちるってのが分かっていたので、まだ分かりやすかったんですけどね…
619:名無しさん＠お腹いっぱい。
09/05/01 02:48:00
>>618
> 確か並行するスレッドの方に問題がありそうな気がして、
スレッド毎にコンテキストは別なんだから普通は落ちた
方だけ気にすればいいはずだよ（間接的に他のスレッド
が影響しているとしても、「X であるはずの値が X で
ない」みたいなのは落ちたスレッドで観察されてるはず
だし）。
> こうすると確実に落ちるってのが分かっていた
この時点で send-pr すべきだったね…。この時メール
送ったのならメールで残ってない？