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
(5) |
2
(3) |
3
(1) |
4
(4) |
5
(1) |
6
(11) |
7
(5) |
|
8
|
9
(6) |
10
(2) |
11
(10) |
12
|
13
|
14
(4) |
|
15
(7) |
16
(1) |
17
(3) |
18
|
19
|
20
|
21
(1) |
|
22
(1) |
23
|
24
|
25
|
26
|
27
|
28
(4) |
|
29
|
30
|
31
|
|
|
|
|
|
From: Julian S. <js...@ac...> - 2002-12-21 23:19:23
|
I've got the wierdest bug, which completely mystifies me, and I wondered if either of you might be able to cast any light on it. I'm running OpenOffice-1.0.1 on V (1.9.2, which is pretty much the current cvs head) on SuSE 8.1 on VMWare 3.2 on Win2K. With almost all arrangements of flags and skins to valgrind, OO runs fine. But with --skin=addrcheck --leak-check=yes, it doesn't. OO is a shell script so I supply --trace-children=yes. One of the traced children is a run of sed. Whilst doing the final leak-check for that run, valgrind's low level memory allocator claims it is out of memory, and aborts. This is a complete lie; there is 300+ M of swap available. Why it's claiming memory at the leak check is so as to read in symbol tables so it can print the leak messages nicely. This isn't relevant, I don't think. Anyway: V's low-level allocator works by mmaping in blocks of /dev/zero with read, write and execute permissions, and flags MAP_PRIVATE|MAP_ANONYMOUS. The usual deal, in other words. In this case it asked for a block of 1MB, having already allocated just under 9MB. mmap returns with -12 (-ENOMEM), which I at first didn't believe. However, prodding with w revealed sewardj 29384 90.8 2.1 2096992 5456 pts/2 R 18:31 0:29 sed with an implausibly large process size. cat /proc/29384/maps reveals 08048000-08055000 r-xp 00000000 08:02 24022 /bin/sed 08055000-08056000 rw-p 0000c000 08:02 24022 /bin/sed 40000000-40013000 r-xp 00000000 08:02 20673 /lib/ld-2.2.5.so 40013000-40014000 rw-p 00012000 08:02 20673 /lib/ld-2.2.5.so 40014000-4001b000 r-xp 00000000 08:02 127756 /home/sewardj/TEST/valgrind-1.9.2/Inst/lib/valgrind/vgskin_addrcheck.so 4001b000-4001c000 rw-p 00006000 08:02 127756 /home/sewardj/TEST/valgrind-1.9.2/Inst/lib/valgrind/vgskin_addrcheck.so 4001c000-4011f000 rw-p 00000000 00:00 0 4011f000-40197000 r-xp 00000000 08:02 127516 /home/sewardj/TEST/valgrind-1.9.2/Inst/lib/valgrind/valgrind.so 40197000-40198000 rw-p 00077000 08:02 127516 /home/sewardj/TEST/valgrind-1.9.2/Inst/lib/valgrind/valgrind.so 40198000-401e6000 rw-p 00000000 00:00 0 401e6000-401f0000 rwxp 00000000 00:00 0 401f1000-40307000 r-xp 00000000 08:02 20679 /lib/libc.so.6 40307000-4030d000 rw-p 00115000 08:02 20679 /lib/libc.so.6 4030d000-40311000 rw-p 00000000 00:00 0 40311000-40aeb000 rwxp 00000000 00:00 0 40aec000-40aee000 rwxp 00000000 00:00 0 40af1000-40af3000 rwxp 00000000 00:00 0 40b23000-40b29000 rwxp 00000000 00:00 0 40b29000-40b2a000 rw-p 00000000 00:00 0 40b2b000-c0000000 rwxp 80b2c000 00:00 0 (!!!!!!!!!!!!!) so there is an enormous /dev/zero segment all the way from 40b2b000 up to the stack base (!). A bit of debug printing shows accounts for the various other segments (40b29000-40b2a000) getting allocated, but nowhere does it ask for more than 2GB of space. I have no idea why the kernel thinks that space is allocated. I wondered if this could be some conflict between parent and child. But the mmaps are private anonymous mappings, which AIUI gives shared-copy-on- write semantics. Then I wondered if it's something strange about running on vmware. But that's proved unfailingly reliable in the past. So I'm completely lost. Any idea why the kernel could come to believe such a huge lump of address space is allocated? This is SuSE's "2.4.18-4GB" kernel, whatever that might entail. Just an idea: it wouldn't be some wierd thing with the kernel extending the stack segment down way too far ??? J |