[LLVMbugs] [Bug 1073] NEW: When destructing a module in the LTO, ilist assertion fails.

[bugzilla-daemon at cs.uiuc.edu]

http://llvm.org/bugs/show_bug.cgi?id=1073

           Summary: When destructing a module in the LTO, ilist assertion
                    fails.
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Linker
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: chandlerc at gmail.com


When destroying the LTO, and therefore its various modules, an assertion fails
during the clearing of the global variable ilist in the module. A backtrace is
as follows:

ld: /home/chandlerc/code/compilers/llvm/include/llvm/ADT/ilist:120: typename
bidirectional_iterator<NodeTy, long int>::reference
llvm::ilist_iterator<NodeTy>::operator*() const [with NodeTy =
llvm::GlobalVariable]: Assertion `Traits::getNext(NodePtr) != 0 &&
"Dereferencing end()!"' failed.

Program received signal SIGABRT, Aborted.
[Switching to Thread 47687191382816 (LWP 4590)]
_______________________________________________________________________________
Error while running hook_stop:
Value can't be converted to integer.
0x00002b5f09f997b5 in raise () from /lib/libc.so.6
gdb> bt
#0  0x00002b5f09f997b5 in raise () from /lib/libc.so.6
#1  0x00002b5f09f9aa4e in abort () from /lib/libc.so.6
#2  0x00002b5f09f93156 in __assert_fail () from /lib/libc.so.6
#3  0x00000000005e33b7 in llvm::ilist_iterator<llvm::GlobalVariable>::operator*
(this=0x7fffa13e3c00) at
/home/chandlerc/code/compilers/llvm/include/llvm/ADT/ilist:120
#4  0x00000000005e33d3 in llvm::ilist_iterator<llvm::GlobalVariable>::operator->
(this=0x7fffa13e3c00) at
/home/chandlerc/code/compilers/llvm/include/llvm/ADT/ilist:123
#5  0x00000000009aba7a in llvm::SymbolTableListTraits<llvm::GlobalVariable,
llvm::Module, llvm::Module, llvm::ilist_traits<llvm::GlobalVariable>
>::setParent (this=0xefcfb0, STO=0x0) at
/home/chandlerc/code/compilers/llvm/lib/VMCore/SymbolTableListTraitsImpl.h:35
#6  0x00000000009aa8fe in ~Module (this=0xefcfb0) at
/home/chandlerc/code/compilers/llvm/lib/VMCore/Module.cpp:77
#7  0x000000000069eaee in ~LTO (this=0xedb430) at
/home/chandlerc/code/compilers/llvm/tools/lto/lto.cpp:471
#8  0x000000000069ab88 in llvm_destroy_optimizer (lto=0xedb430) at
/home/chandlerc/code/compilers/llvm/tools/lto/lto_capi.cpp:35
#9  0x0000000000418ab5 in remove_llvm_lto () at ../../../binutils/ld/ldmain.c:195
#10 0x000000000069a6d9 in xatexit_cleanup () at
../../../binutils/libiberty/xatexit.c:98
#11 0x000000000069a701 in xexit (code=0x0) at ../../../binutils/libiberty/xexit.c:50
#12 0x000000000041926b in c_main (argc=0x18, argv=0x7fffa13e3e98) at
../../../binutils/ld/ldmain.c:601
#13 0x00002b5f09f87394 in __libc_start_main () from /lib/libc.so.6
#14 0x0000000000407a09 in _start ()

The only idea I have is that somewhere in the optimization passes, the list
became corrupted, as when setParent was called the first time, the same loop
succeeds to add the symbols _into_ the symbol table. Removing them causing an
error doesn't make sense unless the list were corrupted in-between.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.