|
From: Hien Le <Hi...@me...> - 2010-05-20 18:17:36
|
> > Hi all, > > I am having an issue with callgrind tool. > I am using the valgrind --version: *valgrind-3.1.1* in 32 bit red-hat Linux > environment. > > My program is basically document analyzer. What it does is, process the > input document and give the result. > I just want to analyze my program with callgrind (purpose is to reduce the > "new" operator calls). > > The callgrind tool is perfect for it, with small number of documents, but it > is giving problems with large number of documents. > > For example, the callgrind output is OK for around 200 documents. But I want > to do the same analyzes with more than 1000 documents. In that case the > callgrind report most of the functions as "*cycle*" even the *new *and *malloc > *calls. > *operator new <cycle 2> > malloc <cycle 2> > free <cycle 2>* > > [image: sample callgrind outpu.png] > > And also it does not show the call flows correctly. > This can not happen due to an error in my program, Because it still (even > after 1000 documents) work perfectly with giving the expected outputs. > > What could be the reason for this....?? Is this due to the large number of > calls (exceeding the supported maximum numeric limits ). > > The following data may be help to identify the issue. > > For 200 documents > - new operator has called 31,452,352 > - malloc has called 31,468,098. > > For around 1000 documents the > - new operator has called 1,003,897,109 > - malloc has called 1,004,566,498 > This section of the manual provides more details on what you are seeing: http://valgrind.org/docs/manual/cl-manual.html#cl-manual.cycles |
|
From: R. P. J. <rpj...@gm...> - 2010-06-03 10:50:40
|
Yeah, I checked the manual for avoiding cycle. But my question is, if it is due to recursive calls, how does it work for small number of data set. And also why does it point it the "*new*" call as a cycle (as I know new should never go in a cycle) On Thu, May 20, 2010 at 11:47 PM, Hien Le <Hi...@me...> wrote: > > > > Hi all, > > > > I am having an issue with callgrind tool. > > I am using the valgrind --version: *valgrind-3.1.1* in 32 bit red-hat > Linux > > environment. > > > > My program is basically document analyzer. What it does is, process the > > input document and give the result. > > I just want to analyze my program with callgrind (purpose is to reduce > the > > "new" operator calls). > > > > The callgrind tool is perfect for it, with small number of documents, but > it > > is giving problems with large number of documents. > > > > For example, the callgrind output is OK for around 200 documents. But I > want > > to do the same analyzes with more than 1000 documents. In that case the > > callgrind report most of the functions as "*cycle*" even the *new *and > *malloc > > *calls. > > *operator new <cycle 2> > > malloc <cycle 2> > > free <cycle 2>* > > > > [image: sample callgrind outpu.png] > > > > And also it does not show the call flows correctly. > > This can not happen due to an error in my program, Because it still (even > > after 1000 documents) work perfectly with giving the expected outputs. > > > > What could be the reason for this....?? Is this due to the large number > of > > calls (exceeding the supported maximum numeric limits ). > > > > The following data may be help to identify the issue. > > > > For 200 documents > > - new operator has called 31,452,352 > > - malloc has called 31,468,098. > > > > For around 1000 documents the > > - new operator has called 1,003,897,109 > > - malloc has called 1,004,566,498 > > > > > This section of the manual provides more details on what you are seeing: > http://valgrind.org/docs/manual/cl-manual.html#cl-manual.cycles > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > -- Regards, R. P. Janaka |
|
From: R. P. J. <rpj...@gm...> - 2010-06-04 10:49:13
|
As mentioned in the manual, I was able to avoid this by using the* ** --separate-recs=10* . But I am still wondering why we get cycle for new or malloc (because they should never call recursively ) On Thu, Jun 3, 2010 at 4:20 PM, R. P. Janaka <rpj...@gm...> wrote: > Yeah, I checked the manual for avoiding cycle. > > But my question is, if it is due to recursive calls, how does it work for > small number of data set. > And also why does it point it the "*new*" call as a cycle (as I know new > should never go in a cycle) > > > > On Thu, May 20, 2010 at 11:47 PM, Hien Le <Hi...@me...> wrote: > >> > >> > Hi all, >> > >> > I am having an issue with callgrind tool. >> > I am using the valgrind --version: *valgrind-3.1.1* in 32 bit red-hat >> Linux >> > environment. >> > >> > My program is basically document analyzer. What it does is, process the >> > input document and give the result. >> > I just want to analyze my program with callgrind (purpose is to reduce >> the >> > "new" operator calls). >> > >> > The callgrind tool is perfect for it, with small number of documents, >> but it >> > is giving problems with large number of documents. >> > >> > For example, the callgrind output is OK for around 200 documents. But I >> want >> > to do the same analyzes with more than 1000 documents. In that case the >> > callgrind report most of the functions as "*cycle*" even the *new *and >> *malloc >> > *calls. >> > *operator new <cycle 2> >> > malloc <cycle 2> >> > free <cycle 2>* >> > >> > [image: sample callgrind outpu.png] >> > >> > And also it does not show the call flows correctly. >> > This can not happen due to an error in my program, Because it still >> (even >> > after 1000 documents) work perfectly with giving the expected outputs. >> > >> > What could be the reason for this....?? Is this due to the large number >> of >> > calls (exceeding the supported maximum numeric limits ). >> > >> > The following data may be help to identify the issue. >> > >> > For 200 documents >> > - new operator has called 31,452,352 >> > - malloc has called 31,468,098. >> > >> > For around 1000 documents the >> > - new operator has called 1,003,897,109 >> > - malloc has called 1,004,566,498 >> > >> >> >> This section of the manual provides more details on what you are seeing: >> http://valgrind.org/docs/manual/cl-manual.html#cl-manual.cycles >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Valgrind-users mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-users >> > > > > -- > Regards, > R. P. Janaka > -- Regards, R. P. Janaka |
|
From: Josef W. <Jos...@gm...> - 2010-06-06 20:33:02
|
On Friday 04 June 2010, R. P. Janaka wrote: > As mentioned in the manual, I was able to avoid this by using the* ** > --separate-recs=10* . > But I am still wondering why we get cycle for new or malloc (because they > should never call recursively ) Probably not a direct cycle, but a false one. It could be (just guessing): - malloc needs the runtime linker on first call - the runtime linker sometimes needs malloc Anyway, by traversing direct callees residing in the cycle function, you should be able to find a cyclic call chain yourself. Josef |