node.js - 来自 AWS Lambda 函数中的 spawn child_process 的 SIGSEGV

Question

我正在尝试在 AWS Lambda 函数中生成一个同步子进程(以运行 ffprobe)，但它几乎立即(200 毫秒)因信号 SIGSEGV 而死。

我对段错误的理解是，它是一个试图访问不允许访问的内存的进程。我尝试将内存增加到 1024MB(我使用 128MB，因为每次执行只使用大约 56MB)，但这并没有改变任何东西。

我知道我不是唯一遇到此问题的人:https://forums.aws.amazon.com/thread.jspa?threadID=229397

有人知道如何解决这个问题吗？

2016 年 4 月 25 日更新

为了清楚起见，我正在运行的代码是:

import { spawnSync } from 'child_process';

exports.handler = (event, context) => {
  process.env.PATH = `${process.env.PATH}:${process.env.LAMBDA_TASK_ROOT}`;
  const ffprobe = './ffprobe';

  const bucket = event.Records[0].s3.bucket.name;
  const key = event.Records[0].s3.object.key;
  console.log(`bucket: ${bucket}`);
  console.log(`key: ${key}`);

  const url = 'http://my-clip-url.com'; // An s3 presigned url.
    if (!url) {
      throw new Error('Clip does not exist.');
    }

    const command = `-show_format -show_streams -print_format json ${url}`;

    try {
      const child = spawnSync(ffprobe, command.split(' '));
      console.log(`stdout: ${child.stdout.toString()}`)
      console.log(`stderr: ${child.stderr.toString()}`)
      console.log(`status: ${child.status.toString()}`)
      console.log(`signal: ${child.signal.toString()}`)
    } catch (exception) {
      console.log(`Process crashed! Error: ${exception}`);
    }
};

其输出为:

START RequestId: 6d72847 Version: $LATEST

2016-04-25T19:32:26.154Z    6d72847 stdout: 
2016-04-25T19:32:26.155Z    6d72847 stderr: 
2016-04-25T19:32:26.155Z    6d72847 status: 0
2016-04-25T19:32:26.155Z    6d72847 signal: SIGSEGV
END RequestId: 6d72847
REPORT RequestId: 6d72847   Duration: 4151.10 ms    Billed Duration: 4200 ms    Memory Size: 256 MB Max Memory Used: 84 MB  

我正在使用无服务器框架来 babelify 和部署我的代码。

注意:我已经尝试在 EC2 上的 ami-bff32ccc 实例上运行这个二进制文件( http://docs.aws.amazon.com/lambda/latest/dg/current-supported-versions.html )并且它可以工作。所以这一定是我正在做的事情(我是如何执行 ffprobe 的)。

Answer 1

试试这个。让您的 Lambda 函数生成一个执行此操作的 bash shell:


ulimit -c 无限制
光盘/tmp
$LAMBDA_TASK_ROOT/ffprobe ...


然后检查名为“/tmp/core”的文件，如果存在，将其复制到 S3 存储桶(或其他)，并使用 gdb 在您的开发系统或 EC2 主机上对其进行分析。我自己还没有验证这一点，但我知道默认情况下 ulimit 将为零，核心文件将转储到当前目录。请注意，这些细节如有更改，恕不另行通知(如果我没记错的话，最近发生了变化。)

当然，“cd”可能发生在 lambda 函数中。如果 nodejs 提供了一种设置 ulimit 的方法，它也可能发生在那里。

[编辑:正确的模式是/tmp/core.%e.%p，参见“man core”来解释。]