unexpectedly loop hanging

Hello everyone,

I was able to get all the execution paths between 2 points (basic blocks) in my program (with the condition to traverse a loop only once). I mapped all the basic blocks to integers and created a correspondent directed graph.

I was able to get all the paths (a path is represented by an integer identifier). For my target program I have 72 paths, but the program hangs unexpectedly at a for loop when I am adding metadata (which is containing the paths). This part of code was working perfectly before of changing the algorithm to traverse the loop only once. However, the traverse algorithm should be totally independent to the part of the code where I add metadata. The single influence that I see is that I have to add more metadata operands to instructions. I mention that for each metadata operand I add a path = an integer identifier. When this was working, I used to add up to 17 metadata operands, now I have up to 72.

How do I add metadata: Inside a loop iterating through basic blocks, for each basic block I take a particular instruction on which I want to attach the metadata (a path = an integer identifier). I do like this :

if( instruc )
{
LLVMContext& C = instruc->getContext();

Value* values[cnt];
errs()<<"\ngy: \n";
for(int gy=0;gy<cnt;gy++)
{
values[gy]=ConstantInt::getSigned(Type::getInt64Ty(C),myarray[gy]);
errs()<<" "<<gy;
}
}

  1. I checked before this part of the code the values of myarray and they are good
  2. It works well for the first 6 instructions (the maximum number of metadata operands they need is 70), but when I get to the 7th instruction to add metadata (with 72 operands), I hangs inside the for loop from above, having :

gy:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

and it hangs. Before this part of the code I print myarray[gy] and it it prints all the values from 0 to 71 (the basic block is contained in all possible execution paths).

What do you think is the problem? Some memory allocation (I have sufficient allocated), maybe I cannot add so many metadata operands?

Thank you for any suggestion !

As an update, it is a memory problem which I don’t know how to fix.

I tried to skip the problematic piece of code when in the case when the loop hangs. So I did something like :

if( instr )
{
LLVMContext& C = instr->getContext();

Value* values[cnt];
errs()<<"\ngy: \n";

if(!(desters==7)){ // this is the condition I put to skip the case when it hanged

for(int gy=0;gy<cnt;gy++){
values[gy]=ConstantInt::getSigned(Type::getInt64Ty(C),cebag[gy]);
errs()<<" "<<gy;
}

SmallVector<Value*, 100> bla;
for(int gy=0;gy<cnt;gy++){
bla.push_back(values[gy]);
}

instr->setMetadata(“path”,MDNode::get(C,bla));

if( (instr->getMetadata(“path”)) ){
for(int gy=0;gy<cnt;gy++){
if(instr->getMetadata(“path”)->getOperand(gy)) {
errs()<<"\n “<<*(is->getMetadata(“path”)->getOperand(gy))<<”\n";

}
}
}

} // closing bracket for the extra condition that I put

}

From the terminal output, I see that the problematic case is skipped, but then it was printed:

---------------------------PROCEED TO NEXT BB------------------------------------
opt: malloc.c:3790: _int_malloc: Assertion `(unsigned long)(size) >= (unsigned long)(nb)’ failed.

So I thought that the problem is regarding memory freeing. I was trying to free the memory for arrays like values or bla, using delete [] name and even free(), but I am getting segfault.

I think it is some basic stuff that I miss.

Thank you for any suggestion !

Hi,

I don’t know much about this issue, but this malloc error won’t be solved by a change to delete[] or free. In fact, if you use the incorrect one for simple types, you may not notice it. The error you have seems to me like a memory corruption because you went out of bound and corrupted the memory somewhere, Valgrind may help you figure out what is going on.

Cheers,

Matthieu

Thank you for your answer. It think you are right, I will try to check with Valgrind. When I had smaller graphs, I did not encountered this problem.

Hi Alexandru, did you build LLVM with assertions enabled? If not then you
should do.

Ciao, Duncan.

Hello Duncan,

Yes, I built it with assertions and I have also debug info.

As an update, here is the current piece of code:

Inside a loop iterating over each basic block :

std::vector<Value*> values;
values.resize(cnt);

//std::vector<Value*> values(sizeof(Value*)*cnt);
//SmallVector<Value*,cnt> values;

if(is)
{
LLVMContext& C = is->getContext();
errs()<<"\ni: \n";

for(i=0;i<cnt;i++){
values[i]=ConstantInt::getSigned(Type::getInt64Ty(C),myArray[i]);
errs()<<" "<<myArray[i];
}

is->setMetadata(“path”,MDNode::get(C,values));
errs()<<"\nmodif instr “<<*is<<”\n";

if( (is->getMetadata(“path”)) ){
for(i=0;i<cnt;i++){
if(is->getMetadata(“path”)->getOperand(i)) {
errs()<<"\nget isntr “<<*(is->getMetadata(“path”)->getOperand(i))<<”\n";
}
}
}
}
values.clear();

Hi Alexandru,

> /*==5134== Invalid write of size 4

==5134== at 0x4039280: (anonymous
namespace)::Hello::runOnModule(llvm::Module&) (in
/home/alex/llvm/Release+Asserts/lib/Hello.so)
==5134== by 0x8E33DE3: llvm::MPPassManager::runOnModule(llvm::Module&) (in
/home/alex/llvm/Release+Asserts/bin/opt)
==5134== by 0x8E3726F: llvm::PassManagerImpl::run(llvm::Module&) (in
/home/alex/llvm/Release+Asserts/bin/opt)
==5134== by 0x8E37385: llvm::PassManager::run(llvm::Module&) (in
/home/alex/llvm/Release+Asserts/bin/opt)
==5134== by 0x41AE4D2: (below main) (libc-start.c:226)
==5134== Address 0x46cfa40 is 0 bytes after a block of size 200 alloc'd
==5134== at 0x402C454: operator new[](unsigned int) (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==5134== by 0x4037AE0: (anonymous
namespace)::Hello::runOnModule(llvm::Module&) (in
/home/alex/llvm/Release+Asserts/lib/Hello.so)*/
==5134== Address 0x46cfa40 is 0 bytes after a block of size 200 alloc'd
==5134== at 0x402C454: operator new[](unsigned int) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==5134== by 0x4037AE0: (anonymous namespace)::Hello::runOnModule(llvm::Module&) (in /home/alex/llvm/Release+Asserts/lib/Hello.so)

you are writing of the end of an array that you allocated with "new". If you
compile your program with debug info (-g) then valgrind should give you the line
number at which the allocation occurred and the line number at which the bad
write occurred.

Ciao, Duncan.

Hello Duncan,

Thank you for your quick answer. I use the standard Makefile from a pass, that is calling Makefile.common. I saw only the make -d option, that “print lots of debugging information”, as mentioned by LLVM.

Using this, valgrind don’t tell me extra info. It is a very good idea ti use -g, but where to insert? If I am trying to use clang++, I have to fix a lot of things. Should I make the changes for to use clang++ or I can debug using the Makefile.common?

Hi Alexandru, if these are LLVM Makefiles, then I suggest you configure and
build LLVM with the options:

   --disable-optimized --enable-assertions

This will make debugging much easier. It enables debug info too, which you can
also turn on directly by configuring with --enable-debug-symbols.

Ciao, Duncan.

Hello Duncan,

I will try this alternative (I think that I already have enable-debug-symbols). However, it is not an easier way to add to an instruction an array of integers? Every element linked to one distinct operand.

PS: I am afraid of rebuild LLVM since problems arose when I was trying to do that.

Thanks you for the answer !