Ubuntu 18环境下.NET Core nopcommerce应用随机崩溃 日志报栈溢出

从syslog日志可以明确，进程崩溃的直接触发原因是栈溢出（Stack overflow）：.NET Core运行时检测到当前线程栈空间被耗尽后，主动抛出SIGABRT信号终止进程，对应日志中Main process exited, code=killed, status=6/ABRT的记录，并非系统内存耗尽、网络异常或systemd配置错误导致的崩溃。这类问题之所以表现为运行一段时间后随机、无规律的崩溃，是因为触发递归的条件并非每次请求都会命中，往往需要特定参数、特定资源状态、特定并发场景才会触发无限循环，因此多数时段服务运行正常。

• 无限递归的业务逻辑：nopCommerce部署的自定义插件、主题、业务扩展代码中存在无终止条件的递归调用，比如Razor视图递归渲染、商品/分类导航属性循环引用、第三方插件的资源查找逻辑缺失出口
• 递归跳转逻辑错误：SEO重定向、权限认证模块的跳转逻辑未设置终止条件，比如权限校验未通过时反复跳转回同一认证路由，形成请求处理链路的无限嵌套，与日志中崩溃前返回302重定向的场景高度匹配
• 序列化过程的循环引用：实体类双向导航属性未配置循环引用忽略规则，JSON序列化时无限遍历对象图，快速耗尽单线程栈空间
• 自定义中间件逻辑错误：认证、限流、缓存等自定义管道组件未正确传递请求委托，或错误在中间件内重复触发当前站点路由，形成管道级别的无限递归
• 老旧.NET Core运行时的已知bug：Ubuntu 18环境下部署的非LTS、未打补丁的.NET Core 2.x/3.x版本，存在高并发下线程栈分配异常、GC触发非预期递归的已知问题
• 服务资源限制配置过严：systemd服务单元文件中对进程设置了过低的栈大小限制（如LimitSTACK配置远低于默认8MB阈值），常规深度的方法调用就会触发栈溢出
• nopCommerce旧版本的固有缺陷：4.20及更早版本存在多语言资源查找的递归逻辑bug，在特定语言资源缺失场景下会无限制递归直到栈耗尽

• 抓取崩溃现场定位递归源头
  • 为nopCommerce进程配置崩溃自动生成转储文件，在systemd服务的环境变量配置中增加三项配置：DOTNET_DbgEnableMiniDump=1（启用崩溃转储）、DOTNET_DbgMiniDumpType=4（生成包含完整栈的转储文件）、DOTNET_DbgMiniDumpPath=/var/log/nopcommerce/dumps（指定转储文件存储路径）
  • 下次崩溃生成转储文件后，使用dotnet-dump工具解析栈信息，栈溢出场景下递归帧会重复出现同一方法名，可直接定位到触发无限循环的具体代码位置
• 基础环境校验
  • 执行dotnet --list-runtimes确认当前运行的.NET Core版本，将运行时升级到对应大版本的最新LTS补丁版本，规避已知的栈溢出bug
  • 检查对应systemd服务文件的资源限制配置，将栈大小限制恢复为系统默认值（8MB），取消过度严格的LimitSTACK配置
• 业务逻辑排查
  • 拉取崩溃前最后一条处理的请求路由日志，重点校验该路由对应的控制器、插件、视图、重定向逻辑，排查无终止条件的递归调用
  • 检查实体类的JSON序列化配置，为双向导航属性增加循环引用忽略规则，避免对象图递归遍历
  • 排查最近新增的自定义中间件逻辑，确认管道委托的调用链路无递归嵌套
• 版本迭代校验
  • 若使用的是4.50及更早版本的nopCommerce，优先升级到最新的LTS版本，修复多语言资源查找、Razor模板渲染、商品层级加载模块已知的递归逻辑缺陷

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