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
(8) |
2
(11) |
3
(21) |
4
(15) |
5
(10) |
|
6
(7) |
7
(7) |
8
(5) |
9
(7) |
10
(5) |
11
(1) |
12
(21) |
|
13
(8) |
14
(17) |
15
(6) |
16
(10) |
17
(7) |
18
(6) |
19
(15) |
|
20
(12) |
21
(16) |
22
(25) |
23
(14) |
24
(10) |
25
(7) |
26
(6) |
|
27
(34) |
28
(13) |
29
(10) |
30
(8) |
|
|
|
|
From: Tom H. <th...@cy...> - 2004-06-04 21:42:25
|
CVS commit by thughes:
There is no __accept in any libc or libpthread that I can find so
it isn't clear why we were intercepting that and only aliasing accept
to it. Switched to intercepting accept directly instead.
CCMAIL: 768...@bu...
M +4 -4 vg_libpthread.c 1.153
--- valgrind/coregrind/vg_libpthread.c #1.152:1.153
@@ -2067,12 +2067,12 @@ int sigaction(int signum,
typedef
-int (*__accept_t)(int fd, struct sockaddr *addr, socklen_t *len);
+int (*accept_t)(int fd, struct sockaddr *addr, socklen_t *len);
-WEAK int __accept(int fd, struct sockaddr *addr, socklen_t *len)
+WEAK
+int accept(int fd, struct sockaddr *addr, socklen_t *len)
{
__my_pthread_testcancel();
- return FORWARD(__accept, fd, addr, len);
+ return FORWARD(accept, fd, addr, len);
}
-strong_alias(__accept, accept);
typedef
|
|
From: Nicholas N. <nj...@ca...> - 2004-06-04 09:42:52
|
On Fri, 4 Jun 2004, Josef Weidendorfer wrote: > > Could V use its interception mechanism here? Likewise for malloc() et al > > for statically linked binaries? > > This would be at compile time: the user has to link with V'pthread then. Or is > this already possible? Not necessarily; AIUI, V has a mechanism whereby if it's told to translate some code that in at the start of a particular function which it wants to intercept, it doesn't translate the original but translates its own version instead. But I could be wrong... N |
|
From: Josef W. <Jos...@gm...> - 2004-06-04 09:35:35
|
On Friday 04 June 2004 09:59, Nicholas Nethercote wrote: > On Fri, 4 Jun 2004, Tom Hughes wrote: > > I wasn't sure it would work even without valgrind because of the way > > libpthread normally uses dynamic linker tricks to override functions > > in the main C library but I guess there must be weak symbol tricks or > > something to make it work in static links. > > Could V use its interception mechanism here? Likewise for malloc() et al > for statically linked binaries? This would be at compile time: the user has to link with V'pthread then. Or is this already possible? Josef |
|
From: Nicholas N. <nj...@ca...> - 2004-06-04 07:59:36
|
On Fri, 4 Jun 2004, Tom Hughes wrote: > > I guess V's libpthread.so isn't overriding the statically linked system > > one. > > Well it won't - if you're statically linked against libpthread then > the dynamic linker won't try and load the dynamic version because it > won't be listed as a dependency and all the calls to the functions in > it will have been resolved anyway. > > I wasn't sure it would work even without valgrind because of the way > libpthread normally uses dynamic linker tricks to override functions > in the main C library but I guess there must be weak symbol tricks or > something to make it work in static links. Could V use its interception mechanism here? Likewise for malloc() et al for statically linked binaries? N |
|
From: Nicholas N. <nj...@ca...> - 2004-06-04 07:58:29
|
CVS commit by nethercote: Added notes about statically linked multi-threaded programs not working. M +9 -6 faq.html 1.4 --- devel-home/valgrind/faq.html #1.3:1.4 @@ -228,10 +228,13 @@ For versions 2.1.1 and later: -Valgrind does now work with static binaries, although beware that some -of the tools won't operate as well as normal, because they have access -to less information about how the program runs. Eg. Memcheck will miss -some errors that it would otherwise find. This is because Valgrind -doesn't replace malloc() and friends with its own versions. It's best -if your program is dynamically linked with glibc. +Valgrind does now work with single-threaded static binaries, although +beware that some of the tools won't operate as well as normal, because +they have access to less information about how the program runs. Eg. +Memcheck will miss some errors that it would otherwise find. This is +because Valgrind doesn't replace malloc() and friends with its own +versions. Valgrind won't work with multi-threaded static binaries, +as Valgrind won't be able to use its own pthreads implementation. + +In short, it's best if your program is dynamically linked. ----------------------------------------------------------------- |
|
From: Tom H. <th...@cy...> - 2004-06-04 07:56:17
|
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Thu, 3 Jun 2004, Tom Hughes wrote:
>
>> The only thing I'm not sure about is statically linked programs
>> but I'm not sure you can statically link a multithreaded program.
>
> You can -- I just tried it. But Memcheck didn't like it, gave lots of
> uninitialised warnings and then bombed out with:
>
> ==29475== Valgrind detected that your program requires
> ==29475== the following unimplemented functionality:
> ==29475== clone(): not supported by Valgrind.
> We do now support programs linked against
> libpthread.so, though. Re-run with -v and ensure that
> you are picking up Valgrind's implementation of libpthread.so.
>
> I guess V's libpthread.so isn't overriding the statically linked system
> one.
Well it won't - if you're statically linked against libpthread then
the dynamic linker won't try and load the dynamic version because it
won't be listed as a dependency and all the calls to the functions in
it will have been resolved anyway.
I wasn't sure it would work even without valgrind because of the way
libpthread normally uses dynamic linker tricks to override functions
in the main C library but I guess there must be weak symbol tricks or
something to make it work in static links.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeremy F. <je...@go...> - 2004-06-04 07:53:12
|
On Thu, 2004-06-03 at 23:51 +0100, Tom Hughes wrote: > Note that it isn't the __libc_xxx > functions I'm forwarding to, it's the original names that are being > overridden by the pthread library. Right, OK. > The only thing I'm not sure about is statically linked programs > but I'm not sure you can statically link a multithreaded program. You can, but we basically lose. > > I was just working on an alternative fix for this by having private > > versions of the __libc_ functions, at least for syscalls. > > The problem is that even the ones that appear to be simple system > call wrappers aren't always - witness the fcntl issue where it > sometimes calls the fcntl64 system call instead. Yeah, I wasn't relishing debugging all that. Your approach looks fine. J |
|
From: Nicholas N. <nj...@ca...> - 2004-06-04 07:42:09
|
On Thu, 3 Jun 2004, Tom Hughes wrote:
> > > Changed cancellation wrappers to use dlsym(RTLD_NEXT) to look up the
> > > libc version of the wrapped function when forwarding the call rather
> > > than trying to call the internal __libc_xxx version of the routine
> > > as many of those are marked as GLIBC_PRIVATE in recent releases.
> >
> > Will this work if libc is stripped?
>
> You can't strip the dynamic symbol table from a shared library if
> you want it to actually work... Note that it isn't the __libc_xxx
> functions I'm forwarding to, it's the original names that are being
> overridden by the pthread library.
>
> The only thing I'm not sure about is statically linked programs
> but I'm not sure you can statically link a multithreaded program.
You can -- I just tried it. But Memcheck didn't like it, gave lots of
uninitialised warnings and then bombed out with:
==29475== Valgrind detected that your program requires
==29475== the following unimplemented functionality:
==29475== clone(): not supported by Valgrind.
We do now support programs linked against
libpthread.so, though. Re-run with -v and ensure that
you are picking up Valgrind's implementation of libpthread.so.
I guess V's libpthread.so isn't overriding the statically linked system
one.
N
|
|
From: <js...@ac...> - 2004-06-04 02:55:10
|
Nightly build on phoenix ( SuSE 8.2 ) started at 2004-06-04 04:00:00 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 153 tests, 12 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) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: <js...@ac...> - 2004-06-04 02:26:03
|
Nightly build on nemesis ( SuSE 9.0 ) started at 2004-06-04 03:50:00 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 153 tests, 12 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) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2004-06-04 02:23:17
|
Nightly build on dunsmere ( Fedora Core 2 ) started at 2004-06-04 03:20:01 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow readline1: valgrind ./readline1 resolv: valgrind ./resolv seg_override: valgrind ./seg_override semlimit: valgrind ./semlimit 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 ---------------------------------------- == 158 tests, 1 stderr failure, 1 stdout failure ================= corecheck/tests/pth_cancel2 (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-06-04 02:17:59
|
Nightly build on audi ( Red Hat 9 ) started at 2004-06-04 03:15:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert rcrl: valgrind ./rcrl readline1: valgrind ./readline1 resolv: valgrind ./resolv seg_override: valgrind ./seg_override semlimit: valgrind ./semlimit 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 ---------------------------------------- == 158 tests, 0 stderr failures, 0 stdout failures ================= |
|
From: Tom H. <th...@cy...> - 2004-06-04 02:13:35
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-06-04 03:10:02 BST 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 semlimit: valgrind ./semlimit 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 ---------------------------------------- == 158 tests, 4 stderr failures, 0 stdout failures ================= helgrind/tests/deadlock (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-06-04 02:08:05
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-06-04 03:05:02 BST 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 ---------------------------------------- == 158 tests, 5 stderr failures, 1 stdout failure ================= 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-06-04 02:07:23
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-06-04 03:00:02 BST 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 semlimit: valgrind ./semlimit 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 ---------------------------------------- == 158 tests, 1 stderr failure, 0 stdout failures ================= memcheck/tests/badfree-2trace (stderr) make: *** [regtest] Error 1 |