状況:私はPython ctypesモジュールを使用してc共有ライブラリを読み込みます。実際にctypesモジュールはRTLD_NOWで共有ライブラリをロードするためにdlopenを使用します。共有ライブラリを使用すると、非常に奇妙な関数アドレスと呼ばれるときにクラッシュしました。以下のようなdlopen with RTLD_NOW結果がクラッシュする
コアスタックは、次のとおりです。
(gdb) bt
#0 **0x00000000001723f6** in ??()
#1 0x00007f39a9d1b506 in do_io()
from /home/z/libgshared.so
#2 0x00007f39b84dddf5 in start_thread (arg=0x7f39a9101700)
at pthread_create.c:308
#3 0x00007f39b7b021ad in clone()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
を、私はより深く行き、奇妙なアドレスがdlopenのは、機能の一部に実際のアドレスを計算しないことを意味GOT、からである見つけます。
(gdb) disas 0x7f39a9ba63f0
Dump of assembler code for function [email protected]:
0x00007f39a9ba63f0 <+0>: jmpq *0x42d452(%rip) # 0x7f39a9fd3848
0x00007f39a9ba63f6 <+6>: pushq $0xf06
0x00007f39a9ba63fb <+11>: jmpq 0x7f39a9b97380
End of assembler dump.
(gdb) x/2a 0x7f39a9fd3848
0x7f39a9fd3848: **0x1723f6** 0x172406
(gdb)
アドレス0x1723f6が正確なフレーム0
で芯のアドレスであることがわかり、これが起こっている理由だろうか、とどのように私はそれを回避するか、それを修正することができますか?
ご報告いただきありがとうございます。私は自分のcentos7 VM上でglibcのバージョンをチェックします。glibcのバージョンは2.17で、そのバグの修正が含まれています。この結果をもたらす他の可能性はありますか?共有lib依存関係はどうですか? – zuanyg