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
(15) |
2
(17) |
3
(23) |
4
(13) |
5
(7) |
6
(8) |
7
(9) |
|
8
(8) |
9
(31) |
10
(31) |
11
(19) |
12
(11) |
13
(38) |
14
(14) |
|
15
(8) |
16
(11) |
17
(7) |
18
(17) |
19
(12) |
20
(12) |
21
(17) |
|
22
(19) |
23
(33) |
24
(42) |
25
(37) |
26
(23) |
27
(27) |
28
(27) |
|
29
(16) |
30
(52) |
31
(33) |
|
|
|
|
|
From: Eric E. <eri...@fr...> - 2004-08-29 21:54:42
|
Nicholas Nethercote wrote: >> What changes to the logging interface are you thinking of? So as promised, I took some time to collect all the bits I had in mind. Current problems are: * Problematic end of block detection Typically, a parser doesn't know that a block is finished until it has received the next block first line. Which may delay the displaying of last error. * Problematic process end detection Because the logging socket is (re)used as-is in forked processes, and is not always closed (maybe a small bug), knowing that a specific vg'ified has exited requires to log at least the exit status (which I did in my patch) * The streams are multiplexed after a fork, even when using --log-socket. Some internal reporting doesn't prefix with the pid, so knowing exactly where an untagged error line should go is tricky. * Parsing the generated stream requires many small kludges, which tends to make any parser relatively fragile, and may slowdown any improvement which may break existing parsers. Especially if --verbose is used. The future issues which may arise: * Localization * People may want to generate reports in different formats (xml, html, colored vt, sql, ...) * People may want valgrind not to read debug infos, and report addresses as-is, to be interpreted afterwards - Faster and less mem/disk usage when tracing very large sets of processes - Faster for people not processing the results (QA teams, ...) - Could help debugging deployed applications - Reports may be processed by proprietary vendors * Attaching user data (strings, stacks, ...) to runtime elements (mem blocks, fds, threads) to be reported in logs * Errors should have some kind of severity attribute, to help users (and parsers if they don't know the error) * Users may want to have a shorter description of the errors, e.g. I translate an "invalid read" with freeing stack into a 'FMR' (Free Memory Read) or an "invalid free" with freeing stack into a 'DMF' (Double Memory Free), etc. As for the communication stream (only in console for now, with as-gdb-attach), we may want (when tracing children) to ask the user if a particular forked/exec'd process must be traced or not, optionally with different vg options from its parent. Here were my first thoughts I have certainly missed things. Comments welcome ;-) Cheers -- Eric |
|
From: Chris J. <ch...@at...> - 2004-08-29 20:43:30
|
> On Fri, 27 Aug 2004, Jeremy Fitzhardinge wrote: >=20 > >> Idle thought: could we provide a malloc (and friends) that=20 > libc could=20 > >> use, that's just a wrapper around out VG_(malloc) stuff? =20 > That way we=20 > >> could use lots of goodies from libc, like printf, the=20 > resolver code,=20 > >> etc. > > > > Very tricky, because glibc has all that nasty short-circuiting=20 > > machinery. Calls internal to glibc don't use the normal dynamic=20 > > linker name resolution rules, so you can't override calls=20 > to malloc,=20 > > etc. Or you can override some calls, but not all... >=20 > and this kind of thing makes me wonder if there are any other=20 > nasty traps=20 > waiting inside glibc to grip us up if we start using it more... I wrote a skin that used a fairly large number of glibc functions that worked fine so long as I overrode malloc, free, etc. It's important to = strip out any reference to pthread_*, _pthread_* and __pthread_* symbols in = the object files though. Chris January |
|
From: Tom H. <th...@cy...> - 2004-08-29 14:42:14
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Fri, 27 Aug 2004, Paul Mackerras wrote:
>
> > In fact the correct switch for linking is -pie. It seems you still
> > need -fpie for compiling, although I would have expected -pie to imply
> > -fpie.
>
> What would the configure-time test for PIE support involve?
Something like this should do it:
Index: configure.in
===================================================================
RCS file: /home/kde/valgrind/configure.in,v
retrieving revision 1.120
diff -u -u -r1.120 configure.in
--- configure.in 29 Aug 2004 09:46:38 -0000 1.120
+++ configure.in 29 Aug 2004 14:39:30 -0000
@@ -345,7 +345,18 @@
AC_SUBST(PREFERRED_STACK_BOUNDARY)
-
+# Check for PIE support in the compiler and linker
+AC_CACHE_CHECK([for PIE support], vg_cv_pie,
+ [safe_CFLAGS=$CFLAGS
+ CFLAGS="$CFLAGS -fpie"
+ safe_LDFLAGS=$LDFLAGS
+ LDFLAGS="$LDFLAGS -pie"
+ AC_TRY_LINK([int foo;],
+ [],
+ [vg_cv_pie=yes],
+ [vg_cv_pie=no])
+ CFLAGS=$safe_CFLAGS
+ LDFLAGS=$safe_LDFLAGS])
# Checks for header files.
AC_HEADER_STDC
That was stolen from glibc and then rewritten more in the style
suggested by the autoconf documentation. After that vg_cv_pie should
be set to yes if PIE support is available.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Bob F. <bfr...@si...> - 2004-08-29 14:40:06
|
On Sun, 29 Aug 2004, Tom Hughes wrote: >> >> That's useful, but AFAICT automake does not allow you to use different >> compilation flags for different modules within the same program/library. > > Presumably you can always build the files which need different > flags into a library and then build the final program/library > against that library? Yes. Libtool "convenience" libraries can easily be used for this task. Of course this introduces libtool into the equation. Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
|
From: Nicholas N. <nj...@ca...> - 2004-08-29 13:42:18
|
On Fri, 27 Aug 2004, Jeremy Fitzhardinge wrote: >> Idle thought: could we provide a malloc (and friends) that libc could >> use, that's just a wrapper around out VG_(malloc) stuff? That way we >> could use lots of goodies from libc, like printf, the resolver code, >> etc. > > Very tricky, because glibc has all that nasty short-circuiting > machinery. Calls internal to glibc don't use the normal dynamic linker > name resolution rules, so you can't override calls to malloc, etc. Or > you can override some calls, but not all... and this kind of thing makes me wonder if there are any other nasty traps waiting inside glibc to grip us up if we start using it more... N |
|
From: Nicholas N. <nj...@ca...> - 2004-08-29 13:41:03
|
On Fri, 27 Aug 2004, Paul Mackerras wrote: > In fact the correct switch for linking is -pie. It seems you still > need -fpie for compiling, although I would have expected -pie to imply > -fpie. What would the configure-time test for PIE support involve? N |
|
From: Nicholas N. <nj...@ca...> - 2004-08-29 12:17:31
|
On Sun, 29 Aug 2004, Tom Hughes wrote: >> That's useful, but AFAICT automake does not allow you to use different >> compilation flags for different modules within the same program/library. > > Presumably you can always build the files which need different > flags into a library and then build the final program/library > against that library? Hmm, I guess. Pretty kludgey way to have to do it. N |
|
From: Tom H. <th...@cy...> - 2004-08-29 11:48:33
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Sat, 28 Aug 2004, Bob Friesenhahn wrote:
>
> > Automake allows you to set compilation flags on a per-program (or
> > per-library) basis. A single source file can be included in several programs,
> > and it will potentially be compiled with different flags for each program.
> > That means if these objects are put in a library you could do:
> >
> > lib_vgfoopic_SOURCES=vg_replace_malloc.c vg_intercept.c vg_libpthread.c
> > lib_vgfoopic_CFLAGS=-fno-omit-frame-pointer -g -fPIC
> >
> > lib_vgnonpic_SOURCES=vg_replace_malloc.c vg_intercept.c vg_libpthread.c
> > lib_vgnonpic_CFLAGS=-fno-omit-frame-pointer -g
>
> That's useful, but AFAICT automake does not allow you to use different
> compilation flags for different modules within the same program/library.
Presumably you can always build the files which need different
flags into a library and then build the final program/library
against that library?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-08-29 11:43:02
|
On Sat, 28 Aug 2004, Bob Friesenhahn wrote: > Automake allows you to set compilation flags on a per-program (or > per-library) basis. A single source file can be included in several programs, > and it will potentially be compiled with different flags for each program. > That means if these objects are put in a library you could do: > > lib_vgfoopic_SOURCES=vg_replace_malloc.c vg_intercept.c vg_libpthread.c > lib_vgfoopic_CFLAGS=-fno-omit-frame-pointer -g -fPIC > > lib_vgnonpic_SOURCES=vg_replace_malloc.c vg_intercept.c vg_libpthread.c > lib_vgnonpic_CFLAGS=-fno-omit-frame-pointer -g That's useful, but AFAICT automake does not allow you to use different compilation flags for different modules within the same program/library. N |
|
From: Tom H. <th...@cy...> - 2004-08-29 09:46:44
|
CVS commit by thughes: Switch to using the newer forms of AC_INIT and AM_INIT_AUTOMAKE so that configure can print the package name correctly. M +3 -2 configure.in 1.120 --- valgrind/configure.in #1.119:1.120 @@ -1,6 +1,7 @@ # Process this file with autoconf to produce a configure script. -AC_INIT(coregrind/vg_main.c) # give me a source file, any source file... +AC_INIT(Valgrind, 2.1.3.CVS, val...@li...) +AC_CONFIG_SRCDIR(coregrind/vg_main.c) AM_CONFIG_HEADER(config.h) -AM_INIT_AUTOMAKE(valgrind, 2.1.3.CVS) +AM_INIT_AUTOMAKE AM_MAINTAINER_MODE |
|
From: Tom H. <th...@cy...> - 2004-08-29 03:08:24
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-08-29 03:00:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow badrw: valgrind -q ./badrw brk: valgrind ./brk brk2: valgrind ./brk2 buflen_check: valgrind -q ./buflen_check clientperm: valgrind -q ./clientperm custom_alloc: valgrind -q ./custom_alloc doublefree: valgrind -q ./doublefree error_counts: valgrind --log-fd=-1 ./error_counts errs1: valgrind -q ./errs1 execve: valgrind -q ./execve execve2: valgrind -q --trace-children=yes ./execve2 exitprog: valgrind -q ./exitprog fpeflags: valgrind -q ./fpeflags fprw: valgrind -q ./fprw fwrite: valgrind -q ./fwrite inits: valgrind -q ./inits inline: valgrind -q ./inline insn_basic: valgrind -q ./../../none/tests/insn_basic Could not read `insn_basic.stderr.exp' make: *** [regtest] Error 2 |
|
From: <js...@ac...> - 2004-08-29 02:55:31
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2004-08-29 03:50:00 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow sem: valgrind ./sem 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 ---------------------------------------- == 174 tests, 4 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2004-08-29 02:25:22
|
Nightly build on dunsmere ( Fedora Core 2 ) started at 2004-08-29 03:20:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow 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 ---------------------------------------- == 179 tests, 8 stderr failures, 1 stdout failure ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/writev (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-08-29 02:19:31
|
Nightly build on audi ( Red Hat 9 ) started at 2004-08-29 03:15:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow 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 ---------------------------------------- == 179 tests, 8 stderr failures, 0 stdout failures ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-08-29 02:13:36
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-08-29 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 sem: valgrind ./sem 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 ---------------------------------------- == 179 tests, 3 stderr failures, 0 stdout failures ================= helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-08-29 02:08:21
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-08-29 03:05:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests ---------------------------------------- == 179 tests, 14 stderr failures, 1 stdout failure ================= addrcheck/tests/toobig-allocs (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/badjump (stderr) memcheck/tests/brk (stderr) memcheck/tests/brk2 (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/mismatches (stderr) memcheck/tests/new_nothrow (stderr) memcheck/tests/new_override (stderr) memcheck/tests/toobig-allocs (stderr) memcheck/tests/writev (stderr) none/tests/coolo_sigaction (stderr) none/tests/gxx304 (stderr) make: *** [regtest] Error 1 |