[llvm-bugs] [Bug 28799] New: DwarfEHPrepare pass crashed when trying to obtain function personality

via llvm-bugs llvm-bugs at lists.llvm.org
Mon Aug 1 10:41:37 PDT 2016


https://llvm.org/bugs/show_bug.cgi?id=28799

            Bug ID: 28799
           Summary: DwarfEHPrepare pass crashed when trying to obtain
                    function personality
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: feishenniubi at gmail.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Created attachment 16853
  --> https://llvm.org/bugs/attachment.cgi?id=16853&action=edit
The crash-triggering bitcode

This issue came up when I was trying to compile bitcodes reduced by bugpoint.
It could be the problem of bugpoint test reduction, but I can't really tell
since I'm not really familiar with the CodeGen part in LLVM.

One can reproduce the problem with the following command:
> opt eh.ll -dwarfehprepare
(where eh.ll is a file generated by running bugpoint on some other file)

And here's the crashing output:

opt: /home/grieve/LLVM/GSoC/Testing/llvm/lib/IR/Function.cpp:1190:
llvm::Constant* llvm::Function::getPersonalityFn() const: Assertion
`hasPersonalityFn() && getNumOperands()' failed.
#0 0x00007fd308276f38 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
/home/grieve/LLVM/GSoC/Testing/llvm/lib/Support/Unix/Signals.inc:402:0
#1 0x00007fd308277298 PrintStackTraceSignalHandler(void*)
/home/grieve/LLVM/GSoC/Testing/llvm/lib/Support/Unix/Signals.inc:470:0
#2 0x00007fd308275548 llvm::sys::RunSignalHandlers()
/home/grieve/LLVM/GSoC/Testing/llvm/lib/Support/Signals.cpp:44:0
#3 0x00007fd308276896 SignalHandler(int)
/home/grieve/LLVM/GSoC/Testing/llvm/lib/Support/Unix/Signals.inc:256:0
#4 0x00007fd306843cb0 (/lib/x86_64-linux-gnu/libc.so.6+0x36cb0)
#5 0x00007fd306843c37 gsignal
/build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0
#6 0x00007fd306847028 abort
/build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0
#7 0x00007fd30683cbf6 __assert_fail_base
/build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92:0
#8 0x00007fd30683cca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2)
#9 0x00007fd30a5e65de llvm::Function::getPersonalityFn() const
/home/grieve/LLVM/GSoC/Testing/llvm/lib/IR/Function.cpp:1191:0
#10 0x00007fd30afa60cd (anonymous
namespace)::DwarfEHPrepare::InsertUnwindResumeCalls(llvm::Function&)
/home/grieve/LLVM/GSoC/Testing/llvm/lib/CodeGen/DwarfEHPrepare.cpp:196:0
#11 0x00007fd30afa66ac (anonymous
namespace)::DwarfEHPrepare::runOnFunction(llvm::Function&)
/home/grieve/LLVM/GSoC/Testing/llvm/lib/CodeGen/DwarfEHPrepare.cpp:260:0
#12 0x00007fd30a650131 llvm::FPPassManager::runOnFunction(llvm::Function&)
/home/grieve/LLVM/GSoC/Testing/llvm/lib/IR/LegacyPassManager.cpp:1526:0
#13 0x00007fd30a6502a8 llvm::FPPassManager::runOnModule(llvm::Module&)
/home/grieve/LLVM/GSoC/Testing/llvm/lib/IR/LegacyPassManager.cpp:1547:0
#14 0x00007fd30a650601 (anonymous
namespace)::MPPassManager::runOnModule(llvm::Module&)
/home/grieve/LLVM/GSoC/Testing/llvm/lib/IR/LegacyPassManager.cpp:1603:0
#15 0x00007fd30a650d01 llvm::legacy::PassManagerImpl::run(llvm::Module&)
/home/grieve/LLVM/GSoC/Testing/llvm/lib/IR/LegacyPassManager.cpp:1706:0
#16 0x00007fd30a650f0d llvm::legacy::PassManager::run(llvm::Module&)
/home/grieve/LLVM/GSoC/Testing/llvm/lib/IR/LegacyPassManager.cpp:1738:0
#17 0x0000000000469cc6 main
/home/grieve/LLVM/GSoC/Testing/llvm/tools/opt/opt.cpp:682:0
#18 0x00007fd30682ef45 __libc_start_main
/build/eglibc-oGUzwX/eglibc-2.19/csu/libc-start.c:321:0
#19 0x000000000044f4d9 _start (bin/opt+0x44f4d9)
Stack dump:
0.    Program arguments: bin/opt -dwarfehprepare eh.bc 
1.    Running pass 'Function Pass Manager' on module 'eh.bc'.
2.    Running pass 'Exception handling preparation' on function
'@main_ehcleanup.ce'


I also tried to use bugpoint on eh.ll itself and got a reduced version of eh.ll
that triggers the same assertion failure. I'm not 100% sure whether it was
exactly the same problem, but I'll just upload the reduced one anyway since it
may be easier to deal with.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160801/d16305b5/attachment.html>


More information about the llvm-bugs mailing list