Segmentation fault (core dumped) when running btrfsslower.py #1221
Comments
|
Same error when trying stacksnoop hid_scan_report. |
|
I checked fc26. Looks like they only install llvm shared libraries. If you build locally on fc26, you will have issue as well: [yhs@localhost build]$ !41 but this file does not exist. Possible reasons include: The current bcc requires static libraries. @drzaeus77 I forgot the history. Is static library absolutely required? |
|
@yonghong-song Do you have llvm-static package installed? Notice that this package is a BuildRequire in the bcc spec file in Fedora. |
|
As a workaround, you can follow instructions in INSTALL.md to build llvm locally. |
|
@r4f4 good, I'll try this in the next few days. |
|
I compiled bcc from source and in both python3 and python2 I get the following error when trying to execute the tools: `# ./cachestat Traceback (most recent call last): |
|
It works fine in my fc25 environment. |
|
@yonghong-song interesting. I will try again in a fc25 box. |
|
Indeed it works fine on f25. Here are the differences: fc25: kernel-4.11.8-200, llvm-3.9.1-3, python-3.5.3-6 |
|
I see similar errors running any of the tools under arch linux, having built from AUR: |
|
This may help - the CPP HelloWorld which builds a static copy of libbcc inside itself segfaults, so we can examine it with gdb a bit (this is compiled on Arch with the same above versions): |
|
The relocation bug is fixed in llvm/clang 5.0, not released yet.
…On Tue, Aug 1, 2017 at 5:28 PM, Troy Engel ***@***.***> wrote:
This may help - the CPP HelloWorld which builds a static copy of libbcc
inside itself segfaults, so we can examine it with gdb a bit (this is
compiled on Arch with the same above versions):
# gdb -q ./HelloWorld
Reading symbols from ./HelloWorld...(no debugging symbols found)...done.
(gdb) r
Starting program: /root/foo/HelloWorld
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
warning: JITed object file architecture unknown is not compatible with target architecture i386:x86-64.
Program received signal SIGSEGV, Segmentation fault.
0x0000000101995354 in llvm::RuntimeDyldELF::resolveRelocation(llvm::RelocationEntry const&, unsigned long)
()
(gdb) bt
#0 0x0000000101995354 in llvm::RuntimeDyldELF::resolveRelocation(llvm::RelocationEntry const&, unsigned long) ()
#1 0x0000000101995385 in llvm::RuntimeDyldELF::resolveRelocation(llvm::RelocationEntry const&, unsigned long) ()
#2 0x0000000101995385 in llvm::RuntimeDyldELF::resolveRelocation(llvm::RelocationEntry const&, unsigned long) ()
#3 0x000000010197d8f9 in llvm::RuntimeDyldImpl::resolveRelocationList(llvm::SmallVector<llvm::RelocationEntry, 64u> const&, unsigned long) ()
#4 0x0000000101980d09 in llvm::RuntimeDyldImpl::resolveRelocations() ()
#5 0x0000000101966871 in llvm::MCJIT::finalizeLoadedModules() ()
#6 0x0000000101966e52 in llvm::MCJIT::finalizeObject() ()
#7 0x000000010064a7e2 in ebpf::BPFModule::finalize() ()
#8 0x0000000100656373 in ebpf::BPF::init(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::vector<ebpf::USDT, std::allocator<ebpf::USDT> >) ()
#9 0x000000010060570e in main ()
(gdb) frame 0
#0 0x0000000101995354 in llvm::RuntimeDyldELF::resolveRelocation(llvm::RelocationEntry const&, unsigned long) ()
(gdb) info frame
Stack level 0, frame at 0x7fffffffe000:
rip = 0x101995354 in llvm::RuntimeDyldELF::resolveRelocation(llvm::RelocationEntry const&, unsigned long)
; saved rip = 0x101995385
called by frame at 0x7fffffffe020
Arglist at 0x7fffffffdfe8, args:
Locals at 0x7fffffffdfe8, Previous frame's sp is 0x7fffffffe000
Saved registers:
rip at 0x7fffffffdff8
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1221 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ALq6omA01oqENXO-87WOAy8IZVx-a6cIks5sT8KxgaJpZM4N2RmY>
.
|
|
I suggest that you use the manual approach described in INSTALL. build llvm and bcc from source codes temporarily until clang/llvm 5.0 official out. |
Can you provide a link or bugzilla # for this bug? I'm wondering if/when the fix will be backported, and my google-fu is failing. |
|
It is fixed by the following llvm patch: commit bd87726db47eb83032b456d062e936bfc3b3bcaa |
|
Thanks @yonghong-song and @4ast for the patch. If other people are looking, the patch is: https://reviews.llvm.org/rL302055 FWIW, I hit this on Fedora 26 as well. In case people are searching for it, here's the info: and the stack: |
|
long since fixed, closing |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is on Fedora 26 (basically the packages are at versions for the beta release)
bcc-0.3.0-2.fc26.x86_64
kernel-4.11.3-300.fc26.x86_64
python3-3.6.1-6.fc26.x86_64
The text was updated successfully, but these errors were encountered: