|
From: Lin Andy-A. <A2...@mo...> - 2007-11-15 07:20:59
|
Spacetime is not accurate sometime?
I wrote a test case as below.
If we used "malloc(100)" in line 9, the massif think that this line
occupied a large part of space time.=20
While we changed the line to malloc(1), the massif think malloc(64) in
line 4 occupied most of the spacetime.
In my view, malloc(100)'s life time is very short, so its spacetime
should be small, but it seems that malloc(100)'s life start time is
start after malloc(64)in line 4.Why is it designed as that? Anyone know
the reason?
1 int main(int argc, char *argv[])
2 {
3 char *pTest =3D NULL;
4 malloc(64);=20
5 =20
6 //sleep 10 second, in my view, malloc(64) will get a
large space*time.
7 sleep(10);
8 malloc(200);
9 pTest=3D (char *) malloc(100);
10 if(pTest !=3D NULL)
11 {
12 free(pTest);
13 }
14 printf("\nEnd\n");
15 }
=20
Thank you very much
Regards
Andy
|
|
From: Nicholas N. <nj...@cs...> - 2007-11-15 11:10:14
|
On Thu, 15 Nov 2007, Lin Andy-A22318 wrote: > Spacetime is not accurate sometime? I recently completely rewrote Massif. It no longer uses spacetime as a unit; rather it measures space at various times during the execution. You can try it by checking out the trunk from the SVN repository. I'd be interested to hear any feedback you may have. N |
|
From: Lin Andy-A. <A2...@mo...> - 2007-11-23 03:32:09
|
> From: Nicholas Nethercote [mailto:nj...@cs...]=20
> Sent: 2007=C4=EA11=D4=C215=C8=D5 19:10
> To: Lin Andy-A22318
> Cc: val...@li...
> Subject: Re: [Valgrind-users] spacetime is seriously inaccurate =
sometime?
> I recently completely rewrote Massif. It no longer uses spacetime =
as a unit; rather it measures space at various times during the =
execution.
> =20
> You can try it by checking out the trunk from the SVN repository. =
I'd be interested to hear any feedback you may have.
=20
I tried the new massif.
It provides you more useful and accurate information althrough the UI is =
not so good as the old massif.
Some suggestions/questions from user view
1>Can we development an interaction massif tool based on the new =
version?
when test programme is running, we can dump the memeory =
information(maybe through another process)
or such as gdb, we can break the programme somewhere, and then we =
can show the memory information.
2>Although there is time information in the output, we don't know where =
it is for one snapshot.
Can we dump the call stack for each snapshot? If so, we can get more =
useful information from it.
Regards. =20
|
|
From: Nicholas N. <nj...@cs...> - 2007-11-23 05:06:22
|
On Fri, 23 Nov 2007, Lin Andy-A22318 wrote: > I tried the new massif. It provides you more useful and accurate > information althrough the UI is not so good as the old massif. It's certainly not as pretty, but I think the presentation of information is better. Can you explain more about how you think it is worse than the old UI? > Some suggestions/questions from user view > 1>Can we development an interaction massif tool based on the new version? > when test programme is running, we can dump the memeory information(maybe through another process) > or such as gdb, we can break the programme somewhere, and then we can show the memory information. That would be possible, but it would be a lot of work. > 2>Although there is time information in the output, we don't know where it is for one snapshot. > Can we dump the call stack for each snapshot? If so, we can get more useful information from it. What would that useful information be? I can't see myself how a stack trace would be useful, but I may be overlooking something. Thanks for the feedback. Nick |
|
From: Lin Andy-A. <A2...@mo...> - 2007-11-23 06:24:54
|
>-----Original Message-----
>From: Nicholas Nethercote [mailto:nj...@cs...]=20
>Sent: 2007=C4=EA11=D4=C223=C8=D5 13:06
>To: Lin Andy-A22318
>Cc: val...@li...
>Subject: RE: [Valgrind-users] spacetime is seriously inaccurate =
sometime?
>
>On Fri, 23 Nov 2007, Lin Andy-A22318 wrote:
>
>> I tried the new massif. It provides you more useful and accurate=20
>> information althrough the UI is not so good as the old massif.
>
>It's certainly not as pretty, but I think the presentation of =
information is better. Can you explain more about how you think it >is =
worse than the old UI?
I just mean that the picture is not so colorful and direct as the old =
one:-)
You are right, the presentation is better from user view. It is =
important that we can get the useful information, not the some =
misunderstanding UI :-)
>
>> Some suggestions/questions from user view
>> 1>Can we development an interaction massif tool based on the new =
version?
> when test programme is running, we can dump the memeory =
information(maybe through another process)
>>> or such as gdb, we can break the programme somewhere, and then we =
can show the memory information.
>
>That would be possible, but it would be a lot of work.
If gdb-similar massif come out, it is great and we can resove memory =
issue easily:-)
>> 2>Although there is time information in the output, we don't know =
where it is for one snapshot.
>> Can we dump the call stack for each snapshot? If so, we can get =
more useful information from it.
>
>What would that useful information be? I can't see myself how a stack =
trace would be useful, but I may be overlooking something.
>From my understanding, the time (such as 133ms) can't express where the =
programmle is running.=20
But if we know the snapshot call stack, more possibely, we know where it =
is executing and it can help us to confirm which part caused memory to =
be allocated.
Below is an example:
For below output:
MB
1.998^ =20
| . @@: @@@#
| @: @@: @@@#
| .@: @@: @@@#
| . @@: @@: @@@#
| @ @@: @@: @@@#
| @ @@: @@: @@@#
| .@ @@: @@: @@@#
| @@ @@: @@: @@@#
| ... @. @ @::@ :@@ @@: @@: @@@#
| .. .. @:@ :@@ :@ :@@ @: @ @::@ :@@ @@: @@: @@@#
| .::@: :@ :: @:@ :@@ :@ :@@ @: @ @::@ :@@ @@: @@: @@@#
| : :::@: :@ :: @:@ :@@ :@ :@@ @: @ @::@ :@@ @@: @@: @@@#
0 +--------@---@----@-@--@@--@--@@-@--@-@--@--@@-@@--@@--@@@#s
0 S X W 27.83
Main()
{
func1()
func2()
func3()
...
funcN()
}
If we know:
S(see the graph x-axis) snapshot is located in func1() in main()
X(see the graph x-axis) snapshot is located in func2() in main()
W(see the graph x-axis) snapshot is also located in func2() in main()
we know that we should pay more attention to func2, not func1 for memory =
allocated.
Maybe we can get some of the information from the current output, but it =
is not easy and even can't get it sometimes.
Thanks
Andy
|
|
From: Lin Andy-A. <A2...@mo...> - 2007-11-20 03:28:42
|
In my understanding, the context accounted percentage should equal or
greater that the sum percentage of it's called.
For below example, 4.4% is a little greater than 3.2%+0.9%.
---------------------------------
Context accounted for 4.4% of measured spacetime
0x4275E64: std::string::_Rep::_S_create(unsigned, unsigned,
std::allocator const&) (in /usr/lib/libstdc++.so.6.0.3)
Called from:
* 3.2%: 0x4278884: (within /usr/lib/libstdc++.so.6.0.3)
* 0.9%: 0x4275EFF: std::string::_Rep::_M_clone(std::allocator
const&, unsigned) (in /usr/lib/libstdc++.so.6.0.3)
* and 2 other insignificant places
But sometimes, we can't get the conclusion.
For below case, 24.9% is less than 40.4%+18.4%.
In fact, moveToChild only called sqlite3GenericMalloc to get memory.What
does 40.4% mean?
Is it incorrect?
---------------------------------
Context accounted for 24.9% of measured spacetime
0x416059C: sqlite3GenericMalloc (os_common.h:177)
0x4160026: sqlite3MallocRaw (malloc.c:592)
0x41647B7: sqlite3PagerAcquire (pager.c:3012)
0x4143BEB: sqlite3BtreeGetPage (btree.c:937)
0x4143C8A: getAndInitPage (btree.c:964)
Called from:
* 40.4%: 0x414557F: moveToChild (btree.c:2951)
* 18.4%: 0x414588F: sqlite3BtreeCursor (btree.c:2391)=20
Anyone can help me on it, thank in advance.
Regards=20
Andy Lin
|
|
From: Nicholas N. <nj...@cs...> - 2007-11-20 06:37:21
|
On Tue, 20 Nov 2007, Lin Andy-A22318 wrote: > But sometimes, we can't get the conclusion. > For below case, 24.9% is less than 40.4%+18.4%. > In fact, moveToChild only called sqlite3GenericMalloc to get memory.What > does 40.4% mean? > Is it incorrect? > --------------------------------- > Context accounted for 24.9% of measured spacetime > 0x416059C: sqlite3GenericMalloc (os_common.h:177) > 0x4160026: sqlite3MallocRaw (malloc.c:592) > 0x41647B7: sqlite3PagerAcquire (pager.c:3012) > 0x4143BEB: sqlite3BtreeGetPage (btree.c:937) > 0x4143C8A: getAndInitPage (btree.c:964) > Called from: > * 40.4%: 0x414557F: moveToChild (btree.c:2951) > * 18.4%: 0x414588F: sqlite3BtreeCursor (btree.c:2391) I believe it's a bug. Massif has recently been extensively rewritten. The new version should be more reliable than the old one, but its output is different (but hopefully more useful). It will be in Valgrind 3.3.0, but for the moment you can check it out from the SVN trunk. Nick |