[LLVMbugs] [Bug 1404] NEW: Assertion "New cannot be in the map!" in llvm-gcc

[bugzilla-daemon at cs.uiuc.edu]

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

           Summary: Assertion "New cannot be in the map!" in llvm-gcc
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr


I hit the assertion
  assert(!LLVMValuesMap.count(New) && "New cannot be in the map!");
in changeLLVMValue.  What's going on is that LLVMValuesMap, which maps
numbers to LLVM values, contains an entry for a freed value.  The freed
memory has been reused when allocating the new value.  Then the assertion
thinks that the same value is being added twice, because the new pointer to
be added is already present, and fires.

Needless to say I can't hit this every time, just from time to time.
I only hit it while compiling the Ada f-e.  Ada does not use unit-at-a-time,
maybe this is relevant?

Here's where the memory was freed:

operator delete(void*) (vg_replace_malloc.c:336)
llvm::AllocaInst::~AllocaInst() (Instructions.h:144)
llvm::iplist<llvm::Instruction, llvm::ilist_traits<llvm::Instruction> 
>::erase(llvm::ilist_iterator<llvm::Instruction>) (ilist:330)
llvm::Instruction::eraseFromParent() (Instruction.cpp:68)
(anonymous namespace)::InstCombiner::DoOneIteration(llvm::Function&, unsigned) 
(InstructionCombining.cpp:9837)
(anonymous namespace)::InstCombiner::runOnFunction(llvm::Function&) 
(InstructionCombining.cpp:9959)
llvm::FPPassManager::runOnFunction(llvm::Function&) (PassManager.cpp:1145)
llvm::FunctionPassManagerImpl::run(llvm::Function&) (PassManager.cpp:1103)
llvm::FunctionPassManager::run(llvm::Function&) (PassManager.cpp:1048)
llvm_emit_code_for_current_function (llvm-backend.cpp:524)
tree_rest_of_compilation (tree-optimize.c:706)
cgraph_expand_function (cgraphunit.c:896)

By the way, valgrind doesn't complain.  This is normal: freed memory is not
being accessed.

A quick fix is to add
  LLVMValuesMap.erase(New);
at the start of changeLLVMValue.  However that begs the question of
whether freed memory should be floating around in this map or not?



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