Pull Request on 2026年02月10日

dotnet/runtimeにマージされたPull RequestをAIで日本語要約

注意点

このページは、dotnet/runtimeリポジトリにマージされたPull Requestを自動的に収集し、その内容をAIが要約した内容を表示しています。そのため、必ずしも正確な要約ではない場合があります。


目次

  1. #124237 Merging internal commits for release/8.0
  2. #124236 Merging internal commits for release/9.0
  3. #124229 Further improvements to code-review skill
  4. #124224 Arm64 Sve: Fix double/float mask test issues
  5. #124189 [Wasm RyuJit] avoid reverse ops
  6. #124183 JIT: Enable inlining of runtime async methods without awaits
  7. #124180 Fix Tensor.Reverse for tensors with length-1 dimensions
  8. #124177 Lower GT_RETURN_SUSPEND blocks to BBJ_RETURN
  9. #124174 [release/10.0] Fix EH profiler notifications
  10. #124138 [Wasm RyuJit] bitcast
  11. #124110 [release/10.0] Fix token memory ordering issue reading from the MethodDef and FieldDef token tables (#123557)
  12. #124083 Fix MachO adrp/add and branch relocations with embedded addend
  13. #124070 [release/10.0] Fix missing release semantics in VolatilePtr
  14. #124055 Fix PerfMap crash when Enable IPC command is sent early in startup
  15. #124050 [release/10.0] [Mono][AOT] Add missing unlock in mono_aot_get_class_from_name if aot table_size == 0
  16. #123987 Fix handling of errSSLClosedGraceful from SSLWrite on macOS
  17. #123933 Fix custom Uri parser edge-case when UriKind.Relative is used
  18. #123931 Fix removing module from appdomain in DB_IPCE_UNLOAD_MODULE event
  19. #123806 Fix integer overflow in ArrayList.IListWrapper.BinarySearch and improve test coverage
  20. #123764 Move Uri tests from System.Runtime to System.Private.Uri and consolidate ExtendedFunctionalTests
  21. #123702 update EnterpriseTests containers
  22. #123594 fix Vector2/3 EqualsAny
  23. #123328 Fix authenticated proxy for dotnet restore
  24. #122748 Bump actions/upload-artifact from 5 to 6
  25. #122216 [automated] Merge branch 'release/8.0' => 'release/8.0-staging'

#124237 Merging internal commits for release/8.0

  • 作成者: @vseanreesermsft
  • 作成日時: 2026年02月10日 19:01:13(UTC)
  • マージ日時: 2026年02月10日 22:10:12(UTC)
  • ラベル: Servicing-approved area-System.Security

概要

このPRは、.NET 8.0リリースに向けたCOSE(Cryptographic Object Signing and Encryption)実装の改善をマージしています。主な改善点は、不定長CBORマップのデコード対応と、クリティカルヘッダー検証の強化です。特に、不定長配列の処理改善と空のクリティカル配列の拒否処理が追加されています。

変更内容

  • CoseMessage.cs: ヘッダーマップデコード処理を不定長CBOR構造に対応させ、エラーハンドリングを改善(+47/-9行)
  • DecodeSign1.cs: Sign1メッセージのクリティカルヘッダーエラーケース用テスト追加(定義長/不定長エンコーディング対応、+125行)
  • DecodeMultiSign.cs: MultiSignメッセージのクリティカルヘッダーエラーケース用テスト追加(定義長/不定長エンコーディング対応、+126行)
  • Sign.CustomHeaderMaps.cs: 定義長と不定長のクリティカルヘッダーエンコーディングをカバーするテスト追加(+35/-20行)
  • System.Security.Cryptography.Cose.csproj: サービシングバージョン番号とパッケージ生成動作を更新(+2/-2行)

パフォーマンスへの影響

影響なし。本変更はデコード処理の正確性向上と検証強化が主体で、パフォーマンス低下のリスクはありません。

関連Issue

なし

その他

  • 本PRはリリース8.0向けの内部コミットのマージです
  • クリティカルヘッダー処理において、空配列(crit: [])を明示的に拒否する仕様に対応しています
  • CBOR仕様に準じた不定長マップ/配列の処理が適切に実装されており、COSE署名検証の堅牢性向上につながります

#124236 Merging internal commits for release/9.0

  • 作成者: @vseanreesermsft
  • 作成日時: 2026年02月10日 18:48:54(UTC)
  • マージ日時: 2026年02月10日 22:10:32(UTC)
  • ラベル: Servicing-approved area-System.Security

概要

COSE(CBOR Object Signing and Encryption)メッセージのデコーディングおよび署名動作を更新し、不定長CBOR コンテナをサポート、およびcrit(Critical Headers)ヘッダーの検証エラーをCryptographicExceptionで明確に表面化しました。定長・不定長両方のエンコーディング方式に対応したテストも追加されています。

// 不定長マップのデコードと crit ヘッダー検証の改善を実施
// Sign1・MultiSign の両メッセージ形式に対応

変更内容

ファイル 主な変更内容
CoseMessage.cs 不定長ヘッダーマップのデコード対応、ヘッダー値検証失敗をCryptographicExceptionでラップ、空のcritヘッダー検証を追加
CoseMessageTests.Sign.CustomHeaderMaps.cs Critical Header署名テストを定長・不定長CBOR エンコーディング両方で実行するよう拡張(+35行)
CoseMessageTests.DecodeSign1.cs Sign1 デコードテストで、attached/detached・定長/不定長の組み合わせについてCritical Header エラーケースをカバー(+125行)
CoseMessageTests.DecodeMultiSign.cs MultiSign デコードテストで、同様にエラーケースを網羅(+126行)

パフォーマンスへの影響

影響なし(テスト拡充とエラーハンドリング改善のため)

関連Issue

なし

その他

注意点: Copilotレビューで指摘されている通り、CoseMessageTests.DecodeSign1.cs(true, true)分岐(detached + 不定長)でDetachedDefiniteHexが使用されており、実際には不定長エンコーディングがテストされていない可能性があります。この点は修正が必要である可能性があります。


#124229 Further improvements to code-review skill

  • 作成者: @stephentoub
  • 作成日時: 2026年02月10日 16:10:49(UTC)
  • マージ日時: 2026年02月10日 17:42:33(UTC)
  • ラベル: area-skills

概要

dotnet/runtimeのコードレビュープロセスを改善するPRです。AIレビュアーが、PR/Issueのコメントに左右されないよう、コード自体から独立した意見を先に形成してから判断するプロンプトに変更しました。また、レビュー結果に「Needs Human Review」オプションを明示的に追加し、より懐疑的で厳密なレビューを促進します。

変更内容

  • .github/skills/code-review/SKILL.md (+60/-33)

    • レビュープロセスを段階化:コード分析フェーズとPR/Issue評価フェーズを分離
    • 初期段階でコード単体から意見を形成し、その後PR narrativeを評価
    • レビュー出力形式に「Needs Human Review」を明示的に追加
    • AIの懐疑的・厳密な姿勢を促す指示を強化
  • .github/code-review-instructions.md (+1/-126)

    • 従来の長形式ドキュメント(126行)をSKILL.mdへのポインタに簡潔化
    • 単一の情報源(SKILL.md)への統一

パフォーマンスへの影響

影響なし(プロセスガイダンスの変更のため)

関連Issue

なし

その他

Copilotレビューから、テンプレートの一貫性に関する指摘あり:Detailed Findings内で「💡」が重要度オプションとして定義されているが、テンプレートヘッダー「#### ✅/⚠️/❌」には含まれていない点。この不一致は将来のドキュメント更新で解決すべき。


#124224 Arm64 Sve: Fix double/float mask test issues

  • 作成者: @a74nh
  • 作成日時: 2026年02月10日 14:55:03(UTC)
  • マージ日時: 2026年02月10日 18:29:41(UTC)
  • ラベル: area-CodeGen-coreclr community-contribution

概要

Arm64 SVE(Scalable Vector Extension)のマスクテスト失敗を修正するPull Requestです。float/double型のマスク値をビットパターンとして扱うことで、reinterpret/bitcast操作時の正確なマスク処理を実現しています。

変更内容

ファイル: src/tests/JIT/HardwareIntrinsics/Arm/Shared/Helpers.cs

主な変更:

  • デフォルト"全true"マスクの生成で、BitConverter.*BitsTo* を使用してnon-zeroなビットパターンを設定
  • AddSequentialAcross のマスクチェック処理で、マスクレーンの生の値をbitwiseで非ゼロか評価するよう修正
  • MaskBothSet でビットパターン等価性チェック(== 1)に変更し、数値等価性(== 1.0)チェックを廃止

パフォーマンスへの影響

影響なし(テストコード修正のため、本体のランタイムパフォーマンスへの直接的な影響はありません)

関連Issue

  • #124029(修正対象のissue)

その他

この修正はSVEマスク操作の正確性に関する問題を解決します。float/doubleのビットパターン解釈により、reinterpret_cast/bitcast経由でマスク値が生成される場合の信頼性が向上します。


#124189 [Wasm RyuJit] avoid reverse ops

  • 作成者: @AndyAyersMS
  • 作成日時: 2026年02月09日 17:48:32(UTC)
  • マージ日時: 2026年02月10日 19:11:05(UTC)
  • ラベル: area-CodeGen-coreclr

概要

WebAssembly (Wasm) ターゲット向けの JIT コンパイラにおいて、オペランド評価順序のヒューリスティクスを調整しました。通常の評価順序を優先し、GT_REVERSE_OPS フラグの使用を抑制します。リロップ(演算子の変更で実現)と可換操作(オペランドの交換で実現)の場合のみ、反転が可能です。

Wasm では評価順序の反転がコード生成に悪影響を及ぼす可能性があるため、明示的に反転を抑制することでコード品質を向上させます。

変更内容

  • src/coreclr/jit/gentree.cpp
    • SetIndirectStoreEvalOrder 関数で Wasm に対して allowReversal = false を強制し、間接ストア操作の反転を禁止
    • gtSetEvalOrder および gtSetEvalOrderMinOpts 関数において、Wasm 環境でのデフォルト交換パスで GTF_REVERSE_OPS フラグ設定を抑制

パフォーマンスへの影響

Wasm ターゲットのコード生成品質を改善する可能性があります。オペランド評価順序を統一することで、命令キャッシュの効率性やメモリアクセスパターンの予測性が向上する可能性があります。ただし、具体的なベンチマーク数値は PR に記載されていません。

関連Issue

なし

その他

この変更は Wasm 特有の最適化調整であり、x86/x64 などの他のプラットフォームには影響しません。将来的には、子ツリーの複雑さに大きな不均衡がある場合に反転を有効化することを検討しており、その際には一時変数へのスピルを処理する下位レベルの変更が必要になる予定です。


#124183 JIT: Enable inlining of runtime async methods without awaits

  • 作成者: @jakobbotsch
  • 作成日時: 2026年02月09日 16:47:33(UTC)
  • マージ日時: 2026年02月10日 22:22:49(UTC)
  • ラベル: area-CodeGen-coreclr

概要

JITコンパイラがawaitを含まない非同期メソッドのインライン化を可能にするPRです。awaitが存在しない非同期メソッドはアロケーション不要で比較的シンプルなため、これらのメソッドのインライン化により呼び出しオーバーヘッドを削減できます。

// インライン化の対象例:awaitなしの非同期メソッド
public async Task<int> GetValueAsync()
{
    return await Task.FromResult(42); // FromResultはawaitなしで最適化可能
}

変更内容

  • src/coreclr/jit/async.cpp (+74/-46): 非同期メソッドのインライン化判定ロジックを追加・改善
  • src/coreclr/jit/fgbasic.cpp (+9/-2): フロー分析でawait検出ロジックを更新
  • src/coreclr/jit/importercalls.cpp (+16/-8): メソッドのインライン化判定時に非同期メソッド処理を調整
  • src/coreclr/jit/inline.def (+1/-1): インライン化ルール定義を更新

パフォーマンスへの影響

改善点: awaitを含まない非同期メソッド(Task.FromResult、同期完了パスなど)のインライン化により、メソッド呼び出しオーバーヘッドが削減されます。これにより、呼び出し側でスタックフレーム生成と非同期ステートマシン構築の不要なコストが軽減されます。

関連Issue

なし

その他

このPRは破壊的変更なし。既存のawaitを含む非同期メソッドのインライン化方針は変わらず(従来通り制限的)、awaitなしのケースのみをスコープとしています。


#124180 Fix Tensor.Reverse for tensors with length-1 dimensions

  • 作成者: @Copilot
  • 作成日時: 2026年02月09日 15:18:20(UTC)
  • マージ日時: 2026年02月10日 16:52:58(UTC)
  • ラベル: area-System.Numerics.Tensors

概要

Tensor.Reverse<T>がlength-1次元(stride 0)を持つテンソルに対して不正な結果を返す問題を修正します。例えば、形状[1, 3]のテンソル[1, 2, 3]を反転すると、期待値は[3, 2, 1]ですが、修正前は[0, 2, 1]となっていました。

int[] data = [1, 2, 3];
var tensor = Tensor.Create<int>(data, [1, 3]);
var reversed = Tensor.Reverse<int>(tensor);
// 期待値: [3, 2, 1]
// 修正前: [0, 2, 1]  (最初の要素が未初期化)

変更内容

TensorShape.cs

  • AdjustToPreviousIndexのwrap時の値リセットを修正:lengths[rankIndex]からdestinationLengths[destinationRankIndex] - 1に変更
  • インデックスがアンダーフローした際、最後の有効インデックスに正しくリセット

TensorOperation.cs

  • ReverseInvokeの初期化を修正:「one-past-end」センチネル値を最内層次元に配置
  • destinationLinearOffsetLinearLength - 1 - negInnermostStrideに修正し、stride 0の内側次元に対応

TensorTests.cs

  • AssertReverseCorrectヘルパーメソッドを追加(フラット化された出力と期待値の比較検証)
  • 20以上の形状に対するテストを追加:1D([1][3])、2D([1,3][3,1][1,4])、3D、4Dテンソル

パフォーマンスへの影響

影響なし。修正はロジックの正確性に関するもので、パフォーマンス面への影響はありません。

関連Issue

#124105(元々の問題報告)

その他

  • テスト時は1ベースの値を使用して、未初期化要素(デフォルト値0)を検出可能に設定
  • 既存の明示的なReverse およびReverseDimensionテストは保持
  • 対称的なAdjustToNextIndexメソッドとの同等性が確保されました

#124177 Lower GT_RETURN_SUSPEND blocks to BBJ_RETURN

  • 作成者: @jakobbotsch
  • 作成日時: 2026年02月09日 14:16:40(UTC)
  • マージ日時: 2026年02月10日 22:21:47(UTC)
  • ラベル: area-CodeGen-coreclr

概要

AsyncSuspend組み込み関数の使用時に、GT_RETURN_SUSPENDノードがBBJ_RETURNブロック以外に存在する可能性がある問題に対応しました。ELTプロファイラーフックによるリターンマージにより発生するこの状況に対し、lowering処理を拡張してGT_RETURN_SUSPENDを含むブロックをBBJ_RETURNブロックに変換します。

変更内容

  • src/coreclr/jit/lower.cpp (+27行)
    • GT_RETURN_SUSPENDノードのlowering処理を拡張
    • ノードを含むブロックをBBJ_RETURNブロックに変換するロジックを追加

パフォーマンスへの影響

影響なし 本変更はコードジェネレーション時の正確性確保を目的とした修正であり、パフォーマンス上の変化は想定されません。

関連Issue

#124162

その他

ELTプロファイラーフックによるリターンマージが行われた場合、従来のローリング処理ではGT_RETURN_SUSPENDノードが適切に処理されず、ブロック構造が不正な状態になる可能性がありました。本修正により、プロファイラー構成下での非同期サスペンド処理の正確性が向上します。


#124174 [release/10.0] Fix EH profiler notifications

  • 作成者: @github-actions[bot]
  • 作成日時: 2026年02月09日 12:58:14(UTC)
  • マージ日時: 2026年02月10日 12:14:17(UTC)
  • ラベル: Servicing-approved area-ExceptionHandling-coreclr

概要

.NET 9で導入された新しい例外処理(EH)メカニズムで、プロファイラーの例外処理コールバック(ExceptionSearchFunctionEnter/LeaveExceptionUnwindFunctionEnter/Leave)がfunclet(catch/finallyブロック)に対して誤って複数回呼び出される回帰バグを修正しました。ネストされたfinallyブロックがある場合、同一メソッドに対して複数回のコールバックが発火し、プロファイラーの実装によっては クラッシュやmisbehaviorが発生する可能性があります。

変更内容

  • exceptionhandling.cpp: funcletの検出ロジックを追加し、funcletに対する例外処理コールバックの呼び出しを防止(+9行)
  • exinfo.cpp/exinfo.h: funclet情報の追跡用フラグを追加し、コールバック呼び出し判定を強化(+3行)
  • プロファイラーテスト: ExceptionTest.cs、exceptionprofiler.cpp/.hを新規追加し、nested finallyブロックでのコールバック呼び出し回数を検証するテストケースを実装(計281行のテストコード)

パフォーマンスへの影響

影響なし。本修正はコールバック呼び出しの不正な重複を削除するだけで、追加のオーバーヘッドは発生しません。むしろプロファイラーの不要な処理が削減されるため、プロファイリングのオーバーヘッドが軽減される可能性があります。

関連Issue

#123564(元の修正PR)、顧客からの報告に基づく回帰修正

その他

  • 互換性: .NET 9以前の動作に統一するため、破壊的変更なし
  • リスク評価: Low(修正は単にfuncletのコールバック呼び出しを抑止し、以前の動作に復帰させるもの)
  • 検証: 顧客から提供されたrepro codeを用いて検証済み
  • Backport: release/10.0ブランチへのBackport対応

#124138 [Wasm RyuJit] bitcast

  • 作成者: @AndyAyersMS
  • 作成日時: 2026年02月08日 02:38:01(UTC)
  • マージ日時: 2026年02月10日 19:11:15(UTC)
  • ラベル: arch-wasm area-CodeGen-coreclr

概要

WebAssembly向けのRyuJIT コンパイラにbitcast操作のコード生成サポートを追加しました。bitcast命令は型を変更せずにバイナリ表現を別の型として解釈する操作で、浮動小数点数と整数の間の変換などで使用されます。

変更内容

  • src/coreclr/jit/codegenwasm.cpp: bitcastノードのコード生成ロジックを追加(+43行)

パフォーマンスへの影響

影響なし。本変更は既存の機能ギャップを埋めるもので、パフォーマンス最適化ではありません。bitcast操作は無変換のバイナリ再解釈のため、実行時のオーバーヘッドはありません。

関連Issue

なし

その他

  • 本変更はWebAssembly環境におけるJIT コンパイラの機能完成度向上を目的としています
  • bitcast命令の実装により、浮動小数点⇔整数間の低レベル変換が正式にサポートされるようになります

#124110 [release/10.0] Fix token memory ordering issue reading from the MethodDef and FieldDef token tables (#123557)

  • 作成者: @davidwrighton
  • 作成日時: 2026年02月06日 22:27:34(UTC)
  • マージ日時: 2026年02月10日 00:20:34(UTC)
  • ラベル: Servicing-approved area-VM-coreclr

概要

メモリ順序付けに関する問題を修正したバックポート。TypeDefテーブルとMethodDef/FieldDefトークンマップテーブル間の読み込み順序が保証されておらず、特にArm64などの弱メモリ順序付けCPUで、実行時に予期しない読み込み順序が発生し、クラッシュを引き起こしていました。VolatileLoadを使用することで適切なメモリバリアを確保します。

// 修正前: メモリバリアなし(読み込み順序の保証がない)
VolatileLoadWithoutBarrier();

// 修正後: メモリバリアを明示的に挿入
VolatileLoad();

変更内容

  • src/coreclr/vm/ceeload.inl: LookupMapテーブルからの読み込み時にVolatileLoadWithoutBarrierからVolatileLoadに変更(+14/-2)
  • メモリ順序付けが不十分である理由を説明するインラインコメントを拡張

パフォーマンスへの影響

微小なパフォーマンス低下の可能性ありVolatileLoadVolatileLoadWithoutBarrierよりも厳密なメモリバリアを適用するため、わずかなオーバーヘッドが発生します。ただし、正確性と安定性の確保が優先されます。

関連Issue

#123557(main ブランチでの修正)をrelease/10.0にバックポート

その他

  • Arm64ハードウェアの利用増加により、このメモリ順序付けのバグがより頻繁に発生するようになっています
  • C#コンパイラを使用したビルドは、この修正なしでは起動時にクラッシュする可能性があります
  • mainブランチでテスト済みで、リグレッションなし
  • リスクレベル:低(パフォーマンスの微小な低下のみ)

#124083 Fix MachO adrp/add and branch relocations with embedded addend

  • 作成者: @jakobbotsch
  • 作成日時: 2026年02月06日 12:31:49(UTC)
  • マージ日時: 2026年02月10日 22:20:33(UTC)
  • ラベル: area-NativeAOT-coreclr

概要

MachO形式のバイナリにおいて、adrp/addおよびbranch命令の再配置(relocation)処理を修正しました。これらの命令は埋め込み加数(embedded addend)を持つことができないため、代わりに追加の再配置エントリを使用する必要があります。オブジェクトライターはすでにこうしたエントリの作成方法を知っていましたが、一部のケースで命令に埋め込み加数が残されていた問題を解決します。

変更内容

  • MachObjectWriter.cs: adrp/add および branch命令の再配置処理を修正し、埋め込み加数を命令から適切に除去。追加の再配置エントリ経由での処理に統一(+9/-15)
  • StackTraceTests.cs: テストコードの調整(+0/-1)

パフォーマンスへの影響

影響なし

関連Issue

#124015

その他

  • ARM64アーキテクチャのMachO形式バイナリ生成に関する修正です
  • 再配置処理は正確性が重要であり、このバグはランタイム時のアドレス計算エラーにつながる可能性がありました
  • 変更内容が限定的(24行のコア処理)で、既存の再配置エントリ作成メカニズムの適切な活用を促進するものです

#124070 [release/10.0] Fix missing release semantics in VolatilePtr

  • 作成者: @hoyosjs
  • 作成日時: 2026年02月06日 05:14:34(UTC)
  • マージ日時: 2026年02月10日 19:06:09(UTC)
  • ラベル: Servicing-approved area-VM-coreclr

概要

VolatilePtr テンプレートクラスのメモリバリア欠落バグを修正。基底クラス Volatile<P>operator= が release semantics を提供していたが、コンパイラ生成の代入演算子がこれを隠蔽し、メモリバリアなしの通常のストアを実行していました。Roslyn言語サーバーで非決定的なロックフリーレースによるクラッシュが発生していたため、using 宣言と明示的なコピー代入演算子を追加して修正します。

// 修正前: コンパイラ生成の代入演算子がrelease semanticsを失う
VolatilePtr<T, P> ptr;
ptr = other; // メモリバリアなしの通常ストア

// 修正後: 明示的な代入演算子がrelease semanticsを提供
class VolatilePtr : public Volatile<P>
{
    using Volatile<P>::operator=;  // 基底クラスのoperator=をスコープに導入
    VolatilePtr& operator=(const VolatilePtr<T,P>& other); // 明示的なコピー代入
};

変更内容

  • src/coreclr/inc/volatile.h (+13行): VolatilePtr テンプレートクラスに using Volatile<P>::operator=; 宣言と明示的なコピー代入演算子を追加
  • src/coreclr/gc/env/volatile.h (+10行): GCサブシステムの volatile.h に同じ修正を適用

パフォーマンスへの影響

パフォーマンス改善。メモリバリアが意図通り機能することで、スピンロック型の同期プリミティブ(DeadlockAwareLock::m_pHoldingThreadThread::m_pBlockingLock など)の write-acquire/read-release セマンティクスが正常に機能。スレッド間の可視性保証が確保されることで、複雑なソリューションで多数のスレッドがGC Static にアクセスする場合の非決定的クラッシュが解消。

関連Issue

#124071、#124096

その他

リスク評価:Low。メモリバリアはクラスの意図したセマンティクスであり、機能を復元する変更のため、破壊的変更なし。内部顧客の Roslyn 言語サーバーで実装されていたレアケース(複雑なソリューションで多数のスレッド競合)で検出された問題。


#124055 Fix PerfMap crash when Enable IPC command is sent early in startup

  • 作成者: @Copilot
  • 作成日時: 2026年02月05日 18:29:22(UTC)
  • マージ日時: 2026年02月10日 00:37:47(UTC)
  • ラベル: area-VM-coreclr

概要

CoreCLR起動初期にPerfMapEnable IPC コマンドが到達した際のクラッシュを修正します。起動中の早い段階でGetAppDomain()ExecutionManager::GetEEJitManager()がNULLである場合、PerfMap::Enable(sendExisting=true)がクラッシュしていました。初期化完了を示すフラグを追加し、sendExisting処理の依存関係が準備できるまで当該処理をスキップする対応です。

変更内容

  • perfmap.h: sendExisting処理の初期化完了を示すvolatile bool フラグを追加(6行追加)
  • perfmap.cpp: GetAppDomain()GetEEJitManager()のNULLチェックを追加し、初期化前の呼び出しを防止(21行追加)
  • ceemain.cpp: PerfMap::SignalSendExistingReady()呼び出しを追加し、SystemDomainAttach()とExecutionManagerInit()の後に初期化完了フラグを設定(4行追加)

パフォーマンスへの影響

影響なし。フラグチェックは軽量な操作であり、起動中の早い段階では sendExisting 処理がスキップされるため追加オーバーヘッドはありません。以降のJIT'd メソッドは通常通りログに記録されます。

関連Issue

#123438

その他

  • 起動タイムラインに基づき、DiagnosticServerAdapter::Initialize()の後で IPC リスナーが起動し、PauseForDiagnosticsMonitor()で早期コマンド受信が可能になっています
  • 検証済み: WSL2環境でDOTNET_DefaultDiagnosticPortSuspend=1を設定し、起動時にDiagnosticClient.EnablePerfMapを実行してもクラッシュしなくなることを確認済み(修正前はsigsegvで落ちていた)

#124050 [release/10.0] [Mono][AOT] Add missing unlock in mono_aot_get_class_from_name if aot table_size == 0

  • 作成者: @github-actions[bot]
  • 作成日時: 2026年02月05日 15:40:44(UTC)
  • マージ日時: 2026年02月10日 13:47:22(UTC)
  • ラベル: Servicing-approved area-Codegen-AOT-mono

概要

Mono AOTランタイムで、mono_aot_get_class_from_name関数においてaotテーブルサイズが0の場合にロックが解放されない問題を修正しました。この修正により、65,000を超えるタイプを含むAOTコンパイル済みアセンブリを持つMaui Androidアプリケーションのデッドロック問題が解決されます。

変更内容

  • src/mono/mono/mini/aot-runtime.c: 4行の変更(追加3行、削除1行)
    • mono_aot_get_class_from_name関数内でaot_table_sizeが0の場合、関数から戻る前にロックを適切に解放するコード追加

パフォーマンスへの影響

影響なし。本修正はデッドロック回避のためのロック管理修正であり、パフォーマンスへの直接的な影響はありません。むしろデッドロック状態を防止することで、アプリケーションの応答性を確保します。

関連Issue

#122097(元のPull Request) 顧客から報告されたMaui Android特定のデッドロック問題

セキュリティ・リスク情報

  • リスクレベル:
  • 理由: ロック解放漏れによるデッドロック問題の修正であり、セキュリティ脆弱性ではなく、スレッド管理バグの修正です。修正内容は単純で限定的なロック処理です。

その他

  • 影響範囲: Mono AOT(Ahead-of-Time)コンパイルを使用するAndroidアプリケーション、特に大規模なアセンブリ(65k以上のタイプ)を含むケース
  • Backport情報: release/10.0ブランチへのバックポート版です
  • テスト方法: 顧客提供の再現ケースで検証済み

#123987 Fix handling of errSSLClosedGraceful from SSLWrite on macOS

  • 作成者: @Copilot
  • 作成日時: 2026年02月04日 09:27:16(UTC)
  • マージ日時: 2026年02月10日 18:09:07(UTC)
  • ラベル: area-System.Net.Security

概要

macOSのSecure Transportで、リモート側がclose_notifyを送信した後にSslStreamへの書き込みがDebug.Fail(デバッグビルド)または誤解を招く「Bad address」エラー(リリースビルド)を発生させる問題を修正します。原因はEncryptMessageSSLWriteからのPAL_TlsIo.ClosedGracefullyステータスを処理していなかったためです。

変更内容

  • SslStreamPal.OSX.cs: EncryptMessageメソッドのswitch文にPAL_TlsIo.ClosedGracefullyケースを追加し、SecurityStatusPalErrorCode.ContextExpiredを返すように変更(3行の追加)
  • SslStreamAlertsTest.cs: SslStream_WriteAfterRemoteCloseNotify_ThrowsIOExceptionテストを追加。プラットフォーム検出機能により、macOSではcloseNotify後の書き込みでIOExceptionが投げられることを検証。Linux/Windowsでは実装の違いに対応

パフォーマンスへの影響

影響なし。エラーハンドリングパスの修正であり、正常系のパフォーマンスに変化はありません。

関連Issue

dotnet/runtime#121272

その他

  • DecryptMessageと同じエラーハンドリングパターンを採用することで、暗号化/復号化パスの一貫性を確保
  • テストは非同期操作とタイムアウトを使用し、複数プラットフォームでのCI安定性を確保
  • macOSではSecure Transport、Linux/WindowsではOpenSSL/Schanelの実装差に対応した包括的な検証

#123933 Fix custom Uri parser edge-case when UriKind.Relative is used

  • 作成者: @MihaZupan
  • 作成日時: 2026年02月03日 05:33:55(UTC)
  • マージ日時: 2026年02月10日 16:41:50(UTC)
  • ラベル: area-System.Net

概要

カスタム UriParser を使用する場合、UriKind.Relative が要求されても絶対 Uri が返される可能性があるエッジケースを修正しました。この問題はカスタム パーサーが base.InitializeAndValidate() の検証エラーをクリアした際に発生していました。修正は else if (uriKind == UriKind.Relative)if に変更するだけの単純な制御フロー調整です。

変更内容

  • src/libraries/System.Private.Uri/src/System/UriExt.cs: UriKind.Relative の検証ロジックを、カスタム パーサーがエラーをクリアするパスでも実行されるよう調整(+6/-12)
  • src/libraries/System.Private.Uri/tests/FunctionalTests/UriParserTest.cs: カスタム パーサーが InitializeAndValidate エラーをクリアする場合の動作を検証する新しいテスト追加(+45)
  • src/libraries/System.Private.Uri/tests/FunctionalTests/UriCreationOptionsTest.cs: 未使用の CustomUriParser テスト型を削除(-3)

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • このエッジケースはカスタム UriParser が実際に使用されることは極めて稀であるため、実環境での影響は限定的と考えられます
  • 修正は Uri.InitializeUri メソッドの制御フロー修正のみで、API 変更や破壊的変更はありません
  • カスタム パーサーの検証エラー復旧時の動作に対する機能的カバレッジが追加されました

#123931 Fix removing module from appdomain in DB_IPCE_UNLOAD_MODULE event

  • 作成者: @tommcdon
  • 作成日時: 2026年02月03日 04:52:22(UTC)
  • マージ日時: 2026年02月10日 19:32:10(UTC)
  • ラベル: area-Diagnostics-coreclr

概要

デバッガがモジュールをアンロードする際に、ハッシュテーブルから正しく削除されていなかった問題を修正します。この不具合により、モジュールの再読み込み時にキャッシュが誤って使用され、デバッガの状態管理が不正になっていました。

変更内容

  • src/coreclr/debug/di/module.cpp (+2/-2): モジュールアンロード処理でハッシュテーブルからの削除ロジックを修正
  • src/coreclr/debug/di/process.cpp (+1/-1): DB_IPCE_UNLOAD_MODULE イベント処理に関連する修正

パフォーマンスへの影響

影響なし。本修正は機能的な正確性に関わるものであり、パフォーマンスへの直接的な影響はありません。

関連Issue

#123930

その他

変更が最小限に抑えられており(4行の修正)、デバッガの内部プロセス管理に限定されているため、実行時のユーザー影響は低いと考えられます。ただし、デバッグセッションでモジュールの動的な読み込み・アンロードを繰り返す環境では、この修正によるデバッガの安定性向上が期待できます。


#123806 Fix integer overflow in ArrayList.IListWrapper.BinarySearch and improve test coverage

  • 作成者: @Copilot
  • 作成日時: 2026年01月30日 18:38:35(UTC)
  • マージ日時: 2026年02月10日 16:17:02(UTC)
  • ラベル: area-System.Collections

概要

ArrayList.IListWrapper.BinarySearchの整数オーバーフロー脆弱性を修正しました。midpoint計算をmid = (lo + hi) / 2からmid = lo + ((hi - lo) >> 1)に変更し、大規模配列検索時のオーバーフロー問題を解決します。併せてテストカバレッジを大幅に拡張しました。

// Before (overflows with large arrays)
int mid = (lo + hi) / 2;

// After (overflow-safe)
int mid = lo + ((hi - lo) >> 1);

変更内容

  • System/Collections/ArrayList.cs: midpoint計算ロジックを修正し、mid変数をループ内に移動(3行変更)
  • ArrayListTests.cs: BinarySearch関連テストを大幅拡張(+186行)
    • BinarySearch_LargeList_NoIntegerOverflow: メモリ割り当てなしで大規模リスト検索をシミュレートするテスト
    • BinarySearch_EmptyList, BinarySearch_SingleElement, BinarySearch_TwoElementList: エッジケース検証
    • BinarySearch_BoundaryConditions, BinarySearch_PartialRangeSearch: 境界値・部分範囲検索テスト
    • BinarySearch_ComparerThrowsException: 例外伝播検証
    • BinarySearch_UnsortedList: 非ソート状態での動作確認
    • ヘルパークラス追加: ThrowingComparer(例外テスト用)、FakeLargeIList(メモリ効率的な大規模リストシミュレーション)

パフォーマンスへの影響

影響なし

  • 算術演算の最適化(除算から右シフト演算へ)により、わずかなパフォーマンス向上の可能性あり
  • mid変数のスコープ制限は最適化機会を増加

関連Issue

#123804(整数オーバーフロー脆弱性報告)

その他

  • リポジトリ全体の調査により、他の箇所(Array.cs、ArraySortHelper.cs)では既に安全なパターンを採用していることを確認
  • ExpressionParser.cs、ConcurrentSet.csにも同様の潜在的リスクが存在するが、影響度は低~中程度

#123764 Move Uri tests from System.Runtime to System.Private.Uri and consolidate ExtendedFunctionalTests

  • 作成者: @Copilot
  • 作成日時: 2026年01月29日 18:17:55(UTC)
  • マージ日時: 2026年02月10日 10:36:47(UTC)
  • ラベル: area-System.Net

概要

System.Runtime/testsに分散していたUri関連テストを、System.Private.Uri/tests/FunctionalTestsに統合するテスト構成の整理です。ExtendedFunctionalTestsプロジェクトを削除し、重複するテストを排除しながら、15,221個のテストすべてが確認されています。

変更内容

  • テスト移動: Uri.CreateStringTests.csUri.CreateUriTests.csUri.MethodsTests.csをSystem.Runtime/testsからSystem.Private.Uri/testsへ移動
  • 名前空間更新: System.TestsからSystem.PrivateUri.Testsに変更
  • ExtendedFunctionalTests統合: 6個の廃止予定API テストをFunctionalTests/UriTests.csにマージ
  • 重複削除: UriRelativeResolutionTest.cs(完全な重複)を削除
  • プロジェクトファイル更新: System.Private.Uri.Functional.Tests.csprojへの参照追加、System.Runtime.Tests.csprojおよびSystem.Runtime.Nls.Tests.csprojからUri テスト参照を削除

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • 合計15,221テストが確認済み
  • ExtendedFunctionalTestsプロジェクト自体が廃止される純粋なリファクタリング
  • テスト機能に変更なく、組織化とメンテナンス性の向上が目的

#123702 update EnterpriseTests containers

  • 作成者: @wfurt
  • 作成日時: 2026年01月28日 07:26:27(UTC)
  • マージ日時: 2026年02月10日 10:08:48(UTC)
  • ラベル: area-System.Net test-enhancement

概要

EnterpriseTests用のコンテナイメージをUbuntu 18.04から24.04へアップデートします。Ubuntu 24.04ではlibapache2-mod-auth-kerblibapache2-mod-auth-ntlm-winbindが廃止されたため、Kerberosモジュールをlibapache2-mod-auth-gssapiに置き換え、NTLM Winbindモジュールはソースからビルドして対応します。また、FTP TLS対応をProftpdの設定で追加します。

変更内容

  • Dockerfile (apacheweb): Ubuntu 24.04へアップデート、libapache2-mod-auth-gsapiの導入、mod_auth_ntlm_winbindのソースビルド対応を追加
  • apache2.conf: Kerberosモジュール設定をlibapache2-mod-auth-gsapiに更新
  • mod_auth_ntlm_winbind/: レガシーNTLMWinbind認証モジュールのソースコード(1084行)とサードパーティーライセンス、READMEを追加
  • proftpd.conf: FTP TLS設定を新規追加(46行)
  • run.sh: Proftpd起動スクリプトを追加
  • kdc/Dockerfile、linuxclient/Dockerfile: Ubuntu 24.04へアップデート

パフォーマンスへの影響

影響なし

関連Issue

https://github.com/dotnet/runtime/issues/123135 (FTP TLS対応の準備)

その他

  • libapache2-mod-auth-ntlm-winbindはパッケージが廃止されているため、ソースコードからのビルドにより継続的なレガシー使用ケースのテストをサポートします
  • このアップデートはシステムライブラリの廃止に対応したメンテナンス性向上を目的としています

#123594 fix Vector2/3 EqualsAny

  • 作成者: @kasperk81
  • 作成日時: 2026年01月25日 14:15:54(UTC)
  • マージ日時: 2026年02月10日 14:17:20(UTC)
  • ラベル: area-System.Numerics community-contribution

概要

Vector2/Vector3のEqualsAnyメソッドの不具合を修正するPull Requestです。Issue #123586で報告された問題を解決し、これらのメソッドが正しく動作するようになります。テストケースも追加されており、Vector2で84行、Vector3で91行の新しいテストが含まれています。

変更内容

  • System.Numerics.Vector2.cs: EqualsAnyメソッドの実装を修正(10行追加、10行削除)
  • System.Numerics.Vector3.cs: EqualsAnyメソッドの実装を修正(10行追加、10行削除)
  • Vector2Tests.cs: EqualsAnyメソッドのテストケースを追加(84行)
  • Vector3Tests.cs: EqualsAnyメソッドのテストケースを追加(91行)

パフォーマンスへの影響

影響なし。このPull Requestは既存の不具合を修正するもので、パフォーマンスへの影響は予想されません。

関連Issue

  • #123586 - Vector2/Vector3のEqualsAnyメソッドに関する問題

その他

なし


#123328 Fix authenticated proxy for dotnet restore

  • 作成者: @ptarjan
  • 作成日時: 2026年01月18日 17:03:40(UTC)
  • マージ日時: 2026年02月10日 16:52:51(UTC)
  • ラベル: area-System.Net.Http community-contribution

概要

プロキシ認証が必要な場合、407レスポンスを待たずに初回リクエストでProxy-Authorizationヘッダを先制的に送信するように修正しました。特に認証なしの接続を拒否するプロキシやHTTPS CONNECTトンネル、環境変数で指定された認証情報付きプロキシに対応します。

// SendWithProxyAuthAsync が ICredentials から認証情報を取得して
// 先制的に Basic 認証を送信するようになりました
var handler = new SocketsHttpHandler 
{ 
    Proxy = new WebProxy("http://proxy:port"),
    Credentials = new NetworkCredential("user", "password")
};

変更内容

  • AuthenticationHelper.cs: SendWithProxyAuthAsyncメソッドを修正し、ICredentialsプロバイダーから利用可能な認証情報がある場合、407レスポンスを待たずにBasic認証を先制的に送信
  • GlobalHttpSettings.cs: 関連する設定追加(7行追加)
  • HttpClientHandlerTest.ProactiveProxyAuth.cs: 先制的プロキシ認証の動作を検証する新規テストスイート(407行)

パフォーマンスへの影響

改善点: 407レスポンスを待つ必要がなくなるため、プロキシ認証が必要な環境ではネットワークラウンドトリップが1回削減され、レイテンシが向上します。

互換性: 反応的認証フロー(407チャレンジに応答)は保持されるため、Digest/NTLM/Negotiateなど異なる認証スキームを要求するプロキシでも動作します。

関連Issue

#123363

その他

  • Reactive(反応的)な認証フローは維持されており、既存の407ベースの認証メカニズムとの後方互換性が確保されています
  • 環境変数プロキシ(HTTP_PROXY/HTTPS_PROXY)に埋め込まれた認証情報の処理が改善されます

#122748 Bump actions/upload-artifact from 5 to 6

  • 作成者: @dependabot[bot]
  • 作成日時: 2025年12月26日 21:10:05(UTC)
  • マージ日時: 2026年02月10日 19:03:11(UTC)
  • ラベル: area-codeflow

概要

GitHub Actions の actions/upload-artifact を v5 から v6 へアップグレードしました。v6 は Node.js 24 をデフォルトランタイムとしており、Actions Runner の最小バージョン要件が 2.327.1 以上になります。セルフホストランナーを使用している場合は、アップグレード前に更新が必要です。

変更内容

  • .github/workflows/aspnetcore-sync.yml: actions/upload-artifact を v5 から v6 へ更新(+1/-1)
  • .github/workflows/breaking-change-doc.yml: actions/upload-artifact を v5 から v6 へ更新(+1/-1)
  • .github/workflows/jit-format.yml: actions/upload-artifact を v5 から v6 へ更新(+1/-1)

計3つのワークフローファイルで actions/upload-artifact のバージョン指定が更新されています。

パフォーマンスへの影響

影響なし。本変更は CI/CD ワークフロー内で使用される GitHub Action のバージョンアップであり、.NET ランタイムのパフォーマンスには直接的な影響を与えません。

関連Issue

なし

その他

重要な注意点

  • actions/upload-artifact@v6 は Node.js 24 で実行されるため、Actions Runner のバージョン要件が 2.327.1 以上に引き上げられています
  • セルフホストランナーを使用している場合、このアップグレードを適用する前に必ずランナーを更新してください
  • v5 では Node.js 24 のプレリリアム対応でしたが、v6 ではデフォルトでの実行環境が Node.js 24 に変更されています
  • @actions/artifact 依存関係が v5.0.1 に更新され、Node.js 24 の punycode 非推奨化に対応しています

#122216 [automated] Merge branch 'release/8.0' => 'release/8.0-staging'

  • 作成者: @github-actions[bot]
  • 作成日時: 2025年12月05日 09:02:35(UTC)
  • マージ日時: 2026年02月10日 16:23:18(UTC)
  • ラベル: area-Infrastructure

概要

release/8.0ブランチからrelease/8.0-stagingブランチへの自動マージPRです。GitHub Actionsによって自動生成され、複数のコミッター(github-actions[bot]、mmitche、dotnet-maestro[bot])による変更を同期します。主にバージョン情報、ビルド設定、NuGetパッケージ構成の更新が含まれています。

変更内容

  • Directory.Build.targets: ビルド構成のバージョン管理情報を更新
  • NuGet.config: NuGetフィード設定を追加
  • eng/Version.Details.xml: 依存パッケージバージョン情報を更新
  • eng/Versions.props: ビルドバージョンプロパティを更新
  • eng/packaging.targets: パッケージング構成を更新
  • CoreLib関連: System.Private.CoreLibプロジェクト設定(CoreCLR、Mono、NativeAoT)を更新
  • SafeFileHandle.Unix.cs: Unixプラットフォーム向けのセーフハンドル実装を更新(4行追加、1行削除)

パフォーマンスへの影響

影響なし(リリースブランチ間の構成・バージョン同期のみ)

関連Issue

なし

その他

  • このPRは自動マージされません。チェック完了後、スクイャッシュやリベースではなくマージコミットで統合してください
  • マージ競合が発生した場合は、手動で解決が必要です
  • コミットラインのリセットに失敗した場合やPRが正しく生成されなかった場合は、dotnet/dncengに連絡してください

目次