[英]illegal instruction on aws batch
I'm trying to submit a demo job to batch compute that tests if I can properly use a python module "cppyy".我正在尝试提交一个演示作业来进行批量计算,以测试我是否可以正确使用 python 模块“cppyy”。
However, I received "illegal instruction" core dump error.但是,我收到“非法指令”核心转储错误。 Interestingly, I didn't receive any error message if I run the job at a container (same image) run on a local ec2 instance.
有趣的是,如果我在本地 ec2 实例上运行的容器(相同图像)上运行作业,我没有收到任何错误消息。
The following the script, test.py
used for the entry point, python3 test.py
以下脚本,
test.py
用于入口点, python3 test.py
import cppyy
cppyy.cppdef(r'''
#include <cmath>
#include <vector>
#include <memory>
#include <iostream>
using namespace std;
namespace Test {
void test() {
cout << "test-yoyo-5" << endl;
unsigned long long timestamp = 1629072000081;
vector<shared_ptr<unsigned long long>> events;
events.push_back(make_shared<unsigned long long>(1629072000081));
for (auto &event: events) {
cout << "static_cast<double>(event->timestamp - timestamp): " << static_cast<double>(*event - timestamp) << endl;
}
}
}
''')
from cppyy.gbl import Test
Test.test()
The core dump error follows核心转储错误如下
*** Break *** illegal instruction
test-yoyo-5
Generating stack trace...
0x00007f4812ecaf43 in <unknown> from /usr/local/lib/python3.9/site-packages/cppyy_backend/lib/libcppyy_backend.so
0x00007f48109bae39 in <unknown> from /usr/local/lib/python3.9/site-packages/libcppyy.cpython-39-x86_64-linux-gnu.so
0x00007f481098b879 in <unknown> from /usr/local/lib/python3.9/site-packages/libcppyy.cpython-39-x86_64-linux-gnu.so
0x00007f481098d249 in CPyCppyy::CPPMethod::Execute(void*, long, CPyCppyy::CallContext*) at /tmp/pip-install-vu_2b778/cpycppyy_c9bff3ea1a5d49d695ef46619c091741/src/CPPMethod.cxx:892 from /usr/local/lib/python3.9/site-packages/libcppyy.cpython-39-x86_64-linux-gnu.so
0x00007f481098782f in CPyCppyy::CPPFunction::Call(CPyCppyy::CPPInstance*&, _object* const*, unsigned long, _object*, CPyCppyy::CallContext*) at /tmp/pip-install-vu_2b778/cpycppyy_c9bff3ea1a5d49d695ef46619c091741/src/CPPFunction.cxx:90 from /usr/local/lib/python3.9/site-packages/libcppyy.cpython-39-x86_64-linux-gnu.so
0x00007f4810992fd1 in <unknown> from /usr/local/lib/python3.9/site-packages/libcppyy.cpython-39-x86_64-linux-gnu.so
0x000055e4b7135a2a in _PyEval_EvalFrameDefault + 0x6b8a from python3
0x000055e4b71f6184 in <unknown> from python3
0x000055e4b71f64aa in PyEval_EvalCode + 0x3a from python3
0x000055e4b72365ac in <unknown> from python3
0x000055e4b72385f0 in PyRun_SimpleFileExFlags + 0x1a0 from python3
0x000055e4b7138bef in <unknown> from python3
0x000055e4b7139290 in Py_BytesMain + 0x70 from python3
0x00007f4817d45d90 in <unknown> from /lib/x86_64-linux-gnu/libc.so.6
0x00007f4817d45e40 in __libc_start_main + 0x80 from /lib/x86_64-linux-gnu/libc.so.6
0x000055e4b7137e75 in _start + 0x25 from python3
*** Break *** illegal instruction
Generating stack trace...
0x00007f4812ecaf43 in <unknown> from /usr/local/lib/python3.9/site-packages/cppyy_backend/lib/libcppyy_backend.so
0x00007f48109bae39 in <unknown> from /usr/local/lib/python3.9/site-packages/libcppyy.cpython-39-x86_64-linux-gnu.so
0x00007f481098b879 in <unknown> from /usr/local/lib/python3.9/site-packages/libcppyy.cpython-39-x86_64-linux-gnu.so
0x00007f481098d249 in CPyCppyy::CPPMethod::Execute(void*, long, CPyCppyy::CallContext*) at /tmp/pip-install-vu_2b778/cpycppyy_c9bff3ea1a5d49d695ef46619c091741/src/CPPMethod.cxx:892 from /usr/local/lib/python3.9/site-packages/libcppyy.cpython-39-x86_64-linux-gnu.so
0x00007f481098782f in CPyCppyy::CPPFunction::Call(CPyCppyy::CPPInstance*&, _object* const*, unsigned long, _object*, CPyCppyy::CallContext*) at /tmp/pip-install-vu_2b778/cpycppyy_c9bff3ea1a5d49d695ef46619c091741/src/CPPFunction.cxx:90 from /usr/local/lib/python3.9/site-packages/libcppyy.cpython-39-x86_64-linux-gnu.so
0x00007f4810992fd1 in <unknown> from /usr/local/lib/python3.9/site-packages/libcppyy.cpython-39-x86_64-linux-gnu.so
0x000055e4b7135a2a in _PyEval_EvalFrameDefault + 0x6b8a from python3
0x000055e4b71f6184 in <unknown> from python3
0x000055e4b71f64aa in PyEval_EvalCode + 0x3a from python3
0x000055e4b72365ac in <unknown> from python3
0x000055e4b72385f0 in PyRun_SimpleFileExFlags + 0x1a0 from python3
0x000055e4b7138bef in <unknown> from python3
0x000055e4b7139290 in Py_BytesMain + 0x70 from python3
0x00007f4817d45d90 in <unknown> from /lib/x86_64-linux-gnu/libc.so.6
0x00007f4817d45e40 in __libc_start_main + 0x80 from /lib/x86_64-linux-gnu/libc.so.6
0x000055e4b7137e75 in _start + 0x25 from python3
static_cast<double>(event->timestamp - timestamp):
You're not specifying the version of cppyy, but most likely the cause is the precompiled header (PCH).您没有指定 cppyy 的版本,但最有可能的原因是预编译的 header (PCH)。 cppyy by default uses the
-march=native
flag, which enables (if the host supports it) such things as AVX. cppyy 默认使用
-march=native
标志,它启用(如果主机支持)诸如 AVX 之类的东西。 If you then ship an instance with the PCH to a machine that doesn't support it, any JITted code may still use AVX b/ca compile-time variable __AVX__
will be baked into it.如果您随后将带有 PCH 的实例发送到不支持它的机器,任何 JITted 代码仍可能使用 AVX b/ca 编译时变量
__AVX__
将被烘焙到其中。
(Older versions of cppyy explicitly use -mavx
if available on the host.) (如果在主机上可用,旧版本的 cppyy 明确使用
-mavx
。)
When running in a heterogeneous environment, you can set CLING_REBUILD_PCH=1
to get around this, or even CLING_STANDARD_PCH=none
to have no PCH altogether as a PCH only makes sense when cppyy is imported multiple times from different processes (it only saves on startup time).在异构环境中运行时,您可以设置
CLING_REBUILD_PCH=1
来解决这个问题,甚至可以设置 CLING_STANDARD_PCH CLING_STANDARD_PCH=none
完全没有 PCH,因为 PCH 仅在从不同进程多次导入 cppyy 时才有意义(它仅节省启动时间).
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.