問題タブ [dlopen]

書き込もうとしているコードがあり、void関数、情報があります。

これは、メイン関数から別のファイルで呼び出そうとしています。dlopenを使用してsoファイルを開きたい。関数をどのように呼び出しますか：info。私の他のファイルから？

使おうとしています

info関数で未定義の参照エラーが発生します。

おそらく私が提供している情報が過剰であることをお許しください
.. 誰かが私にいくつかの解決策を提案してもらえますか.!

各インスタンスが独自のメモリを持つように、ライブラリを独立したスコープに複数回動的にロードしたいと考えています。それは可能ですか？

ポータブルな方法ではないと思います。dlopenPOSIX/Unix/Linux の友達と一緒にできますか? または、少なくとも私は今、特定のケースで MacOSX を気にかけています (そのため、後で他のシステムでも必要になる可能性があります)。

背景: 私が使用したいライブラリは、マルチスレッド セーフになるように設計されていません。ただし、各スレッドがライブラリの独立したインスタンスを使用するだけであれば、問題なく動作するはずです。

詳細な背景: readlinelib です。そこにマルチスレッドのサポートを追加すると、基本的にすべてを書き直すことになります。

私は少しハッキングしています。

で関数を定義するObjCコードがあります__attribute__((constructor)) void init。これを静的にMacOSXアプリにリンクします。また、他のMacOSXバンドルに静的にリンクされています。

ある場所で、MacOSXバンドルバイナリを直接ロードしdlopenます。最初の質問：それはそれをロードするのと同じくらいの違い[[NSBundle bundleWithPath:[NSString stringWithUTF8String:path]] load]ですか？

ではinit、このコードがどのようにロードされたかなど、プロセス環境に関する情報を取得したいと思います。たとえば、現在のプロセスのバイナリのファイル名（いずれの場合もCocoaアプリである可能性が非常に高い）。そして多分もっと。

valgrindSO自体の誰かが提案したように、私はちょうど1日前に使用を開始しました。これは素晴らしいツールですが、今日は問題が発生しました。次のエラーが発生します：definitely lost bytesしかし、エラーの場所を特定できません。

これがの出力ですvalgrind：

エラーは正確にはどこにありますか????

実際、私はxorauth.soここのコマンドでファイルをリンクして
いて、オプションのフィールドにいくつかの認証データを入力していますが、それはできません。

コマンドを実行した後、その位置にオプションの認証データが表示されず、
valgrindまた表示されますdefinitely lost bytesが、問題がどこにあるかはわかりませんか？ また、私はこのバリエーションを試してみましたvalgrind：

この出力がわかりません。フォルダにdl-errorなどという名前のファイルがありません。罪状認否は、問題にパッチを当てる正しい方法を教えてくれます。

編集： 提案されているように、デバッグ情報を含めるオプションを使用gccする必要があり-gます....しかし、問題は、makeコマンドを使用していて、実際にはこの実装が私によって行われていないことです。これは標準のパケットジェネレータツールであり、いくつかのバグがあります。バグが修正されるのを待つことができないので、これが原因で私のプロジェクトが途中で立ち往生しているので、自分の手で修正してみてください。それでは、どうすればよいか教えてくださいmake。私はこの状況に初めて直面しているので、makeとmakefileがどのように機能するかについてはわかりませんか？必要に応じて、ここにいくつかのファイルの内容を追加できます。

sendip.c（行番号575）

makeコマンドの出力

* Makefileの内容：*

dlopen() 内で発生するすべてのファイル システム アクセスをインターセプトしたい。最初は、実行可能な解決策のように見えますが、いくつLD_PRELOADか-Wl,-wrap,の技術的な理由により、それらを機能させるのに問題がありました。

• ld.so は、LD_PRELOAD が処理されるまでに、独自のシンボルを既にマップしています。最初の読み込みをインターセプトすることは重要ではありませんが、_dl_*ワーカー関数はこの時点で解決されるため、以降の呼び出しはそれらを通過します。LD_PRELOAD遅すぎると思います。

• ld.soの内部には機能的な がなく、 を呼び出すだけなmallocので、上記の問題を何らかの形で回避します。malloc()free()memset()

• __libc_read()に含まれるファイル システム ワーカー関数ld.soは静的であるため、 でインターセプトできません-Wl,-wrap,__libc_read。

これはすべてld.so、ソースをラッパーにリンクするのではなく、ソースから直接ビルドする必要があることを意味する場合があります。ここでの課題は、 と の両方libcがrtld-libc同じソースから構築されていることです。のビルド時にマクロIS_IN_rtldが定義されることはわかってrtld-libcいますが、パブリック インターフェイス関数をエクスポートしながら、静的データ構造のコピーが 1 つだけであることをどのように保証できますか? (これは glibc ビルド システムに関する質問ですが、これらの詳細に関するドキュメントは見つかりませんでした。)

中に入るより良い方法はありますdlopen()か？

注：FUSEこれは、そのようなことをサポートしない最小限の「計算ノード」カーネル用であるため、Linux固有のソリューションは使用できません。

私はdlopenを使用して「lib1.so」などの動的ライブラリをロードし、A1などの1つの公開された関数を呼び出します。A1関数はmallocを使用して100kbの動的メモリを割り当てますが、それを解放しません。メイン関数で再びすべてdlcloseします。[dlopen、関数 A1 の呼び出し、dlclose]

この手順を 10 回繰り返します。Purify はこれを 1000KB のメモリ リークとして報告し、valgrind は間接的に 1000KB を失ったと報告します。

100 KB * 10 回 = 1000KB を提案していただけますか? 本当のメモリ リークですか? dlclose を呼び出したので、動的ライブラリに割り当てられたすべてのメモリは、dlclose を呼び出すと自動的に解放されますか?

OS: Linux プログラミング lan: C

プロセス内の動的ライブラリへの参照の数を調べる方法はありますか? つまり、アプリケーションでは、多くのモジュールが dlopen を使用して同じライブラリをロードしている可能性があり、モジュールが dlclose を実行した場合、ライブラリが本当にアンロードされているのか、それとも参照が減分されているだけなのかを知ることができますか?

Linux の C++ 共有ライブラリに奇妙な問題があります。

このプロセスはライブラリを 2 回ロードおよびアンロードします (これは設計によるものであり、変更できません)。

1. 最初の dlopen() で、ライブラリ内のすべての静的メンバーが正しい順序で初期化されます。
2. 次に、最初の dlclose() が呼び出されると、破壊も期待どおりに、構築とは逆の順序で行われます。
3. 2 回目の dlopen() では、すべて問題ありません。最初と同じように、構築の順序は正しいです。
4. しかし、2 番目の dlclose() で、破棄の順序が突然破られます。デストラクタは、初期化されたときと同じ順序で呼び出され、静的オブジェクトがすでに破棄されたオブジェクトにアクセスしようとすると、SEGFAULT が発生することがよくあります。
5. その後 dlopen()/dlclose() を試みると、3 番目と 4 番目のステップが正確に繰り返されます。

最小限の例で問題を再現しようとしましたが、成功しませんでした.小さな偽の共有ライブラリでは、すべてが期待どおりに機能します. 私の大きなライブラリには、2 番目の dlclose() で大混乱を引き起こすものがあり、それは非常に大きいです。

gcc (3.2/3.4/4.1.2 を試した) や Linux ディストリビューション (RHEL 4/5、SuSE 10) への依存関係は見つかりませんでした。Web で同様のケースを検索すると、0 件の結果が得られました。類似したケースはありません。

実験中、atexit() ハンドラーの順序が影響を受けるかどうかを確認するために、atexit() へのいくつかの呼び出しを静的オブジェクト コンストラクターに埋め込もうとしましたが、影響があることがわかりました。手順 1/2/3 は正常に機能します (dlopen/dlclose/dlopen)。2 番目の dlclose では、atexit に登録されたハンドラーの順序が正しくありません。

答えが得られるとはあまり期待していませんが、問題を追求する方法についての提案をいただければ幸いです。

前もって感謝します、

アンドリュー・シェティニン

PS Update - GLIBC で atexit() のコードをデバッグしたところ、ヒットしているバグがあることがわかりました。実際には非常に単純なバグです。GLIBC 2.4 で修正されましたが、GLIBC 2.3.4 で作業できなかったのは不運でした。

C でいくつかの Linux ライブラリを動的にロードしています。

dlinfo

( 1を参照)。

ただし、ライブラリのサイズを取得するための情報は見つかりません。

私が見つけた唯一のことは、

/proc/[pid]/マップ

ファイルを開き、関連情報を解析します ( 2を参照)。もっとエレガントな方法はありますか？