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
|
3
(4) |
4
(5) |
5
(5) |
6
(3) |
7
|
8
|
|
9
|
10
(8) |
11
(13) |
12
(12) |
13
(1) |
14
(1) |
15
(5) |
|
16
|
17
(12) |
18
(7) |
19
(5) |
20
|
21
(11) |
22
(8) |
|
23
(8) |
24
(6) |
25
|
26
(2) |
27
(3) |
28
(9) |
29
|
|
30
|
31
(5) |
|
|
|
|
|
|
From: <sv...@va...> - 2011-01-04 23:46:15
|
Author: njn
Date: 2011-01-04 23:46:07 +0000 (Tue, 04 Jan 2011)
New Revision: 11491
Log:
Clarify some details about "possibly lost" heap blocks.
Modified:
trunk/docs/xml/FAQ.xml
trunk/memcheck/docs/mc-manual.xml
Modified: trunk/docs/xml/FAQ.xml
===================================================================
--- trunk/docs/xml/FAQ.xml 2011-01-04 21:09:14 UTC (rev 11490)
+++ trunk/docs/xml/FAQ.xml 2011-01-04 23:46:07 UTC (rev 11491)
@@ -528,8 +528,9 @@
</listitem>
<listitem>
<para>"possibly lost" means your program is leaking
- memory, unless you're doing funny things with pointers.
- This is sometimes reasonable. Use
+ memory, unless you're doing unusual things with pointers that could
+ cause them to point into the middle of an allocated block; see the
+ user manual for some possible causes. Use
<option>--show-possibly-lost=no</option> if you don't want to see
these reports.</para>
</listitem>
Modified: trunk/memcheck/docs/mc-manual.xml
===================================================================
--- trunk/memcheck/docs/mc-manual.xml 2011-01-04 21:09:14 UTC (rev 11490)
+++ trunk/memcheck/docs/mc-manual.xml 2011-01-04 23:46:07 UTC (rev 11491)
@@ -401,7 +401,11 @@
<itemizedlist>
<listitem>
<para>The pointer might have originally been a start-pointer and have been
- moved along deliberately (or not deliberately) by the program.</para>
+ moved along deliberately (or not deliberately) by the program. In
+ particular, this can happen if your program uses tagged pointers, i.e.
+ if it uses the bottom one, two or three bits of a pointer, which are
+ normally always zero due to alignment, in order to store extra
+ information.</para>
</listitem>
<listitem>
|
|
From: <sv...@va...> - 2011-01-04 21:09:24
|
Author: weidendo Date: 2011-01-04 21:09:14 +0000 (Tue, 04 Jan 2011) New Revision: 11490 Log: Fix typo Modified: trunk/callgrind/docs/cl-format.xml Modified: trunk/callgrind/docs/cl-format.xml =================================================================== --- trunk/callgrind/docs/cl-format.xml 2011-01-04 14:18:35 UTC (rev 11489) +++ trunk/callgrind/docs/cl-format.xml 2011-01-04 21:09:14 UTC (rev 11490) @@ -112,7 +112,7 @@ source file. The 2nd line looks like a regular cost line with the difference that inclusive cost spent inside of the function call has to be specified.</para> -<para>Other associations which or for example (conditional) jumps. See the +<para>Other associations are for example (conditional) jumps. See the reference below for details.</para> </sect2> |
|
From: <sv...@va...> - 2011-01-04 14:18:46
|
Author: sewardj
Date: 2011-01-04 14:18:35 +0000 (Tue, 04 Jan 2011)
New Revision: 11489
Log:
Un-break the trunk build on OSX (broken by r11483 on 6 Dec '10).
Fixes #261654.
Modified:
trunk/coregrind/m_syswrap/syswrap-darwin.c
Modified: trunk/coregrind/m_syswrap/syswrap-darwin.c
===================================================================
--- trunk/coregrind/m_syswrap/syswrap-darwin.c 2010-12-17 00:45:19 UTC (rev 11488)
+++ trunk/coregrind/m_syswrap/syswrap-darwin.c 2011-01-04 14:18:35 UTC (rev 11489)
@@ -2749,7 +2749,13 @@
}
// Decide whether or not we want to follow along
- trace_this_child = VG_(should_we_trace_this_child)( (HChar*)ARG2 );
+ { // Make 'child_argv' be a pointer to the child's arg vector
+ // (skipping the exe name)
+ HChar** child_argv = (HChar**)ARG4;
+ if (child_argv && child_argv[0] == NULL)
+ child_argv = NULL;
+ trace_this_child = VG_(should_we_trace_this_child)( (HChar*)ARG2, child_argv );
+ }
// Do the important checks: it is a file, is executable, permissions are
// ok, etc. We allow setuid executables to run only in the case when
|
|
From: Julian S. <js...@ac...> - 2011-01-04 13:59:49
|
On Monday, January 03, 2011, Tom Hughes wrote: > On 03/01/11 20:23, Konstantin Serebryany wrote: > > We are seeing more and more of this error: > > valgrind: mmap(0x38000000, 2375680) failed in UME with error 22 (Invalid > > argument). > > valgrind: this can be caused by executables with very large text, data > > or bss segments. > > > > (known as > > http://bugs.kde.org/show_bug.cgi?id=138424, > > http://bugs.kde.org/show_bug.cgi?id=184981, > > http://code.google.com/p/chromium/issues/detail?id=28439). > > > > Any chance to fix it? Do you have a reliable reproducer? (If no, we > > could send a pre-built binary for Ubuntu 10.04)... > > What makes you think it can be fixed? It's a basic limitation of > valgrind that it needs to reserve some memory for itself and hence there > will be less available for the client program than when it is not > running valgrind. > > That is, I believe, the basic cause of this error, that after valgrind > has reserved memory for itself there is not enough room to load the > executable. It could also really be caused by executables with very large text etc segments. Since the text segment will get mapped to 0x8048000 (roughly 134MB), if its size exceeds about 800MB then the top part will overlap valgrind's load point of 0x38000000 (939MB) and so the UME will fail. (Actually .. to be more precise .. won't it fail if the size of text + data + bss exceeds about 800MB ?) Konstantin, what happens if you edit configure.in and change all the 0x38000000 to (eg) 0x58000000, to select a higher load address for V? J |
|
From: Tom H. <to...@co...> - 2011-01-03 20:33:44
|
On 03/01/11 20:23, Konstantin Serebryany wrote: > We are seeing more and more of this error: > valgrind: mmap(0x38000000, 2375680) failed in UME with error 22 (Invalid > argument). > valgrind: this can be caused by executables with very large text, data > or bss segments. > > (known as > http://bugs.kde.org/show_bug.cgi?id=138424, > http://bugs.kde.org/show_bug.cgi?id=184981, > http://code.google.com/p/chromium/issues/detail?id=28439). > > Any chance to fix it? Do you have a reliable reproducer? (If no, we > could send a pre-built binary for Ubuntu 10.04)... What makes you think it can be fixed? It's a basic limitation of valgrind that it needs to reserve some memory for itself and hence there will be less available for the client program than when it is not running valgrind. That is, I believe, the basic cause of this error, that after valgrind has reserved memory for itself there is not enough room to load the executable. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Konstantin S. <kon...@gm...> - 2011-01-03 20:23:59
|
Hi, We are seeing more and more of this error: valgrind: mmap(0x38000000, 2375680) failed in UME with error 22 (Invalid argument). valgrind: this can be caused by executables with very large text, data or bss segments. (known as http://bugs.kde.org/show_bug.cgi?id=138424, http://bugs.kde.org/show_bug.cgi?id=184981, http://code.google.com/p/chromium/issues/detail?id=28439). Any chance to fix it? Do you have a reliable reproducer? (If no, we could send a pre-built binary for Ubuntu 10.04)... Thanks, and happy new year! --kcc |
|
From: Julian S. <js...@ac...> - 2011-01-03 13:51:30
|
Interesting use case! > * Syscall whitelisting is done within valgrind, notably preventing the > client from escaping valgrind through execve(), and from closing or > duping over the FD used for valgrind messages > > * Client requests are banned (immediate exit when seeing them in the IR) > > * Memory is tracked far enough to be sure that the client cannot write > to valgrind's memory > > As soon as you can stop screaming "valgrind -- security -- CRAZY", I > would of course be interested to hear if there are any other known > holes. I still plan on keeping the "other" syscall whitelist, to have > double security against leaking the testcases through socket() etc, > but any issue with valgrind would at least allow the student to > circumvent the time limits, which is bad enough. I'm not sure if it could be used to circumvent time limits, but .. you might want to stop the client looking at /proc/self/* or even within /proc. Using (eg) /proc/self/maps it is easy to figure out that you're not running on the real hardware. We already have to fake /proc/self/cmdline (iirc) in order to make OpenOffice work at all. J |
|
From: Irfan Ul H. <irf...@se...> - 2011-01-03 09:53:32
|
Dear all, We are currently in the process of porting Valgrind for MIPS/Linux Platform. Everything else works, except that multithreaded applications using nptl threading library reach the futex deadlock. Google helped us find reference to the bug listed on link: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=299514 We are facing exactly same problem. Note that when we run Valgrind under gdb and add a breakpoint just before child thread's exit and then continue, our program exits normally, producing the expected output. However, the program running directly under Valgrind does not produce expected output. Any idea how to fix this part? -- Irfan |