問題タブ [glibc]

glibc 正規表現関数を測定した経験のある人はいますか? そのような測定を行うために実行する必要がある一般的なテストはありますか (検索する正確なパターンのテストに加えて)?

ありがとう。

以下は、よく知られている LAPACK 数値ライブラリの Fortran ZHEEVR ルーチンの C ラッパーです。

この関数は、私のアプリケーションで何十万回も呼び出され、同じ行列サイズの複素行列 "a" (パラメーター名はこの関数の Fortran 規則に従います) を対角化します。対角化された行列は同じ構造になるため、作業配列のサイズはほとんどの場合同じになると思います。私の質問は次のとおりです。

1. alloc/free (「alloc_memory」は glibc の malloc の単純なラッパーです) 呼び出しを繰り返すと、パフォーマンスが低下する可能性がありますか?
2. フリーの順番は関係ありますか？最後に割り当てられた配列を最初に解放するべきですか、それとも最後に解放すべきですか?

重複の可能性:
Malloc スレッドセーフ?

glibc の malloc() はスレッド セーフではないと聞きました。プロセスの複数のスレッドが同時に malloc() を呼び出すと、未定義の動作が発生するからです。そして私の質問は、スレッドが free() を呼び出した場合、別のスレッドが malloc() を呼び出している場合、これも未定義の動作につながるのでしょうか?

Linux ベースの (arm) 通信アプリケーションで、予期しないタイミングで次のエラーが発生します。

Google はそのエラーに関する多くの参照を見つけましたが、私の状況に関連すると思われる情報はほとんどありません。このエラーのトラブルシューティング方法について誰かがアイデアをくれないかと思っていました。この主張の一般的な原因を知っている人はいますか?

前もって感謝します。

メインの gtk スレッド (別のスレッドから) に通知を使用しようとしていますが、パイプを使用して発生したものもあります。パイプをセットアップしようとすると、次の警告が表示されます。良い回避策は何ですか?

このg_io_channel_win32_new_fdができると、この警告が表示されるため、パイプはまったく作成されません:(

GLib-WARNING **: giowin32.c:1564: 3 は C ライブラリ ファイル記述子ではありません

目標は、スレッド スレッドで何かが発生したことをメイン アプリケーションに通知することです。私の場合、マルチスレッドの方法で gtk を使用できない (生成されたスレッドからメインスレッドの関数を呼び出す) ため、パイプ経由で実行しようとしています。

また、このスレッドでビジュアルスタジオの問題である可能性があることもわかりました

助言がありますか？

Cygwin x サーバーを利用したかったのですが、プログラムを起動しようとすると、glibc が古すぎると言われました。私はバージョン 2.3.2 を持っていますが、バージョン 2.3.6 が必要です。これを更新する簡単な方法はありますか？Cygwin セットアップ ルーチンでこのパッケージを見つけることができません。

ありがとう

そのような関数は標準的ではない可能性が高いことを認識していますが、私のユースケースでは問題ありません。基本的に、ポインター（malloc（）への以前の呼び出しによって返されたポインター）にポインターを渡すことができるメソッド（glibcのsyscall（）インターフェイスを介してのみ公開されている場合でも）が必要です。このメソッドは、ポインターのブロックのサイズを返します。でポイントします。そのようなものは存在しますか？

getpwnam_rを使用して、プログラムのクライアント接続を処理します。悲しいことに、それは決して解放しないバッファを割り当てているようです。関連するvalgrindの出力：

getpwnam_rにバッファを解放するように指示する方法はありますか？または、これらのValgrindエラーを抑制する必要がありますか？

ありがとう、Kasper

/lib/libc.so.6したがって、glibcは通常の実行可能ファイルのようにシェルで実行できることを誰もが知っているでしょう。その場合、glibcはバージョン情報を出力して終了します。これは、.soでエントリポイントを定義することで実行されます。場合によっては、これを他のプロジェクトにも使用すると面白いかもしれません。残念ながら、ldの-eオプションで設定できる低レベルのエントリポイントは少し低レベルです。動的ローダーが使用できないため、適切なライブラリ関数を呼び出すことができません。このため、glibcは、このエントリポイントでネイキッドシステムコールを介してwrite（）システムコールを実装します。

私の質問は、他の.soの関数にアクセスできるように、そのエントリポイントから完全なダイナミックリンカーをブートストラップする方法を誰かが考えられるかどうかです。