Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

python 3.4, llvm 3.8.1 -> segfault #633

Closed
Serafean opened this issue Jul 27, 2016 · 1 comment
Closed

python 3.4, llvm 3.8.1 -> segfault #633

Serafean opened this issue Jul 27, 2016 · 1 comment

Comments

@Serafean
Copy link

backtrace (likely incomplete, if needed I'll recompile with debug symbols) :
(gdb) bt
#0 0x00007f3c4e7eafa7 in raise () from /lib64/libc.so.6
#1 0x00007f3c4e7ec30a in abort () from /lib64/libc.so.6
#2 0x00007f3c4e829394 in ?? () from /lib64/libc.so.6
#3 0x00007f3c4e82ec06 in ?? () from /lib64/libc.so.6
#4 0x00007f3c4e82f963 in ?? () from /lib64/libc.so.6
#5 0x00007f3c4c8f81c2 in ?? () from /usr/lib64/libclangFrontend.so.3.8
#6 0x00007f3c4c8ff266 in clang::CompilerInvocation::CreateFromArgs(clang::CompilerInvocation&, char const* const_, char const_ const*, clang::DiagnosticsEngine&) () from /usr/lib64/libclangFrontend.so.3.8
#7 0x00007f3c4cc0eef4 in ebpf::ClangLoader::parse(std::unique_ptr<llvm::Module, std::default_deletellvm::Module >, std::unique_ptr<std::vector<ebpf::TableDesc, std::allocatorebpf::TableDesc >, std::default_delete<std::vector<ebpf::TableDesc, std::allocatorebpf::TableDesc > > >, std::string const&, bool, char const**, int) () from /usr/lib64/libbcc.so.0
#8 0x00007f3c4cbbf831 in ebpf::BPFModule::load_cfile(std::string const&, bool, char const**, int) () from /usr/lib64/libbcc.so.0
#9 0x00007f3c4cbc5722 in ebpf::BPFModule::load_c(std::string const&, char const**, int) () from /usr/lib64/libbcc.so.0
#10 0x00007f3c4cbbe9f4 in bpf_module_create_c () from /usr/lib64/libbcc.so.0
#11 0x00007f3c4da99f8e in ffi_call_unix64 () from /usr/lib64/libffi.so.6
#12 0x00007f3c4da999f8 in ffi_call () from /usr/lib64/libffi.so.6
#13 0x00007f3c4dd051a6 in _ctypes_callproc () from /usr/lib64/python3.4/lib-dynload/_ctypes.cpython-34m.so
#14 0x00007f3c4dcff68f in ?? () from /usr/lib64/python3.4/lib-dynload/_ctypes.cpython-34m.so
#15 0x00007f3c4edce178 in PyObject_Call () from /usr/lib64/libpython3.4m.so.1.0
#16 0x00007f3c4ee7e0c1 in PyEval_EvalFrameEx () from /usr/lib64/libpython3.4m.so.1.0
#17 0x00007f3c4ee8213e in PyEval_EvalCodeEx () from /usr/lib64/libpython3.4m.so.1.0
#18 0x00007f3c4edf5e53 in ?? () from /usr/lib64/libpython3.4m.so.1.0
#19 0x00007f3c4edce178 in PyObject_Call () from /usr/lib64/libpython3.4m.so.1.0
#20 0x00007f3c4ede26bd in ?? () from /usr/lib64/libpython3.4m.so.1.0
#21 0x00007f3c4edce178 in PyObject_Call () from /usr/lib64/libpython3.4m.so.1.0
#22 0x00007f3c4ee23df0 in ?? () from /usr/lib64/libpython3.4m.so.1.0
#23 0x00007f3c4ee219d6 in ?? () from /usr/lib64/libpython3.4m.so.1.0
#24 0x00007f3c4edce178 in PyObject_Call () from /usr/lib64/libpython3.4m.so.1.0
#25 0x00007f3c4ee7e0c1 in PyEval_EvalFrameEx () from /usr/lib64/libpython3.4m.so.1.0
#26 0x00007f3c4ee8213e in PyEval_EvalCodeEx () from /usr/lib64/libpython3.4m.so.1.0
#27 0x00007f3c4ee8220b in PyEval_EvalCode () from /usr/lib64/libpython3.4m.so.1.0
#28 0x00007f3c4ee9d354 in ?? () from /usr/lib64/libpython3.4m.so.1.0
#29 0x00007f3c4ee9f30d in PyRun_FileExFlags () from /usr/lib64/libpython3.4m.so.1.0
#30 0x00007f3c4eea01e1 in PyRun_SimpleFileExFlags () from /usr/lib64/libpython3.4m.so.1.0
#31 0x00007f3c4eeb587c in Py_Main () from /usr/lib64/libpython3.4m.so.1.0
#32 0x0000000000400b19 in main ()

This is under Gentoo, bcc installed manually.
Kernel 4.4.11
Program run is the task_switch example.

@mlen
Copy link

mlen commented Aug 3, 2016

drzaeus77 pushed a commit that referenced this issue Aug 3, 2016
Based on the bug report in
https://bugs.gentoo.org/show_bug.cgi?id=582770, mixing static+non-static
libstdc++ can lead to crashes. Disable such combinations. Choosing to
leave out the llvm check, since in practice clang is less likely to be
provided statically, so the check should cover both cases.

Fixes: #633
Signed-off-by: Brenden Blanco <[email protected]>
@4ast 4ast closed this as completed in #647 Aug 5, 2016
4ast pushed a commit that referenced this issue Aug 5, 2016
Based on the bug report in
https://bugs.gentoo.org/show_bug.cgi?id=582770, mixing static+non-static
libstdc++ can lead to crashes. Disable such combinations. Choosing to
leave out the llvm check, since in practice clang is less likely to be
provided statically, so the check should cover both cases.

Fixes: #633
Signed-off-by: Brenden Blanco <[email protected]>
chantra pushed a commit to chantra/bcc that referenced this issue Sep 16, 2016
Based on the bug report in
https://bugs.gentoo.org/show_bug.cgi?id=582770, mixing static+non-static
libstdc++ can lead to crashes. Disable such combinations. Choosing to
leave out the llvm check, since in practice clang is less likely to be
provided statically, so the check should cover both cases.

Fixes: iovisor#633
Signed-off-by: Brenden Blanco <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants