icc で最適化(-O2)かけた共有ライブラリを ctypes から使うと segfault してしまうことがあって困っている
- 追記: icc でコンパイルした共有ライブラリって gcc でコンパイルされたプログラムから使えないのか! ということで一応解決(=どうにもなならないことが分かったw)。
この不具合が出るコードは最適化なしの icc や、 gcc だと最適化していても、そんな不具合は出ないしユニットテストも通しているので、自分のコードにあるバグでは無い気がする。
ちなみに不具合起こすコードセットは tkf / ctypes_icc / source – Bitbucket で管理しています。
自分のコードのミスでは無いとは思っていても、糞みたいなミスのせいだと良いなあ、だれか指摘してくれないかなあ、とか淡い期待を抱いています←ぉぃ
悩みどころ
このコードは、今研究で使っているシミュレーション用のコードを icc で動くか試していたら出会ってしまったもの。 そのコードは ctypes を直接使わずに RailGun を使っていたので、RailGunなしでこの挙動を再現しようとして作ったのが↓のコードです。
悩みどころなのは、
- ユニットテストは通しているとはいえ、 segfault するようなコードで研究続けるのが凄く気持ち悪い。
- マシンによって segfault したりしなかったりして再現性が無いので python か intel にバグ報告するのも躊躇する。自分のマシンでしか起こらないような不具合って報告しても良いものか…。
- cypesを介さないでCだけでプログラムを書くとこの不具合が再現できないので、valgrindというツールを使おうとしたんだけどCPython側の処理がうじゃうじゃでてきてついていけない。
- 最適化かけないと起こらない不具合なのでデバッガ(idb/gdb)で見ても意味不明…
…などなど。 もっとCのスキルがあれば、あとは機械語読めたりすれば、頑張りようがあるんだろうか。
ソース
以下の strange.c と run.py を準備して
icc -O3 -Wall -std=c99 -shared strange.c -o libstrange.so
python run.py
ってやると、 segfault を起こす (マシンもある)。
strange.c
run.py
icc -O{2,3} だと segfault
コンパイラとフラグを網羅的に変えて試すと、 python run.py の終了コードは
gcc -O0: 0
gcc -O1: 0
gcc -O2: 0
gcc -O3: 0
icc -O0: 0
icc -O1: 0
icc -O2: 139
icc -O3: 139
という感じなので、どうやら icc -O{2,3} のみで segfault が起こるみたい。
マシン毎で違う挙動
3つのPCでの挙動を調べたらそれぞれ違っていたので、比較のためにスペックと挙動をまとめてみるとこんな感じになった:
| デスクトップA | ラップトップ | デスクトップB | |
|---|---|---|---|
| このポストのコード | 不具合でる | でない | でない |
| シミュレーション用のコード | 不具合でる | 不具合でる | でない |
uname -m |
i868 | i868 | x86_64 |
OS (lsb_release -a) |
Ubuntu 10.04.2 LTS | Ubuntu 10.10 | Scientific Linux SL release 5.5 (Boron) |
| icc version | 12.0.0 20101006 | 12.0.3 20110309 | 12.0.0 20101006 |
| Python version | 2.6.5 | 2.6.6 | 2.6.5 |
| Numpy version | 1.3.0 | 1.3.0 | 1.5.0b1 |
