1

我正在使用 Nextflow.io 安排数千个分析作业，然后加入输出。

Nextflow 是一个 DSL，它允许我指定渠道和流程并安排和运行它们。在后台，它为每个进程创建 bash 脚本，这就是我在此处发布而不是https://github.com/nextflow-io/nextflow的原因。

我可以提供脚本的完整版本，但这是精简版：

#!/bin/bash

nxf_stage() {
    true
    #THIS IS WHERE IT BREAKS
    ...
}    

nxf_main() {
    trap on_exit EXIT
    trap on_term TERM INT USR1 USR2
    # some more prep here
    nxf_stage
    ...
    wait $pid || nxf_main_ret=$?
    ...
    nxf_unstage
}

$NXF_ENTRY

nxf_stage 函数的目的是准备该进程需要的文件。代替上面我所说的中断的评论大约有 76,000 行，如下所示：

rm -f result_job_073241-D_RGB_3D_3D_side_far_0_2019-03-12_03-25-01.json

后跟相同数量的行，如下所示：

ln -s /home/ubuntu/plantcv-pipeline/work/8d/ffe3d29ee581c09d3d25706c238d1d/result_job_073241-D_RGB_3D_3D_side_far_0_2019-03-12_03-25-01.json result_job_073241-D_RGB_3D_3D_side_far_0_2019-03-12_03-25-01.json

当我尝试执行 nextflow 脚本时，我收到此错误：

Segmentation fault (core dumped)

我能够将它调试到该函数，只需使用任何一方的 echo 语句，但该函数中的任何内容对我来说似乎都不复杂。实际上，当我剥离其他所有内容并将脚本保留为约 152,000 行rm命令ln时，它就可以正常工作。

这种大小的函数是否有可能导致段错误的内存占用？似乎每个命令本身都很小。

更新：

输出bash -x：

+ set -x
+ set -e
+ set -u
+ NXF_DEBUG=0
+ [[ 0 > 1 ]]
+ NXF_ENTRY=nxf_main
+ nxf_main
+ trap on_exit EXIT
+ trap on_term TERM INT USR1 USR2
++ dd bs=18 count=1 if=/dev/urandom
++ base64
++ tr +/ 0A
+ export NXF_BOXID=nxf-1qYK72XftztQW4ocxx3Fs1tC
+ NXF_BOXID=nxf-1qYK72XftztQW4ocxx3Fs1tC
+ NXF_SCRATCH=
+ [[ 0 > 0 ]]
+ touch /home/ubuntu/plantcv-pipeline/work/ec/da7ca4e909b2cc4a74ed8963cc5feb/.command.begin
+ set +u
+ set -u
+ [[ -n '' ]]
+ nxf_stage
Segmentation fault (core dumped)
4

1 回答 1

2

我在这里找到了解决方案：https ://stackoverflow.com/a/14471782/5447556

本质上，该函数被分配在堆栈上并且达到了软堆栈空间限制。

跑步ulimit -sS unlimited让我增加了这个限制。

添加beforeScript: 'ulimit -sS unlimited'到我的 nextflow 流程是一个成功的解决方法。值得注意的是，这在极端情况下不起作用，而且相当笨重。我认为真正的解决方案是让 nextflow 为大型输入通道实施更强大的分段过程。

于 2019-11-25T01:38:47.307 回答