You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
1
(1) |
2
(8) |
3
(9) |
4
(6) |
5
(13) |
6
(18) |
7
(2) |
|
8
(1) |
9
(6) |
10
(4) |
11
(6) |
12
(11) |
13
(3) |
14
|
|
15
(4) |
16
(5) |
17
(11) |
18
(3) |
19
(31) |
20
(2) |
21
(5) |
|
22
(3) |
23
(4) |
24
(1) |
25
(4) |
26
(7) |
27
(2) |
28
(6) |
|
29
(2) |
30
(2) |
31
(4) |
|
|
|
|
|
From: Jeroen N. W. <jn...@xs...> - 2005-05-12 15:08:38
|
> On Thu, 12 May 2005, Dennis Lubert wrote: > >>> Is there something else that I am missing ? >> >> In the newest GCC Versions its GLIBCXX_FORCE_NEW not GLIBCPP_FORCE_NEW > > I've updated the FAQ, thanks for the info :) > Unfortunately, the gcc version number in the updates seems incorrect. From the original post: At 12:40 12.05.2005, mma...@ny... wrote: >Hello, > > I am working on a debian testing with gcc-snapshot (sudo apt-get >install gcc-snapshot). Which is currently a gcc 4.1. I am getting this >kind of error (*), eventhough my command line is: > From the patch: +- With gcc 3.4 and later, that variable has changed name to + GLIBCXX_FORCE_NEW. Regards, Jeroen. |
|
From: Nicholas N. <nj...@cs...> - 2005-05-12 14:46:54
|
On Thu, 12 May 2005, Josef Weidendorfer wrote: > But perhaps it is best to call it CG-format (for cachegrind or callgrind), and > thus call the converter "op2cg". I'd call it the "callgrind format". Cachegrind's cg_annotate script cannot read that format, so it seems useful to preserve the distinction between "cachegrind format" and "callgrind format". But I guess it's up to you, Josef. N |
|
From: Josef W. <Jos...@gm...> - 2005-05-12 14:40:21
|
On Wednesday 11 May 2005 22:23, Harry Mangalam wrote: > Answering my own post - > it's called op2calltree in the converters subdir of kcachegrind > ^^^^ > a leftover from when callgrind was called calltree. Hi, the "calltree" in "op2calltree" refers to the format, which is called by the tool which first generated the format, which was calltree. So there is not really a connection between this converter script and callgrind. I did not want to call it "cachegrind" format, as it contains a few extensions. As this format is created by cachegrind, calltree, callgrind, and now even cover, we could search for another name. Ideas? It is more or less simply a ASCII format to relate tuples of 64bit-integers to source positions. As it is used in the context of an executed program, it contains profile information. But perhaps it is best to call it CG-format (for cachegrind or callgrind), and thus call the converter "op2cg". Josef > > Sorry for the noise. > hjm > > > > Harry Mangalam wrote: (before looking arefully..) > > > The KCachegrind docs refer to an app called "op2callgrind" to tranlating > > oprofile information to data compatible with kcachegrind. I've not been > > able to find it via google and it does not appear to be in the oprofile > > source tree, nor the callgrind source tree nor the kcachegrind source > > tree. > > Did I miss something? Does anyone have any further info on it? > > > > > > <quote> > > System wide profiling is only permitted to the root user, as all actions > > on the system can be observed. Therefore, the following has to be done as > > root. First, configure the profiling process, using the GUI oprof_start > > or the command line tool opcontrol. Standard configuration should be > > timer mode (TBS, see introduction). To start the measurement, run > > opcontrol -s. Then run the application you are interested in, and > > afterwards, do a opcontrol -d. This will write out the measurement > > results into files under directory /var/lib/oprofile/samples/. To be able > > to visualize the data in KCachegrind, do in an empty directory: > > > > > > opreport -gdf | op2callgrind > > > > This will produce a lot of files, one for every program which was running > > on the system. Each one can be loaded into KCachegrind on its own. > > </quote> > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by Oracle Space Sweepstakes > > Want to be the first software developer in space? > > Enter now for the Oracle Space Sweepstakes! > > http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Nicholas N. <nj...@cs...> - 2005-05-12 13:48:27
|
On Thu, 12 May 2005, Dennis Lubert wrote: >> Is there something else that I am missing ? > > In the newest GCC Versions its GLIBCXX_FORCE_NEW not GLIBCPP_FORCE_NEW I've updated the FAQ, thanks for the info :) N |
|
From: Dennis L. <pla...@in...> - 2005-05-12 12:34:25
|
Am Donnerstag, den 12.05.2005, 12:03 +0100 schrieb Julian Seward: > Can you be clear about what problem in Valgrind this shows up? > On the face of it, you ran a C++ program on Valgrind, and it reported > a memory leak. Well, that's not unusual. As far as I understood him, his question was about why there is still reachable allocated memory, though he tried to force gcc stl allocator to use new instead of memory pools. In 3.x version you could force it with GLIBCPP_FORCE_NEW (as stated by valgrind faq 4.3) to use new instead, so usually all those still reachable messages go away. Now he was wondering why this does not happen any more with gcc 4.x. Its simply because the now use GLIBCXX_FORCE_NEW environment variable. I think the FAQ 4.3 of valgrind should be updated to reflect this change in latest gcc compiler greets Dennis |
|
From: Julian S. <js...@ac...> - 2005-05-12 11:03:56
|
Can you be clear about what problem in Valgrind this shows up? On the face of it, you ran a C++ program on Valgrind, and it reported a memory leak. Well, that's not unusual. J On Thursday 12 May 2005 11:40, mma...@ny... wrote: > Hello, > > I am working on a debian testing with gcc-snapshot (sudo apt-get > install gcc-snapshot). Which is currently a gcc 4.1. I am getting this > kind of error (*), eventhough my command line is: > > > GLIBCPP_FORCE_NEW=1 valgrind --weird-hacks=lax-ioctls > --trace-children=yes -q --tool=memcheck --leak-check=yes > --show-reachable=yes --workaround-gcc296-bugs=yes --num-callers=100 -v > ./foobar > > Is there something else that I am missing ? > > Thanks a bunch, > Mathieu > > (*) > MPK ==27837== 40 bytes in 10 blocks are still reachable in loss record 1 > of 4 > ==27837== at 0x1B906727: operator new(unsigned) > (vg_replace_malloc.c:132) ==27837== by 0x1BAA9CB5: > __gnu_cxx::__pool::_M_initialize(void > (*)(void*)) (in /usr/lib/gcc-snapshot/lib/libstdc++.so.6.0.4) > ==27837== by 0x1BAAB025: (within > /usr/lib/gcc-snapshot/lib/libstdc++.so.6.0.4) > ==27837== by 0x1BAAA8D0: (within > /usr/lib/gcc-snapshot/lib/libstdc++.so.6.0.4) > ==27837== by 0x1BAF7A3E: std::string::_Rep::_S_create(unsigned, > unsigned, std::allocator const&) (in > /usr/lib/gcc-snapshot/lib/libstdc++.so.6.0.4) > ==27837== by 0x1BAFBE69: (within > /usr/lib/gcc-snapshot/lib/libstdc++.so.6.0.4) > ==27837== by 0x1BAFCACE: std::string::string(char const*, > std::allocator const&) (in /usr/lib/gcc-snapshot/lib/libstdc++.so.6.0.4) > ==27837== by 0x1B9A46AF: > __static_initialization_and_destruction_0(int, int) (in > /home/mathieu/Dashboards/MyTests/gdcm-gcc-snaphot/bin/libgdcm.so) > ==27837== by 0x1B9B11C1: (within > /home/mathieu/Dashboards/MyTests/gdcm-gcc-snaphot/bin/libgdcm.so) > ==27837== by 0x1B92D704: (within > /home/mathieu/Dashboards/MyTests/gdcm-gcc-snaphot/bin/libgdcm.so) > ==27837== by 0x1B8F00DD: (within /lib/ld-2.3.2.so) > ==27837== by 0x1B8F01C9: _dl_init (in /lib/ld-2.3.2.so) > ==27837== by 0x1B8E4C5C: (within /lib/ld-2.3.2.so) > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Dennis L. <pla...@in...> - 2005-05-12 11:03:51
|
At 12:40 12.05.2005, mma...@ny... wrote: >Hello, > > I am working on a debian testing with gcc-snapshot (sudo apt-get >install gcc-snapshot). Which is currently a gcc 4.1. I am getting this >kind of error (*), eventhough my command line is: > > >GLIBCPP_FORCE_NEW=1 valgrind --weird-hacks=lax-ioctls >--trace-children=yes -q --tool=memcheck --leak-check=yes >--show-reachable=yes --workaround-gcc296-bugs=yes --num-callers=100 -v >./foobar > >Is there something else that I am missing ? In the newest GCC Versions its GLIBCXX_FORCE_NEW not GLIBCPP_FORCE_NEW Carpe quod tibi datum est |
|
From: <mma...@ny...> - 2005-05-12 10:40:17
|
Hello, I am working on a debian testing with gcc-snapshot (sudo apt-get install gcc-snapshot). Which is currently a gcc 4.1. I am getting this kind of error (*), eventhough my command line is: GLIBCPP_FORCE_NEW=1 valgrind --weird-hacks=lax-ioctls --trace-children=yes -q --tool=memcheck --leak-check=yes --show-reachable=yes --workaround-gcc296-bugs=yes --num-callers=100 -v ./foobar Is there something else that I am missing ? Thanks a bunch, Mathieu (*) MPK ==27837== 40 bytes in 10 blocks are still reachable in loss record 1 of 4 ==27837== at 0x1B906727: operator new(unsigned) (vg_replace_malloc.c:132) ==27837== by 0x1BAA9CB5: __gnu_cxx::__pool::_M_initialize(void (*)(void*)) (in /usr/lib/gcc-snapshot/lib/libstdc++.so.6.0.4) ==27837== by 0x1BAAB025: (within /usr/lib/gcc-snapshot/lib/libstdc++.so.6.0.4) ==27837== by 0x1BAAA8D0: (within /usr/lib/gcc-snapshot/lib/libstdc++.so.6.0.4) ==27837== by 0x1BAF7A3E: std::string::_Rep::_S_create(unsigned, unsigned, std::allocator const&) (in /usr/lib/gcc-snapshot/lib/libstdc++.so.6.0.4) ==27837== by 0x1BAFBE69: (within /usr/lib/gcc-snapshot/lib/libstdc++.so.6.0.4) ==27837== by 0x1BAFCACE: std::string::string(char const*, std::allocator const&) (in /usr/lib/gcc-snapshot/lib/libstdc++.so.6.0.4) ==27837== by 0x1B9A46AF: __static_initialization_and_destruction_0(int, int) (in /home/mathieu/Dashboards/MyTests/gdcm-gcc-snaphot/bin/libgdcm.so) ==27837== by 0x1B9B11C1: (within /home/mathieu/Dashboards/MyTests/gdcm-gcc-snaphot/bin/libgdcm.so) ==27837== by 0x1B92D704: (within /home/mathieu/Dashboards/MyTests/gdcm-gcc-snaphot/bin/libgdcm.so) ==27837== by 0x1B8F00DD: (within /lib/ld-2.3.2.so) ==27837== by 0x1B8F01C9: _dl_init (in /lib/ld-2.3.2.so) ==27837== by 0x1B8E4C5C: (within /lib/ld-2.3.2.so) |
|
From: Harry M. <hj...@ta...> - 2005-05-11 20:25:35
|
Answering my own post -
it's called op2calltree in the converters subdir of kcachegrind
^^^^
a leftover from when callgrind was called calltree.
Sorry for the noise.
hjm
Harry Mangalam wrote: (before looking arefully..)
>
> The KCachegrind docs refer to an app called "op2callgrind" to tranlating
> oprofile information to data compatible with kcachegrind. I've not been
> able to find it via google and it does not appear to be in the oprofile
> source tree, nor the callgrind source tree nor the kcachegrind source
> tree.
> Did I miss something? Does anyone have any further info on it?
>
>
> <quote>
> System wide profiling is only permitted to the root user, as all actions
> on the system can be observed. Therefore, the following has to be done as
> root. First, configure the profiling process, using the GUI oprof_start or
> the command line tool opcontrol. Standard configuration should be timer
> mode (TBS, see introduction). To start the measurement, run opcontrol -s.
> Then run the application you are interested in, and afterwards, do a
> opcontrol -d. This will write out the measurement results into files under
> directory /var/lib/oprofile/samples/. To be able to visualize the data in
> KCachegrind, do in an empty directory:
>
>
> opreport -gdf | op2callgrind
>
> This will produce a lot of files, one for every program which was running
> on the system. Each one can be loaded into KCachegrind on its own.
> </quote>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
|
|
From: Harry M. <hj...@ta...> - 2005-05-11 20:04:14
|
The KCachegrind docs refer to an app called "op2callgrind" to tranlating oprofile information to data compatible with kcachegrind. I've not been able to find it via google and it does not appear to be in the oprofile source tree, nor the callgrind source tree nor the kcachegrind source tree. Did I miss something? Does anyone have any further info on it? <quote> System wide profiling is only permitted to the root user, as all actions on the system can be observed. Therefore, the following has to be done as root. First, configure the profiling process, using the GUI oprof_start or the command line tool opcontrol. Standard configuration should be timer mode (TBS, see introduction). To start the measurement, run opcontrol -s. Then run the application you are interested in, and afterwards, do a opcontrol -d. This will write out the measurement results into files under directory /var/lib/oprofile/samples/. To be able to visualize the data in KCachegrind, do in an empty directory: opreport -gdf | op2callgrind This will produce a lot of files, one for every program which was running on the system. Each one can be loaded into KCachegrind on its own. </quote> |
|
From: Nicholas N. <nj...@cs...> - 2005-05-11 18:41:14
|
On Wed, 11 May 2005, Kevin Tew wrote: > What do these question marks mean? > > ==28358== by 0x1C603785: ??? (Object.cpp:1526 > ==28358== by 0x1C5FFCB1: ??? (Object.cpp:1546) > ==28358== by 0x1C603823: ??? (Object.cpp:808) The function name is unknown. But the file/line number together is enough to pinpoint the lines involved. N |
|
From: Kevin T. <li...@ek...> - 2005-05-11 18:03:15
|
What do these question marks mean? ==28358== by 0x1C603785: ??? (Object.cpp:1526 ==28358== by 0x1C5FFCB1: ??? (Object.cpp:1546) ==28358== by 0x1C603823: ??? (Object.cpp:808) Listman |
|
From: Nicholas N. <nj...@cs...> - 2005-05-11 14:47:02
|
On Wed, 11 May 2005, Stefan Kost wrote: > as the list does not likes big attachments - here they are as links: > > http://www.buzztard.org/files/valgrind-banner.png > http://www.buzztard.org/files/valgrind-banner2.png > http://www.buzztard.org/files/Valgrind.cpt > http://www.buzztard.org/files/Valgrind2.cpt Thanks! These are really nice. I'm sure they'll be added to the website, as soon as someone gets round to it... N |
|
From: Stefan K. <en...@ho...> - 2005-05-11 06:44:21
|
Hi all, as the list does not likes big attachments - here they are as links: http://www.buzztard.org/files/valgrind-banner.png http://www.buzztard.org/files/valgrind-banner2.png http://www.buzztard.org/files/Valgrind.cpt http://www.buzztard.org/files/Valgrind2.cpt Ciao Stefan > hi, > > I'd love to link back to valgrind page. so such a picture would be nice. > Just one comment, most of this images are 88x32 pixels in size. I don't > know why. > If contributor could take that into account - it would be much easier to > add that to the other images ;) > > Ciao > Stefan > -- > http://www.buzztard.org > >> >> Hi, >> >> On the new Valgrind website, we have some pretty artwork, including small >> pictures at www.valgrind.org/gallery/artwork.html. That page suggests >> using those pictures if you want to link to www.valgrind.org. >> Unfortunately, the pictures alone don't tell people very much. What we'd >> really like is versions of those pictures with some text that identifies >> Valgrind -- eg "www.valgrind.org", or "Checked with Valgrind", or >> something like that. >> >> If you're good at graphics, we'd love you to create such pictures, and >> send >> them in to val...@va.... We'll put the best ones up on that >> page >> at www.valgrind.org, and you can get a warm fuzzy feeling from helping us >> spread the word about Valgrind. There aren't any particular rules about >> picture sizes, or what text should be on there, or how closely you should >> stick to the original pictures -- feel free to use your imagination. >> >> Another thing that would be cool is a set of icons based on that artwork. >> In today's graphical world, having a standard, good set of Valgrind icons >> would be very useful. >> >> More broadly, we'd be interested to see any and all sorts of derivatives >> of the artwork. For example, perhaps somebody wants to make a T-shirt >> logo? >> >> If you want copies of the existing artwork at high-resolution, you can >> grab them with: >> >> svn co svn://www.valgrind.org/valgrind-www/images_src >> >> You'll need to have Subversion installed. >> >> Be warned that this directory contains 150MB of images, and so the above >> command may take some time to complete. Included are a mix of PNG and >> XCF >> (Gimp) format files. >> >> Also, if anyone is able to convert these pictures into SVG format, we'd >> love to have copies. >> >> Thanks. >> >> >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real users. >> Discover which products truly live up to the hype. Start reading now. >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> Valgrind-users mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Nicholas N. <nj...@cs...> - 2005-05-10 21:01:50
|
On Tue, 10 May 2005, Nathi Maus wrote: > Ok, so I run my programm using "valgrind --tool=cachgrind porg" and using > cg_annote I get information at which positions in my source code cache > misses to happen. > But I do I optimize now? What can I change in my programm to avoid a cache > miss? Section 3.3.8 of http://www.valgrind.org/docs/phd2004.pdf has something to say about this: \subsection{Usability Shortcomings} The nature of the information Cachegrind produces is not ideal. With any profiling tool, one wants a minimal ``conceptual distance'' between the information produced, and the action required to act on that information. For example, with traditional time-based profilers that say how much time each function takes, this conceptual distance is quite small---if a function \code{f()} accounts for 80\% of run-time, one knows immediately that speeding it up will have a large effect. By contrast, Cachegrind's conceptual distance is larger, for two reasons. \begin{enumerate} \item The number of cache misses occurring in a section of code does not necessarily relate obviously to the execution time of that section. Ideally, Cachegrind would specify how many cycles of machine time each instruction accounts for. However, given the complexity of modern machines, this is not feasible. One could use crude cost models to approximate cycle counts, but they are so likely to be misleading that this would be more of a hindrance than a help. (However, Section~\ref{Motivating Measurements} provides a rare counter-example.) \item Even if you know a line of source code is causing a lot of cache misses, and you are confident the misses are slowing down the program a lot, it is not always clear what can be done to improve this. It can be strongly indicative that, for example, a data structure could be redesigned. But the results rarely provide a ``smoking gun'', and some non-trivial insight about how the program interacts with the caches is required to act upon them. \end{enumerate} There is no silver bullet; optimising a program's cache utilisation is hard, and often requires trial and error. What Cachegrind does is turn an extremely difficult problem into a moderately difficult one. N |
|
From: Nathi M. <Nat...@gm...> - 2005-05-10 20:32:41
|
Hi everybody, Ok, so I run my programm using "valgrind --tool=cachgrind porg" and using cg_annote I get information at which positions in my source code cache misses to happen. But I do I optimize now? What can I change in my programm to avoid a cache miss? Thanks! Nathan -- +++ Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS +++ GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail |
|
From: Nicholas N. <nj...@cs...> - 2005-05-10 13:38:51
|
On Tue, 10 May 2005, Average GG wrote: > My environment is as follows: > * Red Hat Enterprise Linux AS release 3 (Taroon Update 3) > * 2.4.21-27.0.2.ELsmp > * valgrind-2.4.0 > I have a very large app that uses a number of libs and a lot of memory > management. > I'm trying to suppress everything except what is in my app and the > resulting suppressions file is: > * 169,000 lines > * 10,400 entries > When I try to use it with valgrind I get a very quick abort in a malloc (and > I'm not able to get gdb to localize the abort). > If I reduce the file to 10,000 lines and around 700 enties valgrind will run. > I've looked at the code and the list archives and help files and I don't > see any specific limitation on the number of suppression entries (other than > physical memory). Is there a guideline on the max size of suppression files? > tks for any help AFAIK there is no inherent limit. However, I doubt anyone has stressed the suppression mechanism this much so it's not that surprising that something goes wrong. Can you try your big suppression file with small test programs, and see if that causes problems? That would be an interesting test. Why do you need 10,000 suppressions? I've not heard of anyone needing more than a few hundred (and here's everyone else's chance to enlighten me about how many suppressions they have). N |
|
From: Average G. <ave...@ho...> - 2005-05-10 13:22:55
|
Sorry to bother everyone if this is already noted somewhere but I couldn't find it if so. My environment is as follows: * Red Hat Enterprise Linux AS release 3 (Taroon Update 3) * 2.4.21-27.0.2.ELsmp * valgrind-2.4.0 I have a very large app that uses a number of libs and a lot of memory management. I'm trying to suppress everything except what is in my app and the resulting suppressions file is: * 169,000 lines * 10,400 entries When I try to use it with valgrind I get a very quick abort in a malloc (and I'm not able to get gdb to localize the abort). If I reduce the file to 10,000 lines and around 700 enties valgrind will run. I've looked at the code and the list archives and help files and I don't see any specific limitation on the number of suppression entries (other than physical memory). Is there a guideline on the max size of suppression files? tks for any help agg |
|
From: Jeremy F. <je...@go...> - 2005-05-09 21:11:52
|
Julian Seward wrote:
>All,
>
>As a result of recent memcheck hackery in the 3.0 line, I broke
>support for the VALGRIND_SET_VBITS and VALGRIND_GET_VBITS
>client requests. I haven't fixed them; instead I am hoping to
>get rid of them altogether. They were introduced as an experimental
>hack, and as far as I know nobody ever used them.
>
>So my question is: does anybody use these?
>
I think there are lots of potential for clustered Valgrind, but they
should be relatively easy to put back if/when the time comes.
J
|
|
From: Julian S. <js...@ac...> - 2005-05-09 15:36:40
|
That is to say, valgrind.org. J On Monday 09 May 2005 16:15, Donna Robinson wrote: > Hi All, > > Just to let you all know that our server > is scheduled for downtime re upgrades etc. > from 6am BST to 6.30am BST tomorrow, 10 May. > > Donna > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. > Get your fingers limbered up and give it your best shot. 4 great events, 4 > opportunities to win big! Highest score wins.NEC IT Guy Games. Play to > win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Donna R. <do...@te...> - 2005-05-09 15:15:30
|
Hi All, Just to let you all know that our server is scheduled for downtime re upgrades etc. from 6am BST to 6.30am BST tomorrow, 10 May. Donna |
|
From: Eduardo M. <ea...@us...> - 2005-05-09 14:29:31
|
I think glibc 2.3.3 is supported in 2.1.1 valgrind release right?
So, Why am I getting this message here?
is it a problem??
How can I get rid of this message??
In file glibc-2.3.supp, there is no line to support SLES9 glibc-2.3.3
# valgrind --tool=helgrind ./allok
Actual Results:
==13269== Helgrind, a data race detector for x86-linux.
==13269== Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas Nethercote.
==13269== Using valgrind-2.1.1, a program supervision framework for
x86-linux.
==13269== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward.
==13269== For more details, rerun with: -v
==13269==
==13269== Thread 2:
==13269== Possible data race writing variable at 0x3F016048
(_rtld_global+72)
==13269== at 0x3F0080C0: _dl_lookup_symbol_x (dl-lookup.c:227)
==13269== by 0x3F00CEEB: fixup (dl-runtime.c:98)
==13269== by 0x3F00CCBF: _dl_runtime_resolve (in /lib/ld-2.3.3.so)
==13269== by 0xB800F58C: do__quit (vg_scheduler.c:1792)
==13269== Address 0x3F016048 is in data section of /lib/ld-2.3.3.so
==13269== Previous state: shared RO, no locks
==13269==
==13269== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 1 from 1)
==13269== 2 possible data races found; 0 lock order problems
alloc.c
#include <pthread.h>
static pthread_mutex_t mx = PTHREAD_MUTEX_INITIALIZER;
static int shared;
static void *th(void *v)
{
pthread_mutex_lock(&mx);
shared++;
pthread_mutex_unlock(&mx);
return 0;
}
int main()
{
pthread_t a, b;
pthread_mutex_lock(&mx);
pthread_mutex_unlock(&mx);
pthread_create(&a, NULL, th, NULL);
pthread_create(&b, NULL, th, NULL);
pthread_join(a, NULL);
pthread_join(b, NULL);
return 0;
}
Regards,
Eduardo A. Munoz
Linux Technology Center
ea...@us...
512-838-8219
|
|
From: David E. <tw...@us...> - 2005-05-09 09:37:26
|
On Mon, 2005-05-09 at 08:56 +0000, tim wrote: > Hello, having a small problem with valgrind 2.4.0 on Slackware Linux. Wondering > if anyone here can help. > > The problem is its not displaying the line number and source filename for memory > leaks that occur in our shared libraries. Strangely it does display this > information when it finds leaks in QT, and in our main app executable, but not > for the libs we built ourselves. > > Everything is compiled with -g and gdb can debug inside these shared libs with > no problem. However, valgrind just displays ???, eg: > > ==3407== at 0x1B902457: operator new(unsigned) (vg_replace_malloc.c:132) > ==3407== by 0x1CC60048: ??? > ==3407== by 0x1CBC8F57: ??? > ==3407== by 0x804A15B: CSClient::run(int, char**) (CSClient.cpp:262) > ==3407== by 0x8049815: main (main.cpp:35) > > Just wondering what causes the ??? to be displayed? Maybe this previous discussion is relevant? http://thread.gmane.org/gmane.comp.debugging.valgrind/1712 -- Regards, -\- David Eriksson -/- SynCE - http://synce.sourceforge.net ScummVM - http://scummvm.sourceforge.net Desquirr - http://desquirr.sourceforge.net |
|
From: tim <psi...@bl...> - 2005-05-09 09:18:30
|
Hello, having a small problem with valgrind 2.4.0 on Slackware Linux. Wondering if anyone here can help. The problem is its not displaying the line number and source filename for memory leaks that occur in our shared libraries. Strangely it does display this information when it finds leaks in QT, and in our main app executable, but not for the libs we built ourselves. Everything is compiled with -g and gdb can debug inside these shared libs with no problem. However, valgrind just displays ???, eg: ==3407== at 0x1B902457: operator new(unsigned) (vg_replace_malloc.c:132) ==3407== by 0x1CC60048: ??? ==3407== by 0x1CBC8F57: ??? ==3407== by 0x804A15B: CSClient::run(int, char**) (CSClient.cpp:262) ==3407== by 0x8049815: main (main.cpp:35) Just wondering what causes the ??? to be displayed? Thanks Tim |
|
From: Nicholas N. <nj...@cs...> - 2005-05-08 14:58:58
|
On Fri, 6 May 2005, Nicholas Nethercote wrote: > Looks like they got lost in KDE's CVS-->Subversion conversion. I just tried > to add them but discovered I don't have permission to commit to that branch! > I've told the relevant KDE people, hopefully they'll give me permission soon > and it will be fixed soon. Thanks for letting us know about this. The KDE people have said they've fixed a lot of these problems up now, so hopefully this will be working again. (I just tried to check but was having network problems...) N |