Ubuntu虚拟机中Stack安装text包三次才成功的问题排查

这种时好时坏的编译失败确实挺让人挠头的，结合你提供的环境细节和现象，我来拆解一下背后可能的原因：

现象回顾 #

先梳理下你遇到的核心情况：

• 首次执行 stack install text 触发段错误，当时Ubuntu虚拟机剩余内存仅约75MB
• 第二次编译到第28个模块时，出现GHC内部内存申请失败的错误
• 第三次尝试却顺利完成安装
• 环境配置：Vagrant管理的Ubuntu虚拟机、Stack 1.6.3、使用lts-10.3 resolver（对应GHC 8.2.2）
• 后续验证：stack ghci调用text包、安装依赖text的megaparsec均正常

原因分析 #

1. 临界内存资源的波动影响

你的虚拟机剩余内存只有75MB，属于极端紧张的内存环境。GHC编译Haskell代码（尤其是text这种基础核心库）时，内存占用会有明显的阶段性波动——处理某些复杂模块的语法分析、优化阶段，会突然需要大量内存。

• 第一次的段错误，很大概率是内存耗尽后触发了系统的OOM（内存不足）杀手，或者导致GHC自身内存访问越界
• 第二次在第28个模块失败，是因为该模块编译时的内存峰值刚好超过了当时的剩余可用内存阈值
• 第三次成功，可能是前两次编译过程中，Stack或系统已经缓存了部分中间编译产物，减少了本次编译的内存峰值需求，刚好卡在了可用内存的临界值内

2. 旧版GHC的内存管理bug（关联Ticket 4012）

你提到的GHC Ticket 4012涉及的正是内存分配相关的非确定性问题。在GHC 8.2.2这类旧版本中，内存分配器在资源紧张的场景下，存在竞态条件或分配策略不稳定的情况——有时候能侥幸完成内存申请，有时候就会触发失败。这类bug只会在资源临界时暴露，刚好对应你遇到的“有时失败有时成功”的非确定性现象。

3. Stack缓存机制的间接作用

Stack在编译流程中会自动缓存已编译的模块和依赖产物。前两次失败的编译其实已经生成了部分模块的缓存，第三次编译时不需要重新处理这些模块，整体内存消耗大幅降低，这也让编译得以顺利完成。这也解释了为什么后续安装megaparsec时没有问题——此时text已经被成功编译并缓存，不需要再重复消耗内存编译它。

后续建议 #

如果后续还遇到类似问题，可以尝试：

• 给虚拟机分配更多内存（建议至少1GB以上，Haskell编译对内存需求并不低）
• 升级到更新的Stack resolver版本（比如lts-14及以上，对应GHC 8.6+，这类内存管理的旧bug已经被大量修复）

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