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
(13) |
2
(16) |
3
(10) |
4
(5) |
5
(1) |
6
|
|
7
(4) |
8
(3) |
9
(1) |
10
(1) |
11
(1) |
12
(3) |
13
(2) |
|
14
(8) |
15
(4) |
16
(17) |
17
(6) |
18
(20) |
19
(12) |
20
(1) |
|
21
(3) |
22
(17) |
23
(10) |
24
(9) |
25
|
26
|
27
(4) |
|
28
(4) |
29
(2) |
30
|
31
(5) |
|
|
|
|
From: Tom H. <th...@cy...> - 2003-12-17 18:45:20
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> Probably easier to track down, when running /opt/kde3/bin/kate on memcheck,
> there are also hundreds of messages like this:
>
> ==5883== Warning: invalid file descriptor 822 in syscall close()
> ==5883== at 0x3D505D71: close (in /lib/libc.so.6)
> ==5883== by 0x3E1FCB68: TEPty::startPgm(char const*, QValueList<QCString>&,
> char const*)
> (in /opt/kde3/lib/kde3/libkonsolepart.so)
> ==5883== by 0x3E1FD265: TEPty::commSetupDoneC() (in /opt/kde3/lib/kde3/
> libkonsolepart.so
> )
>
> running from fd=822 up to 1023. Sometimes it starts are 821 instead.
> Any ideas?
That's nothing to do with FV though is it? It looks more like something
that came from the syscall edits which cause FDs above about 822 to be
reserved for use by valgrind and that warning to be issued if the client
tries to do anything to them.
The problem is that some programs loop over all valid FDs and close
them when spawning a child or whatever, so you get that run of errors.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Julian S. <js...@ac...> - 2003-12-17 18:35:13
|
I'm experiencing some turbulence on SuSE 9. Running any program on memcheck, there are a lot more uninit-val errors reported than before. Even with 'ls'. Probably easier to track down, when running /opt/kde3/bin/kate on memcheck, there are also hundreds of messages like this: ==5883== Warning: invalid file descriptor 822 in syscall close() ==5883== at 0x3D505D71: close (in /lib/libc.so.6) ==5883== by 0x3E1FCB68: TEPty::startPgm(char const*, QValueList<QCString>&, char const*) (in /opt/kde3/lib/kde3/libkonsolepart.so) ==5883== by 0x3E1FD265: TEPty::commSetupDoneC() (in /opt/kde3/lib/kde3/ libkonsolepart.so ) running from fd=822 up to 1023. Sometimes it starts are 821 instead. Any ideas? J |
|
From: Dirk M. <mu...@kd...> - 2003-12-17 13:37:29
|
CVS commit by mueller: ignore M +1 -0 .cvsignore 1.6 M +3 -1 coregrind/.cvsignore 1.3 M +1 -0 coregrind/x86/.cvsignore 1.2 M +1 -0 include/.cvsignore 1.2 --- valgrind/.cvsignore #1.5:1.6 @@ -19,2 +19,3 @@ autom4te.cache valgrind.pc +.in_place --- valgrind/coregrind/.cvsignore #1.2:1.3 @@ -2,3 +2,5 @@ Makefile valgrind -.in_place +stage2 +vg_toolint.h +vg_toolint.c --- valgrind/coregrind/x86/.cvsignore #1.1:1.2 @@ -1,2 +1,3 @@ Makefile.in Makefile +stage2.lds --- valgrind/include/.cvsignore #1.1:1.2 @@ -1,2 +1,3 @@ Makefile.in Makefile +vg_skin.h |
|
From: Dirk M. <mu...@kd...> - 2003-12-17 13:21:18
|
CVS commit by mueller: ignore A .cvsignore 1.1 |
|
From: Tom H. <th...@cy...> - 2003-12-17 11:41:49
|
In message <1071540160.20064.65.camel@localhost.localdomain>
Jeremy Fitzhardinge <je...@go...> wrote:
> I've been testing this pretty solidly for a while, so I think it should
> work OK. No doubt you'll find some problems, but that's why I'm
> checking it in (and why we did the 2.1.0 release *before* checking it in
> - so that there's something semi-stable for people to play with).
I've just had a go with the CVS head, and I've found a couple of minor
issues with it:
With RH9 it was complaining about syscall 258 which is set_tid_address
which is called by ld.so early on, so valgrind never used to see it. A
patch to add support for this is attached.
Although simple programs worked, a debug build of one of our main
programs failed to mmap many of the shared objects. I managed to work
round this by adjusting VALGRIND_MAPSIZE in stage2.c to a little
over 300Mb in size. Debug builds of our software are somewhat extreme
in their use of shared libraries - this program had about 150 or so
and they mostly had level 3 DWARF debugging on.
I noticed that if you track FD leaks then both /usr/bin/valgrind and
the client executable are reported as leaks.
Other than that it seems fine so far...
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Josef W. <Jos...@gm...> - 2003-12-17 09:53:39
|
On Tuesday 16 December 2003 23:52, Jeremy Fitzhardinge wrote: > On Tue, 2003-12-16 at 11:10, Josef Weidendorfer wrote: > > 41000c10 <_start>: > > 41000c10: 89 e0 mov %esp,%eax > > 41000c12: e8 f9 00 00 00 call 41000d10 <_dl_start> > > You mean it's the call _dl_start? Does '--pointercheck=no' make a > difference? Yes, I think it's the call - somehow. And you are right, --pointercheck=no does change things! Now I get: =================================================== ==4743== For more details, rerun with: -v ==4743== valgrind: vg_scheduler.c:1171 (vgPlain_scheduler): Assertion `done_this_time >= 0' failed. ==4743== at 0xB8029505: vgPlain_skin_assert_fail (vg_mylibc.c:1161) ==4743== by 0xB8029504: assert_fail (vg_mylibc.c:1157) ==4743== by 0xB8029542: vgPlain_core_assert_fail (vg_mylibc.c:1168) ==4743== by 0xB800EDB4: vgPlain_scheduler (vg_scheduler.c:1206) sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==4743== at 0x81000C10: (within /lib/ld-2.3.2.so) ======================================== > I'm guessing it's something strange about your instrumentation - can you > post the output of '--trace-codegen=10001'? It shouldn't be very > long... That's another thing. --tracegen gives me nothing. If I do e.g. "valgrind -- tool=none --trace-codegen ls &>log", code generation printout in log starts at 0x81000D10. But I know for sure that my instrumentation is already called for BB 0x81000C10, as the "mov" at 0x81000C10 calls the cache simulator (seen when raising verbosity of my tool with --ct-verbose). > [Usefull info for debugging valgrind] Thanks. I will check this out later. > > Oh, I misunderstood. I thought Valgrind and the client run somehow in > > different processes and different address spaces with FV... ? > > No. I use the terms "client address space" and "Valgrind address > space", but they're both just sub-ranges within the one process address > space as far as the kernel is concerned. OK. My understanding of things should be correct now again ;-) BTW: The auto-generated stage2.lds is working fine here on Suse 9.0. Josef |