[LLVMdev] unexpectedly loop hanging

Tue May 28 08:07:13 PDT 2013

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.

On Tue, May 28, 2013 at 5:02 PM, Matthieu Brucher <
matthieu.brucher at gmail.com> wrote:

> 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
>
>
> 2013/5/28 Alexandru Ionut Diaconescu <alexandruionutdiaconescu at gmail.com>
>
>> 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 !
>>
>>
>>
>> On Tue, May 28, 2013 at 10:02 AM, Alexandru Ionut Diaconescu <
>> alexandruionutdiaconescu at gmail.com> wrote:
>>
>>> 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 !
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Best regards,
>> Alexandru Ionut Diaconescu
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
>
> --
> Information System Engineer, Ph.D.
> Blog: http://matt.eifelle.com
> LinkedIn: http://www.linkedin.com/in/matthieubrucher
> Music band: http://liliejay.com/
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>

-- 
Best regards,
Alexandru Ionut Diaconescu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130528/08832686/attachment.html>