You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
(9) |
2
(1) |
3
(1) |
|
4
(1) |
5
(1) |
6
(1) |
7
(1) |
8
(5) |
9
(9) |
10
(1) |
|
11
(1) |
12
(2) |
13
(10) |
14
(4) |
15
(1) |
16
|
17
(1) |
|
18
(1) |
19
(1) |
20
(8) |
21
(1) |
22
(2) |
23
|
24
|
|
25
|
26
(2) |
27
(15) |
28
(12) |
29
(9) |
30
(5) |
31
(5) |
|
From: Konstantin S. <kon...@gm...> - 2009-10-14 12:44:13
|
On Wed, Oct 14, 2009 at 4:05 PM, Julian Seward <js...@ac...> wrote: > On Wednesday 14 October 2009, Konstantin Serebryany wrote: > > > I did not think about opening this file for the duration of the run... > :) > > > I need to check the occupied memory very often so that the tool can > ^^^^^^^^^^ > > Actually, you only need to check it when the process' mappings change, > or when sbrk happens, since that's the only way(s) the process can acquire > more memory. No need for spin-style polling. > > So .. get your tool to monitor the "new_mem_mmap" and "die_mem_mmap" > This will notify me when the client program does mmap/brk. Right? But I also need to watch for mmap/brk of valgrind itself. Is it possible? --kcc > core-tool events. When you get notified of one of those, then check > the memory situation. See Memcheck sources for examples how (it's easy). > > One danger, though; the following race leading to a segfault: > > tool is notified of new_mem_mmap > tool decides to reread /proc/self/status > so it does VG_(malloc) to allocate a buffer > which results in m_mallocfree doing mmap > which results in a new_mem_mmap notification > > We've had problems like this in the past. (I think the above scenario > is impossible, but nevertheless ..) I would strongly suggest that all > the code you have inside your new_mem_mmap does not do any dynamic > mem allocation. Best to read the file, check if need to reduce mem > consumption, if so, set a flag, and exit. Then, elsewhere in your > tool, check the flag, and if set, dump memory, or whatever. > > J > |
|
From: Julian S. <js...@ac...> - 2009-10-14 11:52:44
|
On Wednesday 14 October 2009, Konstantin Serebryany wrote:
> > I did not think about opening this file for the duration of the run... :)
> > I need to check the occupied memory very often so that the tool can
^^^^^^^^^^
Actually, you only need to check it when the process' mappings change,
or when sbrk happens, since that's the only way(s) the process can acquire
more memory. No need for spin-style polling.
So .. get your tool to monitor the "new_mem_mmap" and "die_mem_mmap"
core-tool events. When you get notified of one of those, then check
the memory situation. See Memcheck sources for examples how (it's easy).
One danger, though; the following race leading to a segfault:
tool is notified of new_mem_mmap
tool decides to reread /proc/self/status
so it does VG_(malloc) to allocate a buffer
which results in m_mallocfree doing mmap
which results in a new_mem_mmap notification
We've had problems like this in the past. (I think the above scenario
is impossible, but nevertheless ..) I would strongly suggest that all
the code you have inside your new_mem_mmap does not do any dynamic
mem allocation. Best to read the file, check if need to reduce mem
consumption, if so, set a flag, and exit. Then, elsewhere in your
tool, check the flag, and if set, dump memory, or whatever.
J
|
|
From: Konstantin S. <kon...@gm...> - 2009-10-14 11:30:09
|
On Tue, Oct 13, 2009 at 11:17 PM, Konstantin Serebryany < kon...@gm...> wrote: > On Tue, Oct 13, 2009 at 5:54 PM, John Reiser <jr...@bi...> wrote: > > > > > I need to know how much memory is taken by a valgrind process from > > > inside that process. And I need it to be fast. > > > > How fast? > > > > > One option is to read /proc/self/status and extract the VmSize field. > > > Slow, bad. > > > > Doing a pread(,,,0) and parsing the result via strstr+atoi should take > > about 1 microsecond. > > Hm. Perhaps. > I did not think about opening this file for the duration of the run... :) > I need to check the occupied memory very often so that the tool can > react accordingly when the memory is close to its limit. > pread+strstr+atoi might be fast enough. Need to check... > Valgrind does not have pread(). lseek+read+strstr+strtol is a bit too slow for me, so I have to call it less frequently than I would like to. Any idea how to get VmSize inside valgrind w/o reading /proc/self/status? --kcc > > > > > Open /proc/self/status once at the beginning, > > and keep it open for the zillions of calls you'll be making. > > Or does pread fail for files in /proc? > > > > > Another option is to keep track of valgrind's VG(malloc) and users's > > > malloc, etc. Easy to loose something, bad. > > > > > > If you do not trust valgrind internal code then why run it at all? > > Is there such functionality in valgrind core already? > I need to get the number very close to the one in /proc/self/status:VmSize > > > Thanks! > --kcc > > > > -- > > > > > ------------------------------------------------------------------------------ > > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > > is the only developer event you need to attend this year. Jumpstart your > > developing skills, take BlackBerry mobile applications to market and stay > > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > > http://p.sf.net/sfu/devconference > > _______________________________________________ > > Valgrind-developers mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Bart V. A. <bar...@gm...> - 2009-10-14 07:54:35
|
Nightly build on cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) Started at 2009-10-14 02:27:50 EDT Ended at 2009-10-14 03:54:11 EDT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 448 tests, 45 stderr failures, 10 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cases-full (stderr) memcheck/tests/leak-cases-summary (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/linux/timerfd-syscall (stdout) memcheck/tests/linux-syscalls-2007 (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/wrap8 (stdout) memcheck/tests/wrap8 (stderr) none/tests/empty-exe (stderr) none/tests/linux/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-vmx (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/test_gx (stdout) none/tests/ppc64/jm-fp (stdout) none/tests/ppc64/jm-vmx (stdout) none/tests/ppc64/round (stdout) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) none/tests/shell_zerolength (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) drd/tests/tc23_bogus_condwait (stderr) exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/fp (stderr) exp-ptrcheck/tests/globalerr (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) exp-ptrcheck/tests/hp_bounds (stderr) exp-ptrcheck/tests/hp_dangle (stderr) exp-ptrcheck/tests/hsg (stderr) exp-ptrcheck/tests/justify (stderr) exp-ptrcheck/tests/partial_bad (stderr) exp-ptrcheck/tests/partial_good (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) exp-ptrcheck/tests/realloc (stderr) exp-ptrcheck/tests/stackerr (stderr) exp-ptrcheck/tests/strcpy (stderr) exp-ptrcheck/tests/supp (stderr) exp-ptrcheck/tests/tricky (stderr) exp-ptrcheck/tests/unaligned (stderr) exp-ptrcheck/tests/zero (stderr) |