Peng Yu via llvm-dev
2019-Jan-26 02:50 UTC
[llvm-dev] How to debug .ll file with segmentation fault?
Hi, I edited a working .ll file and llvm-as it to a .bc file. But it causes segmentation fault. I don't know how to debug such errors. Could anybody show me the best way to debug such errors? Thanks. $ TRACE_OUTFILE=/tmp/trace.txt lli /tmp/y/bash_trcr.bc --norc __trace_init LLVMSymbolizer: error reading file: No such file or directory #0 0x00007f162b1ee0ea llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x81e0ea) #1 0x00007f162b1ec366 llvm::sys::RunSignalHandlers() (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x81c366) #2 0x00007f162b1ec49b (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x81c49b) #3 0x00007f162a7c3890 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890) #4 0x00007f162a0923cc _IO_vfprintf /build/glibc-OTsEL5/glibc-2.27/stdio-common/vfprintf.c:1283:0 #5 0x00007f162a09be54 _IO_fprintf /build/glibc-OTsEL5/glibc-2.27/stdio-common/fprintf.c:36:0 #6 0x00007f1628ff648e #7 0x00007f1628e37bc0 #8 0x00007f1628ff63a4 #9 0x00007f1628fc89e5 #10 0x00007f162c3cd79d llvm::MCJIT::runFunction(llvm::Function*, llvm::ArrayRef<llvm::GenericValue>) (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x19fd79d) #11 0x00007f162c3a67f7 llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*, 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> > > > const&, char const* const*) (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x19d67f7) #12 0x0000563cd2ca472b (lli+0x2772b) #13 0x00007f162a058b97 __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:344:0 #14 0x0000563cd2cad34a (lli+0x3034a) Stack dump: 0. Program arguments: lli /tmp/y/bash_trcr.bc --norc Segmentation fault -- Regards, Peng
Chandler Carruth via llvm-dev
2019-Jan-26 05:44 UTC
[llvm-dev] How to debug .ll file with segmentation fault?
Hey Peng, I'm really excited that you're working with LLVM, but I don't think this list is really the best place to get help with the basics of debugging. I'm afraid you'll need to debug this (and learn how to debug this) kind of failure yourself. There are lots of documents and even some good books about this you can find with a quick search. If you get to the point where there is clearly a bug in LLVM upstream, you can file it on our bug tracker of course. -Chandler On Fri, Jan 25, 2019 at 6:50 PM Peng Yu via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi, > > I edited a working .ll file and llvm-as it to a .bc file. But it > causes segmentation fault. I don't know how to debug such errors. > Could anybody show me the best way to debug such errors? Thanks. > > $ TRACE_OUTFILE=/tmp/trace.txt lli /tmp/y/bash_trcr.bc --norc > __trace_init > LLVMSymbolizer: error reading file: No such file or directory > #0 0x00007f162b1ee0ea llvm::sys::PrintStackTrace(llvm::raw_ostream&) > (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x81e0ea) > #1 0x00007f162b1ec366 llvm::sys::RunSignalHandlers() > (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x81c366) > #2 0x00007f162b1ec49b > (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x81c49b) > #3 0x00007f162a7c3890 __restore_rt > (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890) > #4 0x00007f162a0923cc _IO_vfprintf > /build/glibc-OTsEL5/glibc-2.27/stdio-common/vfprintf.c:1283:0 > #5 0x00007f162a09be54 _IO_fprintf > /build/glibc-OTsEL5/glibc-2.27/stdio-common/fprintf.c:36:0 > #6 0x00007f1628ff648e > #7 0x00007f1628e37bc0 > #8 0x00007f1628ff63a4 > #9 0x00007f1628fc89e5 > #10 0x00007f162c3cd79d llvm::MCJIT::runFunction(llvm::Function*, > llvm::ArrayRef<llvm::GenericValue>) > (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x19fd79d) > #11 0x00007f162c3a67f7 > llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*, > 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> > > > const&, char const* > const*) (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x19d67f7) > #12 0x0000563cd2ca472b (lli+0x2772b) > #13 0x00007f162a058b97 __libc_start_main > /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:344:0 > #14 0x0000563cd2cad34a (lli+0x3034a) > Stack dump: > 0. Program arguments: lli /tmp/y/bash_trcr.bc --norc > Segmentation fault > > -- > Regards, > Peng > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190125/8562f14a/attachment-0001.html>
Peng Yu via llvm-dev
2019-Jan-26 07:05 UTC
[llvm-dev] How to debug .ll file with segmentation fault?
Could you give specific pointers to the resources that are relevant to segmentation fault debugging? This kind of bug is the hardest to bebug because the error message has nothing to do with the actual bug. Generic advices without consideration of specific properties of the problem will surely end up inefficient debugging. What I added to the .ll file in this case are just function calls to write something to a file without touching any thing else in the original .ll. I can not envision how such changes can cause segmentation faults. How can even be sure the bug is in the .ll code but not in lli? Also, in this case, I don’t think running lli through lldb or gdb can be helpful, as it will show information of lli not the bitcode converted from the edited .ll file. On Fri, Jan 25, 2019 at 11:44 PM Chandler Carruth <chandlerc at gmail.com> wrote:> Hey Peng, > > I'm really excited that you're working with LLVM, but I don't think this > list is really the best place to get help with the basics of debugging. I'm > afraid you'll need to debug this (and learn how to debug this) kind of > failure yourself. There are lots of documents and even some good books > about this you can find with a quick search. > > If you get to the point where there is clearly a bug in LLVM upstream, > you can file it on our bug tracker of course. > > -Chandler > > > On Fri, Jan 25, 2019 at 6:50 PM Peng Yu via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> >> I edited a working .ll file and llvm-as it to a .bc file. But it >> causes segmentation fault. I don't know how to debug such errors. >> Could anybody show me the best way to debug such errors? Thanks. >> >> $ TRACE_OUTFILE=/tmp/trace.txt lli /tmp/y/bash_trcr.bc --norc >> __trace_init >> LLVMSymbolizer: error reading file: No such file or directory >> #0 0x00007f162b1ee0ea llvm::sys::PrintStackTrace(llvm::raw_ostream&) >> (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x81e0ea) >> #1 0x00007f162b1ec366 llvm::sys::RunSignalHandlers() >> (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x81c366) >> #2 0x00007f162b1ec49b >> (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x81c49b) >> #3 0x00007f162a7c3890 __restore_rt >> (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890) >> #4 0x00007f162a0923cc _IO_vfprintf >> /build/glibc-OTsEL5/glibc-2.27/stdio-common/vfprintf.c:1283:0 >> #5 0x00007f162a09be54 _IO_fprintf >> /build/glibc-OTsEL5/glibc-2.27/stdio-common/fprintf.c:36:0 >> #6 0x00007f1628ff648e >> #7 0x00007f1628e37bc0 >> #8 0x00007f1628ff63a4 >> #9 0x00007f1628fc89e5 >> #10 0x00007f162c3cd79d llvm::MCJIT::runFunction(llvm::Function*, >> llvm::ArrayRef<llvm::GenericValue>) >> (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x19fd79d) >> #11 0x00007f162c3a67f7 >> llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*, >> 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> > > > const&, char const* >> const*) (/usr/lib/llvm-6.0/bin/../lib/libLLVM-6.0.so.1+0x19d67f7) >> #12 0x0000563cd2ca472b (lli+0x2772b) >> #13 0x00007f162a058b97 __libc_start_main >> /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:344:0 >> #14 0x0000563cd2cad34a (lli+0x3034a) >> Stack dump: >> 0. Program arguments: lli /tmp/y/bash_trcr.bc --norc >> Segmentation fault >> >> -- >> Regards, >> Peng >> > _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > --Regards, Peng -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190126/edb7ee4b/attachment.html>
Seemingly Similar Threads
- How to debug .ll file with segmentation fault?
- Interpreter crash due to an "Unknown constant pointer type!"
- Interpreter crash due to an "Unknown constant pointer type!"
- Illegal instruction (core dumped) LLVM 8.0
- Interpreter crash due to an "Unknown constant pointer type!"