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
(15) |
3
(20) |
|
4
(4) |
5
(11) |
6
(8) |
7
(36) |
8
(23) |
9
(6) |
10
(4) |
|
11
(4) |
12
(19) |
13
(17) |
14
(33) |
15
(16) |
16
(17) |
17
(4) |
|
18
(4) |
19
(30) |
20
(22) |
21
(23) |
22
(29) |
23
(20) |
24
(12) |
|
25
(7) |
26
(33) |
27
(10) |
28
(12) |
29
(19) |
30
(15) |
31
(8) |
|
From: <sv...@va...> - 2009-01-05 17:15:51
|
Author: sewardj Date: 2009-01-05 17:15:44 +0000 (Mon, 05 Jan 2009) New Revision: 8910 Log: Bump version number on 3_4_BRANCH. Modified: branches/VALGRIND_3_4_BRANCH/configure.in Modified: branches/VALGRIND_3_4_BRANCH/configure.in =================================================================== --- branches/VALGRIND_3_4_BRANCH/configure.in 2009-01-05 17:14:12 UTC (rev 8909) +++ branches/VALGRIND_3_4_BRANCH/configure.in 2009-01-05 17:15:44 UTC (rev 8910) @@ -8,7 +8,7 @@ ##------------------------------------------------------------## # Process this file with autoconf to produce a configure script. -AC_INIT(Valgrind, 3.4.0, val...@li...) +AC_INIT(Valgrind, 3.4.1.SVN, val...@li...) AC_CONFIG_SRCDIR(coregrind/m_main.c) AM_CONFIG_HEADER(config.h) AM_INIT_AUTOMAKE([foreign]) |
|
From: <sv...@va...> - 2009-01-05 17:14:20
|
Author: sewardj Date: 2009-01-05 17:14:12 +0000 (Mon, 05 Jan 2009) New Revision: 8909 Log: Bump version number on the trunk. Modified: trunk/configure.in Modified: trunk/configure.in =================================================================== --- trunk/configure.in 2009-01-05 12:16:21 UTC (rev 8908) +++ trunk/configure.in 2009-01-05 17:14:12 UTC (rev 8909) @@ -8,7 +8,7 @@ ##------------------------------------------------------------## # Process this file with autoconf to produce a configure script. -AC_INIT(Valgrind, 3.4.0, val...@li...) +AC_INIT(Valgrind, 3.5.0.SVN, val...@li...) AC_CONFIG_SRCDIR(coregrind/m_main.c) AM_CONFIG_HEADER(config.h) AM_INIT_AUTOMAKE([foreign]) |
|
From: Julian S. <js...@ac...> - 2009-01-05 16:17:09
|
> So we should try and find the PT_LOAD associated with each mapping we > see, which would allow us to calculate the bias for that section, then > use the p_vaddr and p_memsz of the segment (which give the svma address > and size) to match against the svma addresses in the section table to > work out the bias for each section. > > Does that make sense? Yes it does. It never occurred to me before that the segment-vs-section mapping stuff needed to be taken into account. Any chance you can hack up a patch for contemplation? J |
|
From: Tom H. <to...@co...> - 2009-01-05 15:04:15
|
Julian Seward wrote: > Um, yeh. (Coughs). I had a great deal of trouble getting it to compute > the correct avmas for the bss and data sections, and I'm sure it's not > right. I always feel (more than) slightly at sea when dealing with ELF > and its innumerable offsets etc. I have seen cases where it fails to get > the correct biases (or something) for bss/data symbols in .so's. If you > understand how to make these computations correct, that would be great. Indeed... What we have now seems to be a bit of a giant kludge that just happens to sort of work most of the time. > From observing mmap, we can see which parts of the object got mapped > r-x and which got mapped rw-. We know that the text segment must be > in the first mapping and the data segment in the second mapping. But > the bss could be mapped anywhere; it's only necessary for ld.so to come > up with a bunch of pages mapped from /dev/zero and put the .bss > somewhere within those. Is there perhaps some ambiguity therefore in > deducing what bss avma was chosen by ld.so, whereas there is no > such ambiguity with the text and data sections? I think the main problem is that we're trying to relate mappings directly to ELF sections, whereas we should really be relating them to ELF segments and then looking to see which ELF segment each ELF section is in. The result of all which is that we are trying to make decisions about which mapping covers a section based on file offsets, even though the file offset in the ELF is of limited use for sections like bss which don't have any data. A typical ELF file will have two or three segments (each described by a PT_LOAD entry in the PHdr table) one of which will be rx, one rw, and possible an ro one as well. The rw segment typically has a memsz which is greater than the filesz and that extra space is where the bss is hidden. The ELF spec requires the bias to be the same for all sections within a segment regardless of whether they are mapped from the file or not, so if we can compute the bias for a segment we can compute the bias for all the sections in it. So we should try and find the PT_LOAD associated with each mapping we see, which would allow us to calculate the bias for that section, then use the p_vaddr and p_memsz of the segment (which give the svma address and size) to match against the svma addresses in the section table to work out the bias for each section. Does that make sense? Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Julian S. <js...@ac...> - 2009-01-05 12:31:09
|
On Monday 05 January 2009, Tom Hughes wrote: > The debuginfo code has some curious kludge code in read_elf_debug_info > which ignores the (correctly calculated) bss details and replaces them > with a kludged version which makes certain (invalid) assumptions. Um, yeh. (Coughs). I had a great deal of trouble getting it to compute the correct avmas for the bss and data sections, and I'm sure it's not right. I always feel (more than) slightly at sea when dealing with ELF and its innumerable offsets etc. I have seen cases where it fails to get the correct biases (or something) for bss/data symbols in .so's. If you understand how to make these computations correct, that would be great. I can't say I remember why the kludge is there. (I presume you refer to the "if (1)" at readelf.c:1579). I remember that I also had to insert a nasty biasing kludge for global variables into the DWARF3 variable/type reader (readdwarf3.c). But I don't think that's directly relevant, at least to the immediate problem of simply extracting the correct addresses of all data and bss symbols from the ELF. Sorry not to be able to offer anything more useful. ----- (a hypothesis, based on dim memories, maybe completely wrong) From observing mmap, we can see which parts of the object got mapped r-x and which got mapped rw-. We know that the text segment must be in the first mapping and the data segment in the second mapping. But the bss could be mapped anywhere; it's only necessary for ld.so to come up with a bunch of pages mapped from /dev/zero and put the .bss somewhere within those. Is there perhaps some ambiguity therefore in deducing what bss avma was chosen by ld.so, whereas there is no such ambiguity with the text and data sections? J |
|
From: <sv...@va...> - 2009-01-05 12:16:28
|
Author: tom
Date: 2009-01-05 12:16:21 +0000 (Mon, 05 Jan 2009)
New Revision: 8908
Log:
Add some more system calls to ptrcheck.
Modified:
trunk/exp-ptrcheck/h_main.c
Modified: trunk/exp-ptrcheck/h_main.c
===================================================================
--- trunk/exp-ptrcheck/h_main.c 2009-01-03 22:46:15 UTC (rev 8907)
+++ trunk/exp-ptrcheck/h_main.c 2009-01-05 12:16:21 UTC (rev 8908)
@@ -2179,6 +2179,7 @@
ADD(0, __NR_accept);
# endif
ADD(0, __NR_access);
+ ADD(0, __NR_alarm);
# if defined(__NR_bind)
ADD(0, __NR_bind);
# endif
@@ -2194,6 +2195,7 @@
# if defined(__NR_connect)
ADD(0, __NR_connect);
# endif
+ ADD(0, __NR_creat);
ADD(0, __NR_dup);
ADD(0, __NR_dup2);
ADD(0, __NR_execve); /* presumably we see this because the call failed? */
@@ -2246,6 +2248,7 @@
ADD(0, __NR_getresgid);
ADD(0, __NR_getresuid);
ADD(0, __NR_getrlimit);
+ ADD(0, __NR_getrusage);
# if defined(__NR_getsockname)
ADD(0, __NR_getsockname);
# endif
@@ -2307,6 +2310,9 @@
# if defined(__NR_sendto)
ADD(0, __NR_sendto);
# endif
+# if defined(__NR_sendmsg)
+ ADD(0, __NR_sendmsg);
+# endif
ADD(0, __NR_set_robust_list);
# if defined(__NR_set_thread_area)
ADD(0, __NR_set_thread_area);
|
|
From: Tom H. <to...@co...> - 2009-01-05 10:35:47
|
The debuginfo code has some curious kludge code in read_elf_debug_info which ignores the (correctly calculated) bss details and replaces them with a kludged version which makes certain (invalid) assumptions. Does anybody know why it does this? A related problem is that all the code for detecting global variables is assuming that they are in the data section and applying the data bias to them, which is bogus if that are really in the bss section. Of course the kludge currently means that the bss bias is the same anyway, but that is itself wrong... Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Tom H. <th...@cy...> - 2009-01-05 03:47:52
|
Nightly build on vauxhall ( x86_64, Fedora 10 ) started at 2009-01-05 03:20:07 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 481 tests, 13 stderr failures, 0 stdout failures, 0 post failures == cachegrind/tests/chdir (stderr) cachegrind/tests/clreq (stderr) cachegrind/tests/dlclose (stderr) cachegrind/tests/wrap5 (stderr) cachegrind/tests/x86/fpu-28-108 (stderr) callgrind/tests/simwork1 (stderr) callgrind/tests/simwork2 (stderr) callgrind/tests/simwork3 (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/preen_invars (stderr) memcheck/tests/linux-syscalls-2007 (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) |
|
From: Tom H. <th...@cy...> - 2009-01-05 03:47:38
|
Nightly build on trojan ( x86_64, Fedora Core 6 ) started at 2009-01-05 03:25:04 GMT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 476 tests, 9 stderr failures, 4 stdout failures, 0 post failures == drd/tests/pth_inconsistent_cond_wait (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) helgrind/tests/tc20_verifywrap (stderr) memcheck/tests/x86/bug133694 (stdout) memcheck/tests/x86/bug133694 (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/cmdline1 (stdout) none/tests/cmdline2 (stdout) none/tests/mremap2 (stdout) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 476 tests, 8 stderr failures, 4 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) helgrind/tests/tc20_verifywrap (stderr) memcheck/tests/x86/bug133694 (stdout) memcheck/tests/x86/bug133694 (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/cmdline1 (stdout) none/tests/cmdline2 (stdout) none/tests/mremap2 (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Mon Jan 5 03:36:23 2009 --- new.short Mon Jan 5 03:47:31 2009 *************** *** 8,10 **** ! == 476 tests, 8 stderr failures, 4 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) --- 8,11 ---- ! == 476 tests, 9 stderr failures, 4 stdout failures, 0 post failures == ! drd/tests/pth_inconsistent_cond_wait (stderr) exp-ptrcheck/tests/ccc (stderr) |
|
From: Tom H. <th...@cy...> - 2009-01-05 03:40:20
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2009-01-05 03:05:05 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 472 tests, 8 stderr failures, 0 stdout failures, 0 post failures == exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) helgrind/tests/tc20_verifywrap (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) |
|
From: Tom H. <th...@cy...> - 2009-01-05 03:31:38
|
Nightly build on mg ( x86_64, Fedora 9 ) started at 2009-01-05 03:10:05 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 478 tests, 14 stderr failures, 2 stdout failures, 0 post failures == cachegrind/tests/chdir (stderr) cachegrind/tests/clreq (stderr) cachegrind/tests/dlclose (stderr) cachegrind/tests/wrap5 (stderr) cachegrind/tests/x86/fpu-28-108 (stderr) callgrind/tests/simwork1 (stderr) callgrind/tests/simwork2 (stderr) callgrind/tests/simwork3 (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) memcheck/tests/linux-timerfd-syscall (stdout) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/mremap2 (stdout) |