出现重复栈溢出输出致dotnet崩溃，是代码问题还是.NET的bug？

核心结论 #

这类场景下的崩溃几乎都来自自身代码逻辑缺陷，不属于.NET运行时本身的bug。经完整复现排查，本次遇到的问题根因为代码中存在没有有效终止条件的递归调用。

异常表现的对应逻辑 #

所有观察到的异常特征都和递归触发的栈溢出机制完全匹配，不存在指向运行时缺陷的证据：

• 编译全流程正常完成：递归类的逻辑错误不存在语法、类型不匹配问题，编译器不会对这类运行时层面的逻辑错误抛出编译报错或警告，可正常完成构建输出可执行文件
• 进程直接在CLR层面崩溃：StackOverflowException是.NET运行时的内置保护机制，当调用栈深度超出系统预设阈值时主动触发的不可捕获异常，会直接终止进程运行，属于设计内的保护逻辑，并非运行时故障
• 调试时弹出The runtime refused to evaluate the expression at this time：这是调试器的内置防护策略，当检测到目标进程调用栈已经溢出、继续执行表达式求值会耗尽调试器自身的调用栈时，会主动拒绝求值操作，避免调试器连带崩溃
• 控制台输出折叠的重复堆栈：当递归达到数万层深度时，运行时为了避免输出冗余信息，会自动折叠完全重复的连续调用栈帧，用重复次数标注替代逐行打印全量堆栈，这就是看到Repeat 24047 times这类提示的原因

快速排查方向 #

遇到同类问题时，可以按照以下路径快速定位缺陷：

• 从控制台输出的折叠堆栈段入手，找到循环重复的调用链——无终止条件的递归本质就是固定的方法序列无限循环，比如方法A调用方法B、方法B反过来调用方法A，或是单个方法在分支逻辑遗漏下出现无出口的自调用
• 重点排查新增代码中容易出现循环调用的位置：
  • 自定义类型的相等判断、隐式转换运算符逻辑中存在互调
  • 属性的get/set访问器内部错误触发了自身属性的读写
  • 事件订阅回调中没有防护机制，重复触发自身关联的事件

内容的提问来源于stack exchange，提问作者hardfork