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
(17) |
2
(21) |
3
(17) |
4
(28) |
5
(21) |
6
(11) |
|
7
(13) |
8
(21) |
9
(21) |
10
(9) |
11
(11) |
12
(15) |
13
(23) |
|
14
(15) |
15
(22) |
16
(28) |
17
(12) |
18
(15) |
19
(8) |
20
(7) |
|
21
(8) |
22
(12) |
23
(13) |
24
(7) |
25
(7) |
26
(3) |
27
(9) |
|
28
(13) |
29
(7) |
30
(7) |
31
(9) |
|
|
|
|
From: Jeremy F. <je...@go...> - 2004-03-18 18:44:58
|
On Thu, 2004-03-18 at 01:19, Nicholas Nethercote wrote: > I only partly understand this thread, but reading it I'm thinking: this > all sounds very complicated for something that only(?) affects FC2... can > we avoid doing anything, or do something simple? It makes me > uncomfortable every time we have to build in some special handling for a > particular version of a library or whatever. Just an observation. No, it isn't library-specific. It's actually a new(ish) kernel interface, which libraries are starting to use. Ultimately it's cosmetic though; it's about showing the right function when we're showing the backtrace of a thread in a syscall. This patch works for me with --pointercheck=no. Unfortunately, just copying the linux-gate.so into the client address space isn't enough. J |
|
From: Tom H. <th...@cy...> - 2004-03-18 17:58:46
|
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Thu, 18 Mar 2004, Jeremy Fitzhardinge wrote:
>
> > On Wed, 2004-03-17 at 19:17, Tom Hughes wrote:
> > > corecheck/tests/pth_cancel2 (stderr)
> >
> > What's this one?
>
> I think I get that one, but only occasionally; something about a syscall
> getting interrupted. Haven't noticed it for a while, but I haven't been
> running the regtests much lately.
That's exactly what it is, yes. It only seems to happen on RH9 and
only occasionally. It complains that write() returned EINTR but I don't
see how that can happen.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-03-18 17:35:22
|
On Thu, 18 Mar 2004, Jeremy Fitzhardinge wrote: > On Wed, 2004-03-17 at 19:17, Tom Hughes wrote: > > corecheck/tests/pth_cancel2 (stderr) > > What's this one? I think I get that one, but only occasionally; something about a syscall getting interrupted. Haven't noticed it for a while, but I haven't been running the regtests much lately. N |
|
From: Jeremy F. <je...@go...> - 2004-03-18 17:28:07
|
On Wed, 2004-03-17 at 19:17, Tom Hughes wrote: > corecheck/tests/pth_cancel2 (stderr) What's this one? J |
|
From: Nicholas N. <nj...@ca...> - 2004-03-18 10:35:38
|
CVS commit by nethercote: Added VXL M +3 -0 users.html 1.58 --- devel-home/valgrind/users.html #1.57:1.58 @@ -136,4 +136,7 @@ <dt><a href="http://www.cs.unipr.it/ppl/">Parma Polyhedra Library</a> <dd>A modern C++ library for the manipulation of convex polyhedra. + +<dt><a href="http://vxl.sf.net/">VXL</a> +<dd>C++ Libraries for computer vision research and implementation. </dl> |
|
From: Nicholas N. <nj...@ca...> - 2004-03-18 10:31:13
|
On Thu, 18 Mar 2004, Tom Hughes wrote: > > I only partly understand this thread, but reading it I'm thinking: this > > all sounds very complicated for something that only(?) affects FC2... can > > we avoid doing anything, or do something simple? It makes me > > uncomfortable every time we have to build in some special handling for a > > particular version of a library or whatever. Just an observation. > > This isn't about FC2 although it will affect it. It is currently > affecting my FC builds and one of Julian's SuSE builds I think. It > will likely affect most future distributions as well. Right. I didn't really mean to cast doubt on this particular proposal. I more just wanted to gently remind everyone about the dangers of complexity; in general, just because we can do something doesn't mean we necessarily should. N |
|
From: Tom H. <th...@cy...> - 2004-03-18 09:35:42
|
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> I only partly understand this thread, but reading it I'm thinking: this
> all sounds very complicated for something that only(?) affects FC2... can
> we avoid doing anything, or do something simple? It makes me
> uncomfortable every time we have to build in some special handling for a
> particular version of a library or whatever. Just an observation.
This isn't about FC2 although it will affect it. It is currently
affecting my FC builds and one of Julian's SuSE builds I think. It
will likely affect most future distributions as well.
The visible effect is that any system call errors are reported as
being in _dl_sysinfo_int80 instead of whichever system call was being
called at the time.
Newer kernels and glibcs support a system whereby the kernel provides a
routine which glibc uses to make system calls. That allows the kernel
to replace the use of int80 for system calls with sysenter/syscall or
whatever depending on the CPU you have.
The address of that routine was originally provided by the AT_SYSINFO
entry in the auxv given to the program, and if it wasn't present then
glibc would use it's internal _dl_sysinfo_int80 routine instead which
just does things the old way.
At some point the system was changed so that rather than just
injecting code into the process the kernel actually maps a small
shared object and sets AT_SYSINFO_EHDR to point to the ELF header
for that object. It also sets AT_SYSINFO still for backwards
compatibility. Newer glibcs effectively ignore AT_SYSINFO however
unless AT_SYSINFO_EHDR is also set.
So on FC1 the kernel doesn't provide a sysinfo page anyway, so all the
stack traces appear to be in _dl_sysinfo_int80 which is why Jeremy
suggested always mapping our own sysinfo page even if the kernel
didn't supply one - currently we only replace any kernel supplied value.
That didn't work however as valgrind only provides an old style
sysinfo page rather than an ELF object so glibc ignored it. Hence
the reason that we are trying to work our how to provide a new style
sysinfo page.
As far as I know 2.6 has sysinfo support by default so this will be an
issue going forward - it isn't clear to me if 2.4 ever had it or
whether RedHat et al have been adding it. RH9 seemed to have it but
then it went away again in FC1 which is a bit odd.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-03-18 09:19:55
|
On Wed, 17 Mar 2004, Jeremy Fitzhardinge wrote: > I just got a chance to download and look at the glibc 2.3.3/FC2 sources, > which want to see the AT_SYSINFO_EHDR entry. It pretty clearly expects > to see a prelinked, premapped .so file containing the vsyscall > entrypoint. If we want to put this near the top of the client address > space, then we will need to be able to generate one of these with > different linked addresses, depending on where it has been placed. This > seems like too much hard work to me. > > The other options I can see are: [snip] I only partly understand this thread, but reading it I'm thinking: this all sounds very complicated for something that only(?) affects FC2... can we avoid doing anything, or do something simple? It makes me uncomfortable every time we have to build in some special handling for a particular version of a library or whatever. Just an observation. N |
|
From: <js...@ac...> - 2004-03-18 04:07:03
|
Nightly build on phoenix ( SuSE 8.2 ) started at 2004-03-18 04:00:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind ./seg_override sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 145 tests, 5 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) helgrind/tests/inherit (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: <js...@ac...> - 2004-03-18 03:47:01
|
Nightly build on nemesis ( SuSE 9.0 ) started at 2004-03-18 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 145 tests, 13 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/inherit (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2004-03-18 03:22:58
|
Nightly build on dunsmere ( Fedora Core 1 ) started at 2004-03-18 03:20:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow == 150 tests, 16 stderr failures, 1 stdout failure ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/inherit (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/fwrite (stderr) memcheck/tests/trivialleak (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/writev (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-03-18 03:18:09
|
Nightly build on audi ( Red Hat 9 ) started at 2004-03-18 03:15:04 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow rcrl: valgrind ./rcrl readline1: valgrind ./readline1 resolv: valgrind ./resolv seg_override: valgrind ./seg_override sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 150 tests, 2 stderr failures, 0 stdout failures ================= corecheck/tests/pth_cancel2 (stderr) helgrind/tests/inherit (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-03-18 03:13:15
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-03-18 03:10:03 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 150 tests, 6 stderr failures, 0 stdout failures ================= helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/nanoleak (stderr) memcheck/tests/trivialleak (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-03-18 03:08:15
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-03-18 03:05:03 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 150 tests, 6 stderr failures, 1 stdout failure ================= helgrind/tests/inherit (stderr) memcheck/tests/badfree-2trace (stderr) memcheck/tests/badjump (stderr) memcheck/tests/brk (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/new_nothrow (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-03-18 03:06:13
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-03-18 03:00:03 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow rcrl: valgrind ./rcrl readline1: valgrind ./readline1 resolv: valgrind ./resolv seg_override: valgrind ./seg_override sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 150 tests, 2 stderr failures, 0 stdout failures ================= helgrind/tests/inherit (stderr) memcheck/tests/badfree-2trace (stderr) make: *** [regtest] Error 1 |