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
(14) |
2
(8) |
3
(7) |
|
4
(7) |
5
(7) |
6
(6) |
7
(11) |
8
(10) |
9
(14) |
10
(10) |
|
11
(13) |
12
(15) |
13
(6) |
14
(8) |
15
(6) |
16
(6) |
17
(6) |
|
18
(6) |
19
(11) |
20
(15) |
21
(14) |
22
(11) |
23
(7) |
24
(17) |
|
25
(14) |
26
(28) |
27
(21) |
28
(23) |
29
(21) |
30
(17) |
31
(8) |
|
From: <js...@ac...> - 2007-03-30 11:39:19
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2007-03-30 09:00:02 BST 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 == 219 tests, 10 stderr failures, 6 stdout failures, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/round (stdout) none/tests/ppc32/round (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: Dirk M. <dm...@gm...> - 2007-03-30 11:01:54
|
On Friday, 30. March 2007, Ashley Pittman wrote: > Errors that originate from client requests are reported as > "Uninitialised byte(s) found during client check request" and I don't > think these can be suppressed currently, it should be fairly easy to add > however. The other slightly annoying thing about them is that they > don't report the base or the length of the client request. I've removed the client request in the 2nd incarnation of the patch, since the string length determination did already issue a memcheck trace, the valgrind client request was just duplicating the same error. Greetings, Dirk |
|
From: Ashley P. <as...@qu...> - 2007-03-30 10:45:33
|
Dirk Mueller wrote: > On Friday, 30. March 2007, Ashley Pittman wrote: > >> Can you? As it's a function wrapper isn't it run in the client address >> space and and therefore currently unsuppressable? This may have changed >> without me noticing though. > > Just because it is run in the client it is suppressable (?). In any case > created a suppression to test this behaviour and it worked fine for me. Errors that originate from client requests are reported as "Uninitialised byte(s) found during client check request" and I don't think these can be suppressed currently, it should be fairly easy to add however. The other slightly annoying thing about them is that they don't report the base or the length of the client request. Ashley, |
|
From: Dirk M. <dm...@gm...> - 2007-03-30 10:39:17
|
On Friday, 30. March 2007, Ashley Pittman wrote: > Can you? As it's a function wrapper isn't it run in the client address > space and and therefore currently unsuppressable? This may have changed > without me noticing though. Just because it is run in the client it is suppressable (?). In any case created a suppression to test this behaviour and it worked fine for me. Dirk |
|
From: Dirk M. <dm...@gm...> - 2007-03-30 10:37:02
|
On Friday, 30. March 2007, Duncan Sands wrote: > > it is a documented feature of gcc to not optimize away empty loops. > Not anymore, this feature was removed in the gcc 4.x series. Not entirely true: the documentation says: However, the rationale here is that optimization of a nonempty loop cannot produce an empty one. This held for carefully written C compiled with less powerful optimizers but is not always the case for carefully written C++ or with more powerful optimizers. Thus GCC will remove operations from loops whenever it can determine those operations are not externally visible (apart from the time taken to execute them, of course). In case the loop can be proved to be finite, GCC will also remove the loop itself. In this case, there is a memory dereference involved (externally visible) and the compiler cannot prove that the loop is finite (since it doesn't know exit value of p). the next two levels of making sure the compiler doesn't optimize is volatile'ing p and calling an extern non-inline function with p after the loop. (which is a bit difficult because the vgpreload consists of only one compilation unit, I'd have to add a second one for that). Dirk |
|
From: Duncan S. <bal...@fr...> - 2007-03-30 10:13:45
|
> it is a documented feature of gcc to not optimize away empty loops. Not anymore, this feature was removed in the gcc 4.x series. Duncan. |
|
From: Ashley P. <as...@qu...> - 2007-03-30 10:00:57
|
Dirk Mueller wrote: > Plus you can still write a suppression if you really don't like > it :) Can you? As it's a function wrapper isn't it run in the client address space and and therefore currently unsuppressable? This may have changed without me noticing though. Ashley, |
|
From: Dirk M. <dm...@gm...> - 2007-03-30 09:56:27
|
On Friday, 30. March 2007, Julian Seward wrote: > - could you change 'int result' to 'Word result' (64-bit paranoia > w.r.t the horrible CALL_FN_W.. macros) done. > - how do we stop some future gcc-5.7.2 from noticing that > "if (p) while (*p++) ;" does not compute anything useful and > and therefore optimising it away? it is a documented feature of gcc to not optimize away empty loops. > Since gcc has no way to know what is going in inside the asm, it > has to believe our claim that it reads p. another solution would be to calculate len and store it in a volatile variable. Dirk |
|
From: Ashley P. <as...@qu...> - 2007-03-30 09:51:12
|
Julian Seward wrote: > Should be be in the business of checking arguments to arbitrary libc > functions? I had not realised this before, but the function wrapping > stuff makes it possible to do that if we want. It would be a nice thing to have although a whole heap of work to do it properly. Question is though should memcheck be doing this or would it require it's own tool? How much checking could you perform by taking the output of "valgrind --tool=callgrind --ct-verbose=1 ..." and piping it into another application? There are a number of functions that are done already (malloc(-1) anyone?) but they could be better because currently they only print an error, not the stack and don't play well with the xml output, changing this is another thing that's on my TODO list but I'm not sure what the correct thing to do is... Ashley, |
|
From: Dirk M. <dm...@gm...> - 2007-03-30 09:47:01
|
On Friday, 30. March 2007, Julian Seward wrote: > Oh, yes, you're right. Hang on. That's not good. I've thought about this some days ago. the reason why environment is special compared to other glibc functions is that it is something that interacts with process-external (other subprocesses for example). So it falls into the same class like the defined-ness checking for write(2) or similar syscallls, with the difference, that environment manipulation doesn't involve any significant syscalls (brk() at most). Thats why I want to add these special wrappers. No, I haven't used the code myself yet, but I've added it to the suse package and requested the bug reporter to test it ;) > Sounds reasonable; on the other hand it's a bit specialised and > would cause a false error in the case where you added an undefined > string to the environment and then never looked it up. Well, its the same like you write uninitialized memory to disk and never use it again. Plus you can still write a suppression if you really don't like it :) > Should be be in the business of checking arguments to arbitrary libc > functions? I had not realised this before, but the function wrapping > stuff makes it possible to do that if we want. A more generalized approach would be preferred, yes. So still ok to go ahead with the patch? Dirk |
|
From: Josef W. <Jos...@gm...> - 2007-03-30 09:24:50
|
On Friday 30 March 2007, Nicholas Nethercote wrote: > On Fri, 30 Mar 2007, Julian Seward wrote: > > >> So you've essentially added eager definedness checking for environment > >> variables -- is that right? > > > > Oh, yes, you're right. Hang on. That's not good. > > [...] > > Should be be in the business of checking arguments to arbitrary libc > > functions? I had not realised this before, but the function wrapping > > stuff makes it possible to do that if we want. > > Dunno, it's a bit of a slippery slope. It's a shame the origin-tracking > doesn't work very well. What are the big problems there? Josef |
|
From: Tom H. <th...@cy...> - 2007-03-30 02:31:10
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2007-03-30 03:15:02 BST 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 == 256 tests, 27 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/addressable (stderr) memcheck/tests/badjump (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-pool-0 (stderr) memcheck/tests/leak-pool-1 (stderr) memcheck/tests/leak-pool-2 (stderr) memcheck/tests/leak-pool-3 (stderr) memcheck/tests/leak-pool-4 (stderr) memcheck/tests/leak-pool-5 (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/long_namespace_xml (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/partial_load_dflt (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/xor-undef-x86 (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2007-03-30 02:23:52
|
Nightly build on dellow ( x86_64, Fedora Core 6 ) started at 2007-03-30 03:10:04 BST 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 == 291 tests, 4 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2007-03-30 02:19:10
|
Nightly build on lloyd ( x86_64, Fedora Core 3 ) started at 2007-03-30 03:05:06 BST 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 == 291 tests, 6 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2007-03-30 02:14:04
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2007-03-30 03:00:03 BST 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 == 293 tests, 6 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Nicholas N. <nj...@cs...> - 2007-03-30 00:41:05
|
On Fri, 30 Mar 2007, Julian Seward wrote: >> So you've essentially added eager definedness checking for environment >> variables -- is that right? > > Oh, yes, you're right. Hang on. That's not good. > [...] > Should be be in the business of checking arguments to arbitrary libc > functions? I had not realised this before, but the function wrapping > stuff makes it possible to do that if we want. Dunno, it's a bit of a slippery slope. It's a shame the origin-tracking doesn't work very well. Nick |
|
From: <js...@ac...> - 2007-03-30 00:17:11
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2007-03-30 02:00:01 CEST 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 == 226 tests, 6 stderr failures, 3 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/res_search (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 == 226 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Fri Mar 30 02:08:18 2007 --- new.short Fri Mar 30 02:17:07 2007 *************** *** 8,10 **** ! == 226 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) --- 8,10 ---- ! == 226 tests, 6 stderr failures, 3 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) *************** *** 17,18 **** --- 17,19 ---- none/tests/mremap2 (stdout) + none/tests/res_search (stdout) |