7.11. コンパイラーおよび開発ツール


glibc の監査モジュールにおける再帰的な dlopen の呼び出しのサポートが強化されました

以前は、監査モジュールからの再帰的な dlopen の呼び出しにより、glibc の dl-open.c で、r_state == RT_CONSISTENT アサーションエラーが発生することがありました。その結果、監査モジュールがアクティブなときにアプリケーションが予期せず終了していました。この更新により、dlopen 呼び出しの実行中に、動的リンカーがその内部データ構造の整合性を、より早い段階で報告するようになりました。その結果、監査モジュールの再帰的な dlopen 操作が、より多くのケースでサポートされるようになりました。

Jira:RHEL-47403

glibc: 監査モードでの初期 TLS 割り当て中にアプリケーションがクラッシュする

以前は、監査モードで、プロセスの起動中にメインの malloc が初期化される前に、メインの realloc 関数を使用して、スレッドローカルストレージ (TLS) 管理に関連する内部データ構造が割り当てられていました。その結果、malloc によって割り当てられていないメモリーに対して realloc が呼び出されると、アプリケーションがクラッシュしていました。

この更新により、起動プロセスが完了するまで、動的リンカーが mallocrealloc のスタブまたは最小限の実装を使用するようになりました。初期 TLS 割り当て中にアプリケーションがクラッシュしなくなりました。

Jira:RHEL-71922[1]

glibc: ctype.h マクロが、複数の libc.so を持つマルチスレッドプログラムで、セグメンテーション違反を引き起こしていました

以前は、audit または dlmopen によって作成されたセカンダリー C ライブラリーコピー内の <ctype.h> の内部状態が、pthread_create で作成されたスレッドの初期化に失敗していました。その結果、セカンダリースレッドおよび名前空間で <ctype.h> の機能を直接的または間接的に使用すると、プログラムがクラッシュしていました。

この更新により、セカンダリースレッドおよび名前空間の C ロケールを参照するように、<ctype.h> の内部状態が初期化されるようになりました。その結果、上記のような状況で <ctype.h> 由来の機能を使用しても、クラッシュが発生しなくなりました。

Jira:RHEL-72017

glibc の監査ロギングが、完全なオブジェクトライフサイクルの追跡を提供するようになりました

以前は、glibc の動的リンカーが、セカンダリー名前空間において、先に la_objopen を呼び出さずに、プロキシー ld.so リンクマップに対して la_objclose を呼び出していました。そのため、共有オブジェクトを追跡するために la_objopen に依存するツールにとって、オブジェクトのライフサイクルに関する報告が不完全なものになっていました。

追跡を確立するために la_objopen に依存している監査ツールは、プロキシーリンクマップを確実に監視できませんでした。そのため、監視能力に不足が生じ、アンロードイベントが誤って解釈される可能性がありました。

この更新により、glibc の動的リンカーは、セカンダリー名前空間内のプロキシー ld.so を含め、該当するリンクマップに対して la_objopen を生成するようになりました。これにより、監査インターフェイスのシーケンスの一貫性が確保されます。

その結果、監査機能が、一貫した la_objopen および la_objclose のペアを使用して、プロキシーリンクマップをそのライフサイクル全体にわたって追跡できるようになりました。これにより、監査ツールと診断の信頼性が向上します。

Jira:RHEL-49549

glibc を監査モードで実行しても、特定のプログラムがクラッシュしなくなりました

この更新前は、LD_AUDIT モードの glibc 動的リンカーは、リンカーがメインの malloc サブシステムを初期化する前に、メインの calloc 関数を使用して内部データ構造を割り当てることがありました。そのため、プログラムの起動時にプロセスが calloc 関数で予期せず終了することがありました。この更新により、プロセスの起動シーケンスが変更されました。その結果、起動時に使用される内部の malloc 実装を使用して、メインの malloc 関数に切り替える前に calloc メモリー割り当てが行われるようになりました。その結果、動的リンカーが監査モードを使用している場合でも、プログラム実行時に、起動中に calloc 関数内でプログラムがクラッシュしなくなりました。

Jira:RHEL-48820[1]

glibc の stdio フラッシュの問題が修正されました

この更新前は、glibc の特定の stdio ストリームにおいて、バッファリングされた読み取りを行った後に正しい位置へシークして戻ろうとすると、fclose の実行中に処理が失敗することがありました。その際、シーク不可能な入力に対して、期待される ESPIPE ではなく EINVAL が返されていました。その結果、パイプやその他のシーク不可能な記述子に対して fclose を使用するアプリケーションでは、予期しないエラーが発生する場合がありました。これにより、I/O のクリーンアップが失敗し、ファイルの位置指定動作に一貫性がなくなることがありました。

この更新により、glibc は、バイトの読み取り後に lseek が 0 を返した場合、ESPIPE エラーを生成するようになりました。これにより、fclose がシーク不可能な状態を意図どおりに無視するようになり、動作を検証するためのテストインフラストラクチャーの変更 (xdup など) がサポートされるようになりました。その結果、fclose およびそれに関連する stdio 操作が、シーク不可能なストリームに対して一貫して動作するようになりました。これにより、バッファリングされた I/O に依存するアプリケーションで、エラーが起きる状況が減り、信頼性が向上しました。

Jira:RHEL-68805[1]

popenfork を並行して呼び出しても、アプリケーションでデッドロックが発生しなくなりました

この更新前は、マルチスレッドアプリケーションが別々のスレッドで popenfork を呼び出し、かつ popen が内部ロックを保持している間に fork が発生すると、子プロセスがロックされた状態を継承することがありました。子プロセスが再度 popen を呼び出した場合には、デッドロックが発生することがありました。

この更新により、glibc が fork 全体の関連するロック状態を解放し、後続の popen 呼び出しがブロックされることなく続行されるようになりました。その結果、popen がマルチスレッドの fork 呼び出し後にデッドロックにならなくなり、サポートされているアーキテクチャーのプロセスの信頼性と入出力動作が向上しました。

Jira:RHEL-59712[1]

go-rpm-macros の Golist コマンドラインパーサーの修正

この更新前は、コマンドラインパーサーの置き換えにより、Golist が特定のファイルを正しく処理していませんでした。その結果、一部のプログラムのビルドが失敗していました。この更新により、Golist に元のコマンドラインパーサーが復元されました。

その結果、Golist が必要なすべてのファイルを正しく処理し、プログラムが期待どおりにビルドされるようになりました。

Jira:RHEL-7366

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat