运行blastn v2.12.0多线程模式时抛出std::length_error异常求助

terminate called after throwing an instance of 'std::length_error' what(): basic_string::_M_create

根因定位 #

• 触发报错的核心原因是系统依赖库版本不兼容：RHEL7/CentOS7默认搭载的GLIBC版本仅为2.17，而NCBI官方预编译的BLAST v2.12.0版本最低要求GLIBC 2.23及以上版本，低版本GLIBC的字符串内存分配接口在高并发场景下会触发底层异常。
• Ubuntu 18.04默认搭载GLIBC 2.27，完全满足BLAST v2.12.0的运行要求，因此本地运行不会触发报错。
• -mt_mode 1按查询拆分的多线程模式会并发处理大量输入序列字符串，进一步放大了低版本GLIBC的接口缺陷，所以仅在该参数搭配高线程数时会触发报错。

可行修复方案 #

方案1：使用适配低版本系统的BLAST版本 #

直接替换为BLAST v2.11.0及更低的官方预编译版本，该版本编译时适配了RHEL7/CentOS7的GLIBC版本，原有运行参数不需要修改即可正常运行。

方案2：通过conda安装适配环境的BLAST #

使用bioconda通道安装BLAST，conda会自动匹配当前系统的依赖库版本，不会出现兼容性问题，安装命令如下：
conda install -c bioconda blast==2.12.0
安装完成后激活对应conda环境，再运行原有blastn命令即可。

方案3：调整运行参数临时规避 #

如果暂时无法替换BLAST版本，可以通过修改参数规避高并发场景的触发条件：

• 将-num_thread参数降低到16及以下，减少并发处理的压力
• 把-mt_mode参数从1改为0（按数据库拆分模式），该模式下不会触发高频的查询序列字符串并发分配操作，大部分场景下可正常运行

验证建议 #

优先用小样本测试调整后的方案，确认不会抛出异常后再提交全量任务，避免浪费超算计算资源。

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