llvm dev - Jan 2019 - 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

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>

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>