c# 如何在Linux上用lldb和dotnet-dump调试c#并发问题

dotnet-dump 无法直接捕获线程阻塞或竞争状态，仅能获取内存快照，不记录执行轨迹、锁持有链或调度历史；需配合 lldb、dotnet-trace、日志与符号调试综合分析。

dotnet-dump 无法直接捕获线程阻塞或竞争状态

dotnet-dump 只能抓取进程某一时刻的内存快照（core dump），它不记录执行轨迹，也不保存锁持有链、线程调度历史或内存访问顺序。所以当你遇到 Task 卡住、Monitor.Enter 死锁、或 ConcurrentDictionary 某些 key 查不到却没报错这类问题时，仅靠 dotnet-dump analyze 很难定位——它能看到线程在哪个方法挂起，但看不到“为什么等”、“谁在持锁”、“是否自旋超时后放弃”。

实操建议：

• 先用 dotnet-dump ps 确认目标 dotnet 进程 PID，再用 dotnet-dump collect -p 抓取 dump；注意：必须确保该进程启用了 COMPlus_DbgEnableMiniDump=1 环境变量，否则 dump 缺少托管堆符号信息
• dump 分析阶段，重点运行 clrstack -all 和 dumpheap -stat，看是否有大量 Thread 或 Task 实例未完成，以及哪些线程卡在 WaitHandle.WaitOne、Monitor.ObjWait 或 SpinWait.SpinOnce
• 若发现多个线程停在 Monitor.Enter 同一个对象地址，用 dumpobj 查该对象的 SyncBlockIndex，再用 eeheap -syncblk 找出当前持有该 sync block 的线程 ID

lldb 是唯一能实时观测托管线程调度和原生调用栈的工具

Linux 上没有 WinDbg，而 lldb 是 dotnet runtime 官方支持的调试器（通过 libsosplugin.so 插件）。它能 attach 到运行中的 dotnet 进程，设置断点、单步执行、查看寄存器，并在托管代码断点命中时自动切换到 C# 源码上下文（需有 PDB + 调试符号路径正确）。

实操建议：

• 启动前导出符号路径：export DOTNET_SYMBOLS=1，并确保 /tmp/dotnet-symbols 可写（或设 DOTNET_SYMBOLS_CACHE=/path）
• 用 lldb --core 加载 dump 时，必须手动加载插件：plugin load /usr/share/dotnet/shared/Microsoft.NETCore.App/*/libsosplugin.so（路径依 .NET 版本而异）
• 调试运行中进程更实用：先 lldb -p ，再 plugin load ...，然后 bpmd YourAssembly.dll YourNamespace.YourClass.YourMethod 下托管断点；若断点不生效，检查是否用了 AOT 编译或 Tiered Compilation 导致方法未 JIT
• 并发关键操作（如 Interlocked.CompareExchange、SpinLock.Enter）附近可下原生断点：b coreclr!JIT_CheckedWriteBarrier 或 b libpthread.so.0!pthread_mutex_lock，观察锁争用路径

并发问题必须结合日志 + 时间戳 + 线程 ID 交叉验证

单纯靠 dump 或 lldb 快照，容易误判“假死”：比如某个 Task.Delay(60000) 就是合法等待，不是 bug；而 Parallel.ForEach 中某次迭代耗时突增，可能只是 I/O 偶发延迟。没有上下文时间线，所有线程状态都是静态幻觉。

实操建议：

• 在关键同步块前后打日志，用 DateTime.UtcNow.Ticks 和 Thread.CurrentThread.ManagedThreadId 标记，例如：log($"[T{tid}] Enter lock @ {ticks}")
• 避免用 Console.WriteLine（会锁 stdout，干扰并发行为），改用 System.IO.File.AppendAllText 或 Microsoft.Extensions.Logging 的 async logger
• 若使用 dotnet-trace，启用 Microsoft-DotNetRuntime:1:4:0x80000000 事件提供程序，它会记录 ThreadPoolWorkerThreadStart、ThreadStart、ContentionStart 等底层事件，配合 traceconv 转成 CSV 后用 Pandas 分析锁等待热区

常见陷阱：.NET 版本、符号、权限三重不匹配

在 Linux 上调试 .NET 并发问题，80% 的失败不是逻辑问题，而是环境没对齐：你用 .NET 7 SDK 编译的程序，却用 .NET 6 的 libsosplugin.so 加载 dump；或者 dotnet-dump 是全局安装的，而应用跑在容器里，符号路径根本不可见；又或者非 root 用户 attach lldb，被 ptrace_scope 拦截。

实操建议：

• 统一版本：用 dotnet --list-runtimes 和 dotnet-dump --version 确保一致；容器内调试优先用 mcr.microsoft.com/dotnet/sdk:7.0 镜像，自带匹配的调试工具链
• 符号路径必须显式指定：dotnet-dump analyze mydump.coredump --symbols /path/to/pdb/；PDB 文件名必须与 DLL 名完全一致（含大小写），且不能压缩
• 绕过 ptrace 限制：echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope（临时），或容器启动加 --cap-add=SYS_PTRACE

sudo docker run --cap-add=SYS_PTRACE -v $(pwd):/app -w /app mcr.microsoft.com/dotnet/sdk:7.0 \
  dotnet-dump collect -p $(pidof dotnet) --symbols ./bin/Debug/net7.0/

真正棘手的并发问题，往往藏在 JIT 编译后的指令重排、CPU cache line false sharing、或 GC suspension 导致的暂停毛刺里——这些已超出 dotnet-dump 和 lldb 的常规能力边界，需要 perf + eBPF + clrstack 多维印证。别指望一次命令就定位，留好 trace 和 dump 的时间戳，它们是你回溯的唯一锚点。