.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 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
18/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
csharp, linux
领域
operating-systems

调研方向

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 小时
30 天内合并 PR
585

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

dotnet/runtime 的其他 Issue

查看 dotnet/runtime 的全部 Issue

相似的 Issue

更多 C# Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。