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
|
2
(13) |
3
(29) |
|
4
(18) |
5
(12) |
6
(12) |
7
(22) |
8
(9) |
9
(14) |
10
(6) |
|
11
|
12
|
13
(1) |
14
(5) |
15
(11) |
16
(7) |
17
(5) |
|
18
(1) |
19
(8) |
20
(7) |
21
(12) |
22
(5) |
23
(17) |
24
(6) |
|
25
(27) |
26
(17) |
27
(2) |
28
(10) |
29
(3) |
30
(8) |
31
(20) |
|
From: Nicholas N. <nj...@ca...> - 2004-01-10 12:56:39
|
On Fri, 9 Jan 2004, Josef Weidendorfer wrote:
> > Colon (':') chars? Yes, they wouldn't be allowed, but that doesn't seem
> > like a great loss? If that's a problem, maybe --toolname::option, or
> > something even more obscure?
>
> In calltree, in some options there can symbol names be specified, e.g. where
> to start collecting, and so on. Unfortunately, for C++, colons can be part of
> the symbol name.
> As my options are like --option=... it would work with your scheme if we only
> allow alpha(numeric?) characters as part of a tool/skin name, e.g. not '='.
> Is this acceptable?
Sounds fine, I'll fix.
N
|
|
From: Dirk M. <dm...@gm...> - 2004-01-10 12:40:04
|
On Saturday 10 January 2004 09:11, Ayodele Thomas wrote: > VG_(get_memory_from_mmap): request for 1048576 bytes failed. > VG_(get_memory_from_mmap): 2144292771 bytes already allocated. on intel x86 archictures, which valgrind runs on, a single process cannot allocate more than 2GB of RAM. Even though you have 20GB of swap, as pointers have only 32bit size, you can't create a bigger process image. reduce your working set size and try again. Dirk |
|
From: Ayodele T. <em...@st...> - 2004-01-10 09:27:19
|
I just tried it with the latest stable release and I get the same problem. > > In message <200...@ca...> > "Ayodele Thomas" <em...@st...> wrote: > > > Valgrind seems to think it has run out of memory although the machine > > seems to believe that it has ample memory. Any suggestions on how to fix > > this problem? It is very frustrating. I am not using the latest release. > > Well if you're not using the latest release, what version are you using? > > Tom > > -- > Tom Hughes (th...@cy...) > Software Engineer, Cyberscience Corporation > http://www.cyberscience.com/ > -- --------------------------------------------------------------- Ayodele Bolaji Thomas "Joy in the Morning" Ph.D. Candidate Electrical Engineering Computer Systems Laboratory Stanford University Ayo...@st... Support our troops. Support our country. Pray for Peace. \o/ "We succeed, not because of Affirmative Action, but in spite of the conditions that make it necessary" (ABE '98) "War may sometimes be a necessary evil. But no matter how necessary, it is always an evil, never a good. We will not learn to live together in peace by killing each other's children." Jimmy Carter '02 --------------------------------------------------------------- |
|
From: Jeremy F. <je...@go...> - 2004-01-10 08:23:11
|
On Fri, 2004-01-09 at 09:56, Nicholas Nethercote wrote:
> Behaviour should be the same as before; where VALGRIND_OPTS was read
> before, I know read VALGRIND_OPTS plus the two .rc files.
OK, I think env vars are more "local" though (since they're per-shell),
so VALGRIND_OPTS should take precidence over ~/.valgrindrc (and maybe
./.valgrindrc), but obviously not the actual command line.
> > > I think this also fixes bug 71126, thanks to Tom for his patch.
> >
> > I still think this could do with a more radical rearrangement. I don't
> > think main() should be parsing the command line at all, or loading the
> > tool. If it simply generates a unified vg_argv and passes it to
> > VG_(main), VG_(main) can do the rest. This means that the address space
> > should remain padded until VG_(main) is ready to unpad it (ie, after
> > doing dlopen on the tool).
>
> Can you clarify what you see as the conceptual difference between main()
> and VG_(main)()?
There is none - it's a historical artifact. At one point stage2 and
valgrind.so were separate entities, with stage2 dlopening valgrind.so.
At that point it seemed like a good idea to do all the dlopening in
main(), and set VG_(main) off with everything set up. Now that they're
linked together, it doesn't seem so important.
Part of the complexity of the current initialization is that a lot of
low-level Valgrind mechanisms are set up in VG_(main), but the stuff in
main() should really be using them.
Using VG_(mmap) is mandatory once the padding has been removed, and
VG_(mmap) depends on the allocator having been set up. And because we'd
like to allow the use of any library, we should probably set up
intercept functions for plain old mmap/__libc_mmap/etc.
VG_(mmap/munmap/mprotect/ec) also depend on the Segment list being set
up.
Also, all the error reporting in main() should probably use Valgrind
standard error reporting mechanisms, rather than just fprintf()ing
things.
In other words, it's a mess which just happens to mostly work.
> One possibility is that main() is a bit like __libc_start_main(), ie sets
> things like argv/argc up ready for the program. Then VG_(main)() is a bit
> like main() for a normal program -- start doing real stuff. In which
> case, moving the command-line parsing to main() makes perfect sense.
>
> However, to me, the unpadding feels like it should be done as part of the
> setup stuff in main().
>
> 1. pad
> 2. setup argv
> 3. partially parse argv to find tool
> 4. load tool.so + valgrind.so
> 5. do_exec the client binary
> 6. unpad
>
> Because it's all a bit mixed up at the start -- necessary due to tool
> selection from the command-line -- there doesn't seem to be an obvious cut
> point between main() and VG_(main)().
The pad() really does have to happen very early, because it must get
done before anyone else calls mmap(), but we can unpad pretty late
without consequence (at any time up to running the first client
instruction). Hm. The most important pad, the client address space,
has already been done by stage1, so it is already in place by the time
stage2's main() is called.
Setting up argv currently uses malloc(), which is a bit troublesome,
because it may want to use brk(). brk() happens to work at the moment,
because stage1 sets up the brk segment, but this is non-portable and
unreliable. This means we also have to intercept brk/sbrk and implement
them in terms of VG_(mmap) so that libraries can use them.
In general, for the moment, I'd like to keep using VG_() versions of
functions as much as possible, and move over to the libc versions in a
systematic way. That's because a lot of the VG_() versions are not
simple clones of the libc functions, and/or may have other important
side-effects which we rely on. I broke this rule a lot in stage2.c and
ume.c, mostly because of the historical unavailability of the VG_()
functions in those contexts (and ume.c still needs to link into stage1,
which has no VG_() functions available).
So, I think the init ordering should be:
1. stage1
1. pad the client address space
2. do_exec stage2
2. stage2:main()
1. (do something to cope with .init sections of any
libraries we're using)
2. initialize Segment list to reflect all current mappings
(VG_(init_memory)
3. init Valgrind heap, make mmap() call VG_(mmap), deal
with brk/sbrk.
4. init early error reporting (ie default output sink)
5. set up any other padding
6. collate arguments from all the possible sources,
generating a unified vg_argv[] array
3. stage2:VG_(main)()
1. parse vg_argv
2. print errors/usage/early failures
3. dlopen() the tool
4. init everything else (may need to be after
do_exec(client) if it depends on the shape/placement of
the client address space)
5. remove all padding/clear all mappings out of client
address space
6. do_exec client/set up client stack
7. start VCPU
As you say, the break between main() and VG_(main) is pretty arbitrary.
Perhaps we should just drop stage2.c, move everything into vg_main.c,
rename VG_(main)() to main(), get rid of KickStartParams (another
historical name).
J
|
|
From: Tom H. <th...@cy...> - 2004-01-10 08:14:34
|
In message <200...@ca...>
"Ayodele Thomas" <em...@st...> wrote:
> Valgrind seems to think it has run out of memory although the machine
> seems to believe that it has ample memory. Any suggestions on how to fix
> this problem? It is very frustrating. I am not using the latest release.
Well if you're not using the latest release, what version are you using?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Ayodele T. <em...@st...> - 2004-01-10 08:11:02
|
I am having serious issues running out of memory. Valgrind claims that it
cannot allocate 1M of memory (below), but when I look at "top" I see
almost 1GB of free memory, no swap space being used and no memory shared.
VG_(get_memory_from_mmap): request for 1048576 bytes failed.
VG_(get_memory_from_mmap): 2144292771 bytes already allocated.
Valgrind seems to think it has run out of memory although the machine
seems to believe that it has ample memory. Any suggestions on how to fix
this problem? It is very frustrating. I am not using the latest release.
The following is a dump of "top", just before it dies.
Ayo
00:07:55 up 2 days, 9:28, 13 users, load average: 1.70, 0.97, 0.78
89 processes: 86 sleeping, 3 running, 0 zombie, 0 stopped
CPU states: 99.0% user 1.0% system 0.0% nice 0.0% iowait 0.0%
idle
Mem: 2064560k av, 1091960k used, 972600k free, 0k shrd, 192148k
buff
939968k actv, 31616k in_d, 45976k in_c
Swap: 4233116k av, 0k used, 4233116k free 467696k cached
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
959 ayodele 25 0 246M 246M 556 R 99.3 12.2 3:31 0 pegwit
---------------------------------------------------------------
Ayodele Bolaji Thomas "Joy in the Morning"
Ph.D. Candidate Electrical Engineering
Computer Systems Laboratory
Stanford University
Ayo...@st...
---------------------------------------------------------------
|