unexpectedly loop hanging

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

unexpectedly loop hanging

Alexandru Ionut Diaconescu
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 !






_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: unexpectedly loop hanging

Alexandru Ionut Diaconescu
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 <[hidden email]> 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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: unexpectedly loop hanging

Matthieu Brucher
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 <[hidden email]>
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 <[hidden email]> 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
[hidden email]         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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: unexpectedly loop hanging

Alexandru Ionut Diaconescu
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 <[hidden email]> 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 <[hidden email]>
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 <[hidden email]> 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
[hidden email]         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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




--
Best regards,
Alexandru Ionut Diaconescu

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: unexpectedly loop hanging

Duncan Sands
In reply to this post by Alexandru Ionut Diaconescu
Hi Alexandru, did you build LLVM with assertions enabled?  If not then you
should do.

Ciao, Duncan.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: unexpectedly loop hanging

Alexandru Ionut Diaconescu
Hello Duncan,

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


On Tue, May 28, 2013 at 5:47 PM, Duncan Sands <[hidden email]> wrote:
Hi Alexandru, did you build LLVM with assertions enabled?  If not then you
should do.

Ciao, Duncan.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



--
Best regards,
Alexandru Ionut Diaconescu

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: unexpectedly loop hanging

Alexandru Ionut Diaconescu
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();



I receive a memory corruption error at some basic blocks. Here are the debug outputs:

1. opt - opt: malloc.c:3801: _int_malloc: Assertion `(unsigned long)(size) >= (unsigned long)(nb)' failed.

2. gdb -
Program received signal SIGABRT, Aborted.
0xb7fdd424 in __kernel_vsyscall ()


3. valgrind - it executes all the code and at the problematic loop iteration I have :

==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)


and repeating.

==5230== HEAP SUMMARY:
==5230==     in use at exit: 95,110 bytes in 317 blocks
==5230==   total heap usage: 33,395 allocs, 33,078 frees, 4,484,753 bytes allocated
==5230==
==5230== LEAK SUMMARY:
==5230==    definitely lost: 7,732 bytes in 31 blocks
==5230==    indirectly lost: 85,864 bytes in 275 blocks
==5230==      possibly lost: 0 bytes in 0 blocks
==5230==    still reachable: 1,514 bytes in 11 blocks
==5230==         suppressed: 0 bytes in 0 blocks
==5230== Rerun with --leak-check=full to see details of leaked memory
==5230==
==5230== For counts of detected and suppressed errors, rerun with: -v
==5230== ERROR SUMMARY: 16432 errors from 15 contexts (suppressed: 0 from 0)


I assume the main problems are:
1. I don't allocate well memory for values. Or maybe I am allocating only for Value* pointers, not for the actual values. Maybe I don't free the mem.
2. I cannot use array instead of vector, since is->setMetadata("path",MDNode::get(C,values)); won't let me.

What do you think it is wrong? What should I try? I want only to attach some integers as metadata, one integer per operand.

Thank you !



On Wed, May 29, 2013 at 10:00 AM, Alexandru Ionut Diaconescu <[hidden email]> wrote:
Hello Duncan,

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


On Tue, May 28, 2013 at 5:47 PM, Duncan Sands <[hidden email]> wrote:
Hi Alexandru, did you build LLVM with assertions enabled?  If not then you
should do.

Ciao, Duncan.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



--
Best regards,
Alexandru Ionut Diaconescu



--
Best regards,
Alexandru Ionut Diaconescu

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: unexpectedly loop hanging

Duncan Sands
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.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: unexpectedly loop hanging

Alexandru Ionut Diaconescu
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?


On Thu, May 30, 2013 at 1:57 PM, Duncan Sands <[hidden email]> wrote:
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.




--
Best regards,
Alexandru Ionut Diaconescu

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: unexpectedly loop hanging

Duncan Sands
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.

On 30/05/13 14:21, Alexandru Ionut Diaconescu wrote:

> 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?
>
>
> On Thu, May 30, 2013 at 1:57 PM, Duncan Sands <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     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.
>
>
>
>
> --
> Best regards,
> Alexandru Ionut Diaconescu

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: unexpectedly loop hanging

Alexandru Ionut Diaconescu
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 !





On Thu, May 30, 2013 at 3:05 PM, Duncan Sands <[hidden email]> wrote:
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.


On 30/05/13 14:21, Alexandru Ionut Diaconescu wrote:
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?


On Thu, May 30, 2013 at 1:57 PM, Duncan Sands <[hidden email]
<mailto:[hidden email]>> wrote:

    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.




--
Best regards,
Alexandru Ionut Diaconescu




--
Best regards,
Alexandru Ionut Diaconescu

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev