[mono][wasm][AOT] CollectionsMarshal dictionary value-ref write is lost across GC

オープン
  • 何か問題がありますか？
#136,544 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
12/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
csharp, wasm
領域
compilers

調査の方向性

Start by extracting the attached reproducer and running the provided publish/Node loop; the failing evidence is the ref-gc rows in __PROBE__, where sum and readback diverge while the indexer and no-GC controls pass. Read Program.cs alongside Repro.csproj and main.mjs to confirm the forced collection and value-ref lifetime, then use the linked runtime issues as context. Done means every ref-gc row reports readback=9757946880 across fresh processes on both .NET 10 and .NET 11 RC3.

索引モデルが issue の本文から書いたものです。

説明

area-System.Collections untriaged
Description

In Node-hosted Mono browser-WASM AOT, a write through a dictionary value reference returned by CollectionsMarshal.GetValueRefOrNullRef can be silently lost if a GC occurs while the reference is live.

The addition produces the expected BigInteger, but a subsequent dictionary lookup returns the original value. The key remains present, with no insertion, removal, resize, or concurrent access while the reference is live.

  • .NET 11 RC3: all forced-GC byref writes failed.
  • .NET 10: the first forced-GC byref write in each fresh process failed; later calls in that process passed.
  • Controls using the indexer across GC or the byref without GC passed on both versions.
Reproduction Steps

Reproducer package: mono-wasm-byref-gc-repro.zip

It contains .NET 10 and .NET 11 RC3 projects with identical C# source, pinned SDKs, a Node launcher, and instructions.

Relevant declarations copied from the attached Program.cs:

private sealed record Sample(string Mode, string Before, string Increment, string Sum, string Readback, int Collections);

[MethodImpl(MethodImplOptions.NoInlining)]
private static Sample RefProbe(Dictionary<int, BigInteger> map, bool collect) {
    BigInteger increment = new(2987424000L);
    ref BigInteger slot = ref GetSlot(map);
    BigInteger previous = slot;
    BigInteger sum = previous + increment;
    int before = GC.CollectionCount(GC.MaxGeneration);
    if (collect) {
        GC.Collect(GC.MaxGeneration, GCCollectionMode.Forced, true, true);
    }
    slot = sum;
    BigInteger readback = map[7];
    GC.KeepAlive(map);
    return new(collect ? "ref-gc" : "ref-no-gc", previous.ToString(), increment.ToString(), sum.ToString(), readback.ToString(), GC.CollectionCount(GC.MaxGeneration) - before);
}

[MethodImpl(MethodImplOptions.NoInlining)]
private static ref BigInteger GetSlot(Dictionary<int, BigInteger> map) => ref CollectionsMarshal.GetValueRefOrNullRef(map, 7);

Each dictionary starts with [7] = 6770522880. The full reproducer uses non-inlined creation and probe methods, creates the dictionary before await Task.Yield(), obtains the reference after resuming, and uses a separate dictionary for every trial and control.

Requirements: SDKs 10.0.402 and 11.0.100-rc.3.26522.148, each SDK's wasm-tools workload, and Node 24.22.1.

From the extracted archive root, in a POSIX-compatible shell:

for framework in net10 net11; do
  (
    cd "$framework" || exit 1
    dotnet workload install wasm-tools --skip-manifest-update &&
    dotnet publish Repro.csproj -c Release -o publish &&
    cp ../main.mjs publish/wwwroot/main.mjs
  ) || exit 1
done

for process in 1 2 3 4 5; do
  node net10/publish/wwwroot/main.mjs
  node net11/publish/wwwroot/main.mjs
done

Each process prints three trials of:

  • ref-gc: write through the value ref after forced GC.
  • indexer-gc: write through map[7] after forced GC.
  • ref-no-gc: write through the value ref without forced GC.

The process exits with code 0 even when a write is lost; inspect the __PROBE__ rows.

Expected behavior

Every row should report:

previous=6770522880
increment=2987424000
sum=9757946880
readback=9757946880
Actual behavior

Failing ref-gc rows report sum=9757946880 but readback=6770522880. Every forced-GC row recorded one maximum-generation collection; every no-GC row recorded zero.

The same results were reproduced independently on Windows and Ubuntu. The counts below are per operating system, using five fresh processes per framework and three trials per process:

Observation .NET 10 .NET 11 RC3
First ref-gc call lost write 5/5 5/5
Later same-process ref-gc calls lost write 0/10 10/10
indexer-gc controls lost write 0/15 0/15
ref-no-gc controls lost write 0/15 0/15

All processes completed all nine probe rows and printed __DONE__.

Regression?

No response

Known Workarounds

Copy the previous dictionary value with TryGetValue, compute the sum, then write using the dictionary indexer instead of retaining the value byref across GC. The indexer-with-GC control passed in the reported .NET 10 and .NET 11 runs.

Configuration

Hosts:

  • Windows x64, build 10.0.26200
  • Ubuntu 24.04.3 x64, Linux 6.18.55
  • Node 24.22.1
Component .NET 10 .NET 11 RC3
SDK 10.0.402 11.0.100-rc.3.26522.148
Mono browser-WASM runtime/AOT packs 10.0.13 11.0.0-rc.3.26522.148
Emscripten compiler 3.1.56 6.0.3

Both projects use Microsoft.NET.Sdk.WebAssembly, RunAOTCompilation=true, RuntimeIdentifier=browser-wasm, and the default WasmStripILAfterAOT=true.

Other information

Potentially related: dotnet/runtime#132306, dotnet/runtime#136489, and dotnet/runtime#130592.

主要言語
C#
スター
18.4k
フォーク
5.8k
平均マージ
2日 15時間
マージ済み PR（30日）
596

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

dotnet/runtime のほかの issue

dotnet/runtime の issue をすべて見る

似ている issue

C# の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。