Menu
▾
▴
valgrind-users
|
From: yoma s. <sop...@gm...> - 2015-11-23 15:18:37
Attachments:
massif.out.5744
test.c
|
hi all:
I have some questions about massif:
1. from massif.out file, I cannot tell where the free is called
I compile the sample code in the document page as below and get
the massif output. From the log, there are messages about where
"malloc" is called, but I cannot find the place for "free".
is there any option I need to add when using massif tool or config
I need to add when compile the valgrind?
( in the smple I attach, the line#28 is where "free" is called, but
there is no such information in the massif output)
2. there is a option call "--trace-children=yes" to capture all
children information.
is it possible to limit the specific child name for tracking?
if possile, should I use some other valgrind execution options or
modify the source code?
appreciate all your kind help in advance,
|
|
From: Azat K. <a3a...@gm...> - 2015-11-23 15:33:28
|
On Mon, Nov 23, 2015 at 11:18:29PM +0800, yoma sophian wrote:
> 2. there is a option call "--trace-children=yes" to capture all
> children information.
> is it possible to limit the specific child name for tracking?
> if possile, should I use some other valgrind execution options or
> modify the source code?
>From valgrind(1):
...
--trace-children-skip=patt1,patt2..
...
--trace-children-skip-by-arg=patt1,patt2..
...
|
|
From: yoma s. <sop...@gm...> - 2015-11-24 05:16:19
|
hi Azat: 2015-11-23 23:33 GMT+08:00 Azat Khuzhin <a3a...@gm...>: > On Mon, Nov 23, 2015 at 11:18:29PM +0800, yoma sophian wrote: >> 2. there is a option call "--trace-children=yes" to capture all >> children information. >> is it possible to limit the specific child name for tracking? >> if possile, should I use some other valgrind execution options or >> modify the source code? > > From valgrind(1): > ... > --trace-children-skip=patt1,patt2.. > ... > --trace-children-skip-by-arg=patt1,patt2.. > ... BTW, is there any other option that we can focus on some specific child? Thanks for your kind help ^^ |
|
From: Philippe W. <phi...@sk...> - 2015-11-24 21:08:52
|
On Mon, 2015-11-23 at 23:18 +0800, yoma sophian wrote: > hi all: > I have some questions about massif: > 1. from massif.out file, I cannot tell where the free is called > I compile the sample code in the document page as below and get > the massif output. From the log, there are messages about where > "malloc" is called, but I cannot find the place for "free". > is there any option I need to add when using massif tool or config > I need to add when compile the valgrind? > ( in the smple I attach, the line#28 is where "free" is called, but > there is no such information in the massif output) massif does not provide information about where memory was freed. It shows the memory used by your program, and where it was allocated. For what reason do you want to know where some memory was freed ? > appreciate all your kind help in advance, You are welcome. Note that such type of questions is well suited on valgrind-users. valgrind-developers is more used for questions about valgrind development itself. So, no need to send the question on both mailing lists. Philippe |
|
From: yoma s. <sop...@gm...> - 2015-11-25 05:32:40
|
hi philippe > massif does not provide information about where memory was freed. > It shows the memory used by your program, and where it was allocated. > > For what reason do you want to know where some memory was freed ? if there is no free information output by massif, how could massif-visualizer show the heap memory usage decreased with thinner color bar if some function call free? (take the web side sample for example, the color of main in massif-visualizer will get thinner at the end of UI output) I cannot see any free information in the ms_print > You are welcome. Note that such type of questions is well suited > on valgrind-users. valgrind-developers is more used for questions > about valgrind development itself. So, no need to send the question > on both mailing lists. Originally I thought maybe my question may nedd to modify source or compile option. Sorry for sending to 2 mailing lists ^^ BTW, I found the massif output seems only created when program exit. is there any option or some modifification for valgrind to generate massif.out in a period of time or by specific event, such as user add special code in program or press specia button, etc? Since I am using valgrind to profile a daemon heap usage when it runing before and after some specific function, but that mean I have to kill the daemon before and after running function. And that is quite inconvinent. thanks for your kind help, |
|
From: Philippe W. <phi...@sk...> - 2015-11-25 20:35:42
|
On Wed, 2015-11-25 at 13:32 +0800, yoma sophian wrote: > hi philippe > > > massif does not provide information about where memory was freed. > > It shows the memory used by your program, and where it was allocated. > > > > For what reason do you want to know where some memory was freed ? > if there is no free information output by massif, how could > massif-visualizer show the heap memory usage decreased with thinner > color bar if some function call free? > (take the web side sample for example, the color of main in > massif-visualizer will get thinner at the end of UI output) > I cannot see any free information in the ms_print I do not know to what color bar you refer, but I guess that the decrease of memory is detected by comparing 2 successive snapshots. Massif records the stack trace of each malloc, and for each such stacktrace, maintains the memory (still) allocated by this stack trace. In other words, massif observes the free calls to decrease the memory allocated by a stacktrace, but massif does not record the stacktraces that are calling free, and does not maintain stats about such 'free stacktraces'. Maybe you could explain why you need to have the free stacktraces ? This might maybe point at other tools (memcheck ? callgrind ? dhat ?) that will help to achieve what you need/want. > > > You are welcome. Note that such type of questions is well suited > > on valgrind-users. valgrind-developers is more used for questions > > about valgrind development itself. So, no need to send the question > > on both mailing lists. > > Originally I thought maybe my question may nedd to modify source or > compile option. > Sorry for sending to 2 mailing lists ^^ > > BTW, I found the massif output seems only created when program exit. > > is there any option or some modifification for valgrind to generate > massif.out in a period of time or by specific event, such as user add > special code in program or press specia button, etc? > Since I am using valgrind to profile a daemon heap usage when it > runing before and after some specific function, but > that mean I have to kill the daemon before and after running function. > And that is quite inconvinent. You can trigger massif snaphots, using massif monitor commands either: * from the shell, using vgdb * from gdb, using gdb+vgdb * from your program, using the client request VALGRIND_MONITOR_COMMAND(command) See http://www.valgrind.org/docs/manual/ms-manual.html#ms-manual.monitor-commands for the list of massif monitor commands. Philippe |
|
From: Philippe W. <phi...@sk...> - 2015-12-06 23:03:49
|
On Mon, 2015-12-07 at 00:08 +0800, yoma sophian wrote:
> I attach the pic, massif_test.png I got from massif-visualizer, and in
> the pic, the heap allocated by main will decreased to 0.
> But f and g these 2 functions will not.
> What makes me curious is I cannot find the free information in the
> massis output ascii file.
There is no free information in the massif outputs.
massif only produces a sequence of snaphots, each snapshot gives
the memory still allocated at the snapshot time.
The memory allocated by main returns to 0, because all the memory
allocated by main is freed. The graph effectively shows the absolute
value of the memory allocated at the snapshot time.
massif does not record the free stacktraces, it only records how
much memory is allocated by a stacktrace (and this amount decreases
when free is called).
So, in summary:
* massif does *not* record 'free' stacktraces
* massif *only* record 'malloc' stacktraces
* massif maintains the memory allocated by a stacktrace
this amount is decreased when free is called.
So, do not expect to find some details about free stacktraces, as these
are not recorded.
> BTW, I have some questions about --pages-as-heap=yes
> I purposely write a program, mmap.c, that will map the file into the memory
> But from ms_print of mmap.c, mmap_4440, I cannot see the location of
> mmap I put in the c file.
> (I attach the c file and mass output as well)
> Shall we add more options to see the location of mmap in the program
> when enable --pages-as-heap=yes?
The stack is only output for detailed snaphots. I believe that no
detailed snapshot is taken between the mmap and the munmap.
I think there is a bug in the massif logic to make a peak detailed
snapshot at the moment of munmap: it should try to produce a peak
snapshot when releasing the first page of munmap, not when releasing
the last page.
Philippe
|
|
From: yoma s. <sop...@gm...> - 2015-12-07 03:49:20
|
hi Philippe:
> There is no free information in the massif outputs.
> massif only produces a sequence of snaphots, each snapshot gives
> the memory still allocated at the snapshot time.
>
> The memory allocated by main returns to 0, because all the memory
> allocated by main is freed. The graph effectively shows the absolute
> value of the memory allocated at the snapshot time.
> massif does not record the free stacktraces, it only records how
> much memory is allocated by a stacktrace (and this amount decreases
> when free is called).
>
> So, in summary:
> * massif does *not* record 'free' stacktraces
> * massif *only* record 'malloc' stacktraces
> * massif maintains the memory allocated by a stacktrace
> this amount is decreased when free is called.
>
> So, do not expect to find some details about free stacktraces, as these
> are not recorded.
Thanks for your kind explination ^^
>
> I think there is a bug in the massif logic to make a peak detailed
> snapshot at the moment of munmap: it should try to produce a peak
> snapshot when releasing the first page of munmap, not when releasing
> the last page.
I use vgdb and try to create snapshop with command, "monitor
detailed_snapshot xxx"
No matter I create snapshop before mmap or after mmap, I hightlight in
the below program, there is still no mmap information in the detail
snapshop file.
It seems the mmap is not recorded by massif even I manual trigger the snapshop.
If I miss anything or do any wrong experiment, please let me know.
appreciate your kind help,
f();
g();
/****break Here*****/
p = mmap (0, sb.st_size, PROT_READ, MAP_SHARED, fd, 0);
if (p == MAP_FAILED) {
/****break Here*****/
perror ("mmap");
return 1;
}
|
|
From: Philippe W. <phi...@sk...> - 2015-12-07 21:46:33
|
On Mon, 2015-12-07 at 11:49 +0800, yoma sophian wrote: > I use vgdb and try to create snapshop with command, "monitor > detailed_snapshot xxx" > No matter I create snapshop before mmap or after mmap, I hightlight in > the below program, there is still no mmap information in the detail > snapshop file. > It seems the mmap is not recorded by massif even I manual trigger the snapshop. > If I miss anything or do any wrong experiment, please let me know. The mmap is probably below the massif threshold, and so is not shown. Either mmap more memory or decrease the massif --threshold value. Philippe |
|
From: Philippe W. <phi...@sk...> - 2015-12-10 22:41:14
|
On Mon, 2015-12-07 at 00:05 +0100, Philippe Waroquiers wrote: > I think there is a bug in the massif logic to make a peak detailed > snapshot at the moment of munmap: it should try to produce a peak > snapshot when releasing the first page of munmap, not when releasing > the last page. revision 15745 introduces a test for this case, and fixes the bug. Philippe |
|
From: yoma s. <sop...@gm...> - 2015-12-11 13:02:05
|
hi Phillippe: 2015-12-11 6:42 GMT+08:00 Philippe Waroquiers <phi...@sk...>: > On Mon, 2015-12-07 at 00:05 +0100, Philippe Waroquiers wrote: >> I think there is a bug in the massif logic to make a peak detailed >> snapshot at the moment of munmap: it should try to produce a peak >> snapshot when releasing the first page of munmap, not when releasing >> the last page. > revision 15745 introduces a test for this case, and fixes the bug. I checkout 15745 and compile. but I bump into below error message valgrind.git# ./autogen.sh running: aclocal running: autoheader running: automake -a Makefile.am:21: error: required directory ./VEX does not exist error: while running 'automake -a' valgrind.git# Did I miss anything? thanks for your kind help, |
|
From: Ivo R. <iv...@iv...> - 2015-12-11 14:57:33
|
2015-12-11 14:01 GMT+01:00 yoma sophian <sop...@gm...>: > hi Phillippe: > > 2015-12-11 6:42 GMT+08:00 Philippe Waroquiers < > phi...@sk...>: > > On Mon, 2015-12-07 at 00:05 +0100, Philippe Waroquiers wrote: > >> I think there is a bug in the massif logic to make a peak detailed > >> snapshot at the moment of munmap: it should try to produce a peak > >> snapshot when releasing the first page of munmap, not when releasing > >> the last page. > > revision 15745 introduces a test for this case, and fixes the bug. > > I checkout 15745 and compile. > but I bump into below error message > > valgrind.git# ./autogen.sh > running: aclocal > running: autoheader > running: automake -a > Makefile.am:21: error: required directory ./VEX does not exist > Why valgrind.git? Valgrind is versioned in SVN. Anyway, it seems your source tree is incomplete and you did not get an external repo 'VEX'. See http://valgrind.org/downloads/repository.html I, |
|
From: yoma s. <sop...@gm...> - 2015-12-11 15:00:17
|
hi Ivo: 2015-12-11 22:57 GMT+08:00 Ivo Raisr <iv...@iv...>: > > > 2015-12-11 14:01 GMT+01:00 yoma sophian <sop...@gm...>: >> >> hi Phillippe: >> >> 2015-12-11 6:42 GMT+08:00 Philippe Waroquiers >> <phi...@sk...>: >> > On Mon, 2015-12-07 at 00:05 +0100, Philippe Waroquiers wrote: >> >> I think there is a bug in the massif logic to make a peak detailed >> >> snapshot at the moment of munmap: it should try to produce a peak >> >> snapshot when releasing the first page of munmap, not when releasing >> >> the last page. >> > revision 15745 introduces a test for this case, and fixes the bug. >> >> I checkout 15745 and compile. >> but I bump into below error message >> >> valgrind.git# ./autogen.sh >> running: aclocal >> running: autoheader >> running: automake -a >> Makefile.am:21: error: required directory ./VEX does not exist > > > Why valgrind.git? Valgrind is versioned in SVN. > Anyway, it seems your source tree is incomplete and you did not get > an external repo 'VEX'. See > http://valgrind.org/downloads/repository.html I use git svn instruction for getting the repository. it should be no differneces with git svn command. Anyway, I will use svn command to redo again. thanks for your kind remind, |
|
From: yoma s. <sop...@gm...> - 2015-12-13 12:43:20
|
> I use git svn instruction for getting the repository. > it should be no differneces with git svn command. > Anyway, I will use svn command to redo again. hi ivo: after I use svn instead of git svn, I can successfully compile valgrind trunk. it seems git svn not handle external link ^^ >>> >> I think there is a bug in the massif logic to make a peak detailed >>> >> snapshot at the moment of munmap: it should try to produce a peak >>> >> snapshot when releasing the first page of munmap, not when releasing >>> >> the last page. >>> > revision 15745 introduces a test for this case, and fixes the bug. hi Philippe: I compile the trunk valgrind with ur patch, but I still cannot see the location of mmap I put in the c file, even I set the --threshold=0.0. (I attach the c file and mass output as well) BTW, would you please let me know how to compile and run the programs in massif/tests? appreciate all your kind help, |
|
From: Philippe W. <phi...@sk...> - 2015-12-13 13:35:12
|
On Sun, 2015-12-13 at 20:43 +0800, yoma sophian wrote: > hi Philippe: > I compile the trunk valgrind with ur patch, but I still cannot see the > location of mmap I put in the c file, even I set the --threshold=0.0. > (I attach the c file and mass output as well) --threshold indicates the threshold below which massif does not show the details of the memory. Details will be shown in 2 different kinds of snapshots: * peak snapshots * detailed snapshots In your case, I guess that the file you are mmap-ing is too small to be the peak, and you do not have a detailed snaphot being taken between the mmap and the munmap. E.g. try to mmap a much bigger file, to ensure that the peak is reached by the mmap you are doing, and not any other operations. > BTW, would you please let me know how to compile and run the programs > in massif/tests? in valgrind top directory, to compile/install locally and run all regtests: ./configure --prefix=`pwd`/Inst make install make regtest Philippe |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X