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
|
2
(13) |
3
(29) |
|
4
(18) |
5
(12) |
6
(12) |
7
(22) |
8
(9) |
9
(14) |
10
(6) |
|
11
|
12
|
13
(1) |
14
(5) |
15
(11) |
16
(7) |
17
(5) |
|
18
(1) |
19
(8) |
20
(7) |
21
(12) |
22
(5) |
23
(17) |
24
(6) |
|
25
(27) |
26
(17) |
27
(2) |
28
(10) |
29
(3) |
30
(8) |
31
(20) |
|
From: Doug R. <df...@nl...> - 2004-01-05 20:12:03
|
On Mon, 2004-01-05 at 16:59, Jeremy Fitzhardinge wrote:
> On Mon, 2004-01-05 at 03:37, Doug Rabson wrote:
> > I think the key problem was the use of '\1' but I didn't realise that
> > until I started messing around with -E (which selects an alternative
> > regexp expression syntax). It should be possible to come up with
> > something that works on both versions of sed.
>
> Well, both versions of sed support a more complete regex syntax than
> normal sed, but they seem to do it incompatibly. GNU sed uses a lot
> more \'s, and BSD sed uses -E. We could just weaken the regexps until
> they're representable in standard sed regex syntax, but that seems like
> giving up.
The closest I can come to a regexp which works in BSD sed using the
"obsolete" regexp syntax is:
sed "s/[=-\+\*]\{2,2\}[0-9]\{1,5\}[=-\+\*]\{2,2\} //"
The main problem is that '\|' (e.g. '\(a\|b\)') isn't supported in the
obsolete syntax. It is supported in extended syntax but without as many
backslashes, (e.g. '(a|b)'). How wretched - maybe it would be better to
use perl after all.
|
|
From: Jeremy F. <je...@go...> - 2004-01-05 16:59:46
|
On Mon, 2004-01-05 at 03:37, Doug Rabson wrote: > I think the key problem was the use of '\1' but I didn't realise that > until I started messing around with -E (which selects an alternative > regexp expression syntax). It should be possible to come up with > something that works on both versions of sed. Well, both versions of sed support a more complete regex syntax than normal sed, but they seem to do it incompatibly. GNU sed uses a lot more \'s, and BSD sed uses -E. We could just weaken the regexps until they're representable in standard sed regex syntax, but that seems like giving up. J |
|
From: Nicholas N. <nj...@ca...> - 2004-01-05 16:34:53
|
Hi, A current problem with VALGRIND_OPTS is that you can't put tool-specific options in it, otherwise you'll get problems if you run a different tool. Eg. a Memcheck-specific option will cause Cachegrind to fall over. I have a patch that addresses this, whereby you can prefix an option with "--toolname:" and it will only be run where "toolname" matches the chosen tool. Eg, with this: --memcheck:--leak-check the --leak-check will only be applied for Memcheck, and ignored for other tools. The way I have coded it, this "--toolname:" prefix works in VALGRIND_OPTS or on the command line... the latter wasn't really necessary, but it doesn't seem to be a problem. I was originally thinking of using the syntax "toolname:--option", but it's easier to have "--" at the start, because stage2 considers any command line word that doesn't begin with '-' to be the start of the executable. It wouldn't be hard to allow ./.valgrindrc and ~/.valgrindrc files, too, which can contain (prefixed and non-prefixed) options, just like the VALGRIND_OPTS var. What do people think? N |
|
From: Doug R. <df...@nl...> - 2004-01-05 13:44:01
|
On Mon, 2004-01-05 at 12:45, Nicholas Nethercote wrote:
> On Mon, 5 Jan 2004, Doug Rabson wrote:
>
> > I think the key problem was the use of '\1' but I didn't realise that
> > until I started messing around with -E (which selects an alternative
> > regexp expression syntax). It should be possible to come up with
> > something that works on both versions of sed.
>
> How about this?
>
> sed "s/\(==\|--\|\+\+\|\*\*\)[0-9]\{1,5\}\(==\|--\|\+\+\|\*\*\) //" |
I'll try that this evening on FreeBSD.
|
|
From: Nicholas N. <nj...@ca...> - 2004-01-05 12:46:00
|
On Mon, 5 Jan 2004, Doug Rabson wrote:
> I think the key problem was the use of '\1' but I didn't realise that
> until I started messing around with -E (which selects an alternative
> regexp expression syntax). It should be possible to come up with
> something that works on both versions of sed.
How about this?
sed "s/\(==\|--\|\+\+\|\*\*\)[0-9]\{1,5\}\(==\|--\|\+\+\|\*\*\) //" |
While we're at it, can these lines be removed:
# Reduce some libc incompatibility
sed "s/ __getsockname / getsockname /" |
sed "s/ __sigaction / sigaction /" |
sed "s/ __GI___/ __/"
now that Jeremy did the name canonicalisation?
N
|
|
From: Doug R. <df...@nl...> - 2004-01-05 11:38:15
|
On Mon, 2004-01-05 at 10:33, Jeremy Fitzhardinge wrote: > On Mon, 2004-01-05 at 02:15, Doug Rabson wrote: > > On Mon, 2004-01-05 at 01:02, Jeremy Fitzhardinge wrote: > > > CVS commit by fitzhardinge: > > > > > > Debork regtests > > > > The '\1' reference will not work on FreeBSD. To quote the manpage: > > > > Back references are a dreadful botch, posing major problems for > > efficient implementations. They are also somewhat vaguely > > defined (does `a\(\(b\)*\2\)*d' match `abbbd'?). Avoid using > > them. > > Yep, and -E doesn't work with gnu sed - we need to fix it properly > somehow, but in the meantime we should not break the current tests. > Perhaps we should use perl, since it will be consistent across > platforms? I think the key problem was the use of '\1' but I didn't realise that until I started messing around with -E (which selects an alternative regexp expression syntax). It should be possible to come up with something that works on both versions of sed. |
|
From: Nicholas N. <nj...@ca...> - 2004-01-05 11:13:05
|
CVS commit by nethercote: Update about OS ports: mentioned Doug Rabson's FreeBSD port, and Falgrind has disappeared off the web. M +14 -5 related.html 1.4 --- devel-home/valgrind/related.html #1.3:1.4 @@ -62,7 +62,15 @@ <h3>Ports to Other Operating Systems</h3> -Some attempts have been made to port Valgrind to other systems. We haven't -tried these, but they don't seem complete. But kudos to the authors for -attempting a <i>very</i> difficult task. +Some attempts have been made to port Valgrind to other systems. + +<ul> +<li>FreeBSD: Doug Rabson has done a fairly complete port. See details in this + <a href="http://sourceforge.net/mailarchive/forum.php?thread_id=3660580&forum_id=12302"> + mailing list thread</a>. We hope to integrate this port into Valgrind. + <p> +</ul> + +We haven't tried the following ports, but they don't seem complete. But kudos +to the authors for attempting a <i>very</i> difficult task. <ul> @@ -72,6 +80,7 @@ <p> <li>FreeBSD: sos22 tried porting Valgrind, but decided a rewrite would be - simpler. The result is - <a href="http://www.srcf.ucam.org/~sos22/falgrind.html">Falgrind</a>. + simpler. The result was called Falgrind. Unfortunately, the page it was + hosted on seems to have disappeared. +<!--<a href="http://www.srcf.ucam.org/~sos22/falgrind.html">Falgrind</a>.--> <p> </ul> |
|
From: Jeremy F. <je...@go...> - 2004-01-05 10:33:50
|
On Mon, 2004-01-05 at 02:15, Doug Rabson wrote: > On Mon, 2004-01-05 at 01:02, Jeremy Fitzhardinge wrote: > > CVS commit by fitzhardinge: > > > > Debork regtests > > The '\1' reference will not work on FreeBSD. To quote the manpage: > > Back references are a dreadful botch, posing major problems for > efficient implementations. They are also somewhat vaguely > defined (does `a\(\(b\)*\2\)*d' match `abbbd'?). Avoid using > them. Yep, and -E doesn't work with gnu sed - we need to fix it properly somehow, but in the meantime we should not break the current tests. Perhaps we should use perl, since it will be consistent across platforms? J |
|
From: Doug R. <df...@nl...> - 2004-01-05 10:16:18
|
On Mon, 2004-01-05 at 01:02, Jeremy Fitzhardinge wrote: > CVS commit by fitzhardinge: > > Debork regtests The '\1' reference will not work on FreeBSD. To quote the manpage: Back references are a dreadful botch, posing major problems for efficient implementations. They are also somewhat vaguely defined (does `a\(\(b\)*\2\)*d' match `abbbd'?). Avoid using them. |
|
From: Doug R. <df...@nl...> - 2004-01-05 09:36:01
|
On Sun, 2004-01-04 at 22:05, Jeremy Fitzhardinge wrote: > On Sun, 2004-01-04 at 02:42, Doug Rabson wrote: > > Thats right. My FreeBSD system started valgrind with a stack that wasn't > > aligned to 16 bytes and this confused fix_auxv enough to corrupt the > > auxv entries given to stage2. > > Hm, I wonder if that code is ever needed... I'm not sure. I do know that the FreeBSD kernel doesn't try to align stacks properly before execve even for platforms that need special alignment. We rely on the C startup code (which we provide along with libc itself) to apply any extra alignment before calling main. > > > The main problem (I think) is that the default data size limit for > > FreeBSD is only 0.5G. We do overcommit by default but moving the brk > > this way generates valid mappings (lazy allocated zero-filled mappings > > but still valid) for the entire ~3G address space and this is greater > > than the limit. > > Yep. Then they all get unmapped again immediately afterwards. Would it > help to make a loop which increases brk by a bit, unmaps the pages, etc > until brk is at the right place? Probably not. The relavent kernel code (src/sys/vm/vm_unix.c if you want to read it) just subtracts the new brk value from the 'data section base' that the ELF loader set and compares it to RLIMIT_DATA. It care whether or not the pages are mapped. > > > Overriding brk, sbrk (and even malloc itself) is perfectly safe in > > FreeBSD and it should override all ways that the syscall can be called > > apart from a pathological use of syscall(3). I made sure that stage2 was > > able to call malloc safely with these changes although there was a > > problem with non-trivial use of malloc because stage2's copy of libc.so > > ended up being loaded very close to the end of stage2 which didn't leave > > much spare to expand the 'brk'. > > Hm, yes, the kernel gets to place it, so I guess it could do that. Can > we convince it to place it below stage2 (which is what happens on > Linux)? Actually, its /libexec/ld-elf.so.1 which gets to place libc.so and valgrind can control its placement the way it does now - by mapping other stuff over places it needs to avoid. > > > I think that RLIMIT_DATA in FreeBSD governs the virtual size of the > > brk-managed region. The libc implementation will not fall back to mmap > > if sbrk (or brk) fails. > > OK. And I presume brk/sbrk are not allowed to grow the brk segment > beyond the next mapping up. Correct. > > > > I think the best thing to do is use this as a basis for factoring all > > > the OS-specific code into OS-specific files. > > > > Right - I think that process has already been started. > > Hm. After looking at the patch in a bit more detail, the changes are > smaller than I would have guessed. I'm pleased to see that almost all > of vg_syscalls.c is common. I definitely don't want to duplicate common > stuff, nor do I want to have lots of ifdefs, so the division will need > to be more fine-grained than I first thought. There are a fair number of differences in the syscall ABIs but there was definately a lot of common ground there. I currently get a load of 'defined but not used' warnings for linux syscalls which aren't in the FreeBSD tables. Maybe separating the syscall pre and post stubs from the tables and dispatch code would be sufficient? > > I didn't really look at the differences between vg_libpthread.c and > vg_libpthread_freebsd.c, but they seemed pretty similar. Why the split? The main difference between linuxthreads and FreeBSD pthreads is that where in Linux, e.g. a mutex is declared: typedef struct pthread_mutex pthread_mutex_t; in FreeBSD it would be declared: typedef struct pthread_mutex *pthread_mutex_t; The reason for this is to remove sizeof(pthread_mutex) from the pthreads ABI which makes it easy to substitute different pthreads implementations without rebuilding client code. Currently I know of at least four pthreads implementations that use the same ABI. Coping with this difference was getting very clumsy with several ifdef sections in almost every function. Also the glibc-specific stuff ended up changing quite a bit too. In the end it seemed easier to fork the code. > > > Other things: does FreeBSD have the same sysinfo page mechanism as Linux > now? I'm not familiar with sysinfo at all, so probably not. > > And which version of FreeBSD should I download and install to try your > stuff out? Would it be the New Technology release 5.1? 5.2? My test system here is approximately a 5.2 prerelease. I would recommend installing 5.2-RC2. |
|
From: Eyal L. <ey...@ey...> - 2004-01-05 02:22:30
|
Jeremy Fitzhardinge wrote: > > On Sat, 2004-01-03 at 17:57, Eyal Lebedinsky wrote: > > Jeremy Fitzhardinge wrote: > > > Um. It would be nice if you could give us a lot more detail - like the > > > actual error message it generated, and other debugging stuff it probably > > > printed. And what do you mean by "spawn"? There's no library function > > > or syscall called that. Do you mean system? execve? > > > > OK, I now have these logs. First a good run of a program 'ssaexec' which > > simply spawn a child with the same arguments as itself. In real life it > > is > > used as a wrapper for redirecting stdout/err and such. > > OK, sync to CVS and try again. I just fixed a bug which would cause > child Valgrinds to die with a SEGV. (Though it would have only affected > CVS HEAD; 2.1.0 should have been OK.) This fixed the problem with the sample program, but my real application still goes down sig 11 with --trace-children=yes. I will try to produce another sample. I tried to get a gdb trace but: ==26406== --gdb-attach=yes conflicts with --trace-children=yes ==26406== Please choose one or the other, but not both. very funny... -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Jeremy F. <je...@go...> - 2004-01-05 01:02:48
|
CVS commit by fitzhardinge:
Debork regtests
M +1 -1 filter_stderr_basic 1.14
--- valgrind/tests/filter_stderr_basic #1.13:1.14
@@ -5,5 +5,5 @@
# Remove ==pid== and --pid-- and ++pid++ and **pid** strings
-sed -E "s/(==|--|\+\+|\*\*)[0-9]{1,5}(==|--|\+\+|\*\*) //" |
+sed "s/\(==\|--\|\+\+\|\*\*\)[0-9]\{1,5\}\1 //" |
# Remove "<name>, a <description> for x86-linux." line and the following
|