.NET 10.0.14 regression on Linux ARM64: named System.Threading.Mutex fails for non-root user, works on 10.0.12

オープン
#136,920 コメント 7 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
18/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
csharp, linux

調査の方向性

The failure is in System.Threading.Mutex.CreateMutexCore when a named mutex is created by a non-root user on Linux ARM64, and it only reproduces when System.Private.CoreLib.dll and libcoreclr.so are both from 10.0.14. Start by building the four-line repro from the issue against 10.0.12 and 10.0.14 as a non-root user, then trace which native call returns the error. Done means the named mutex is created for an unprivileged user on 10.0.14 and the change passes the existing named-mutex tests.

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

説明

area-System.Threading untriaged
Description

After upgrading a self-contained Linux ARM64 application from .NET 10.0.12 to .NET 10.0.14, creation of a named System.Threading.Mutex fails with an IOException.

The same code:

  • works on .NET 10.0.12
  • fails on .NET 10.0.14
  • works as root
  • fails as an unprivileged user
  • works for unnamed mutexes
  • fails only for named mutexes

This appears to be a runtime regression in the interaction between System.Private.CoreLib.dll and libcoreclr.so. Through binary replacement tests, I isolated the failure to the 10.0.14 versions of those runtime components.

Reproduction Steps

Compile the following with .NET 10.0.12 and 10.0.14:

using System;
using System.Threading;

Console.WriteLine("Unnamed mutex");

using (var m = new Mutex())
{
    Console.WriteLine("Unnamed OK");
}

Console.WriteLine("Named mutex");

using (var m = new Mutex(false, "NamedMutexTest"))
{
    Console.WriteLine("Named OK");
}
Expected behavior

.NET 10.0.12:
Unnamed mutex
Unnamed OK
Named mutex
Named OK

Actual behavior

.NET 10.0.14:
Unnamed mutex
Unnamed OK
Named mutex
Unhandled exception. System.IO.IOException: The system cannot open the device or file specified. : 'NamedMutexTest'.
at System.Threading.Mutex.CreateMutexCore(Boolean initiallyOwned, String name, NamedWaitHandleOptionsInternal options, Boolean& createdNew)
at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name)
at Program.

$(String[] args) in C:\Users\ChrFin00\source\MutexRepro\Program.cs:line 10

Regression?

Yes, works with 10.0.12

Known Workarounds

No response

Configuration

OS: Embedded Linux
Kernel: Linux 6.6.52
Architecture: aarch64 (ARM64)

User:
root -> works
mgnt -> fails

Deployment:
Self-contained
linux-arm64

Runtime:
.NET 10.0.12 -> works
.NET 10.0.14 -> fails

Other information

Additional Investigation

/dev/shm
Exists and is writable by the failing user:

su mgnt -s /bin/ash -c 'touch /dev/shm/test-mgnt'

Result:

-rw-r--r-- 1 mgnt system 0 ...

Filesystem:

tmpfs on /dev/shm
size=64K
38% used

User Permission Tests

The same executable:

root -> works
mgnt -> fails

However:

touch /dev/shm/test-mgnt
works for mgnt, so the user has write access to /dev/shm.

Runtime Isolation
Two self-contained deployments were compared:

Working

{
"name": "Microsoft.NETCore.App",
"version": "10.0.12"
}

Failing

{
"name": "Microsoft.NETCore.App",
"version": "10.0.14"
}

Using the failing application binaries together with the 10.0.12 runtime files works correctly.

Further binary replacement testing showed:

Runtime File Replaced
Resultlibcoreclr.so only -> works
System.Private.CoreLib.dll only -> works
both together (10.0.14 versions) -> fails

This suggests the problematic code path requires both the 10.0.14 managed and native runtime components.

主要言語
C#
スター
18.4k
フォーク
5.8k
平均マージ
2日 14時間
マージ済み PR(30日)
585

環境構築

Codespaces で開く

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

はじめの一歩

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

dotnet/runtime のほかの issue

dotnet/runtime の issue をすべて見る

似ている issue

C# の issue をもっと見る

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

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