Ошибка сегментации во время выполнения AWS lambda R

Question

Я пытаюсь создать слой времени выполнения, чтобы разрешить использование R в качестве среды выполнения для лямбда-функций, используя их новый API времени выполнения .

Для этого я создал слой, который содержитвсе зависимости, необходимые для R, а затем второй слой, содержащий сам R.Я создал эти слои, используя тот же Amazon AMI, на котором работает lambda.Я проверил мою сборку, сжав мои слои, создав новый экземпляр, а затем загрузив и распаковав слои в этот новый экземпляр (поместив все в / opt, что также происходит там, где я установил R и его зависимости, когда я их строил),Я использовал тип экземпляра с минимальными ресурсами (2 процессора, 4 ГБ оперативной памяти).Насколько я понимаю, это должно очень близко приближать к лямбда-окружению.

У меня есть небольшой тестовый скрипт (test.r), который просто печатает сообщение на стандартный вывод.Это нормально работает в тестовой среде.Вот сценарий:

cat("hello from planet lambdar")

А вот как он вызывается в сценарии начальной загрузки в моем слое:

SCRIPT=$LAMBDA_TASK_ROOT/$(echo "$_HANDLER" | cut -d. -f1).r
  echo "About to run $SCRIPT"
  /opt/R/bin/Rscript $SCRIPT

Из приведенных ниже журналов видно, что имяскрипт отправляется и анализируется правильно.Ранее я подтвердил, что скрипт test.r попадает в / var / task, как и ожидалось.Но выполнение этого скрипта через лямбду приводит к ошибке сегментации:

START RequestId: 2c1b8801-f903-11e8-a32d-796c039278f1 Version: $LATEST
About to run /var/task/test.r
/opt/bootstrap: line 18:    18 Segmentation fault      (core dumped) /opt/R/bin/Rscript $SCRIPT

Как отладить эту ошибку сегментации, если процесс работает нормально на минимальном экземпляре EC2, работающем с тем же Amazon AMI, который используется lambda, загруженным стот же набор инструментов и зависимостей, которые я создал для слоев, которые я добавил в свою лямбда-функцию?

Answer 1

В этом случае оказалось, что я был слишком агрессивен при копировании разделяемых библиотек, связанных с исполняемым файлом R, в мой слой.Я взял все перечисленное с помощью

ldd /opt/R/lib/libR.so

и скопировал его в / opt / lib

Проблема в том, что многие из этих библиотек уже были в AMI, и их присутствие в другом месте вызвалопроблемы (возможно, связанные с кешем библиотек?).

Переместив только две библиотеки, которые не были в AMI (но добавлены, когда я установил инструменты сборки, которые, конечно, не находятся в среде Lambda),Сегфо ушел.Этими двумя библиотеками являются:

/usr/lib64/libgfortran.so.3
/usr/lib64/libquadmath.so.0

Чтобы ответить на более глубокий вопрос здесь, а именно, как отлаживать segfaults в среде Lambda, я нашел вдохновение здесь и включилчто-то вроде этого в моем скрипте bootstrap, чтобы напечатать обратную трассировку из дампа памяти:

gdb -q -n -ex bt -batch /opt/R/bin/Rscript /temp/core.N.XXXX

Где core.N.XXXX - имя файла дампа ядра (который можно обнаружить, поставив echo $(ls /tmp) в вашем bootstrap скрипте).Журналы Cloudwatch будут содержать хотя бы некоторые подсказки от следа.