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: Tom H. <th...@cy...> - 2004-01-03 23:52:25
|
In message <3FF...@ey...>
Eyal Lebedinsky <ey...@ey...> wrote:
> Eyal Lebedinsky wrote:
> > I also need the --time-stamp patch which I mentioned on
> > the list a few times in the past, but it somehow was
> > never accepted (what do I have to get it in?). I really
> > need it for analysing reports in a client/server environment.
> > I am attaching this patch against cvs.
>
> Patch now really attached...
This feature was also requested in bug 70587 and I've just posted a
patch there to add it. It's a bit different from yours because it is
desigmed for the CVS head so can use libc's localtime instead of
having to reimplement it.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeremy F. <je...@go...> - 2004-01-03 22:40:16
|
On Sat, 2004-01-03 at 06:15, Eyal Lebedinsky wrote: > There is a problem with spawn. 2.0.0 is OK but later it went south > (2.1.0 and current). I set --trace-children=no for now (this works OK). > > Basically, I get a "child got sig 11" type message. I am moving up > to current cvs. > > > I also notice that the old way where my servers (which launch many > threads) were running with 98% idle CPU now run with 0% idle, but > the whole run seems to take at lease the same amount of time. This > suggests busy waiting. I will check the new timing options and > see which gives better performance. > > I am running on an AMD Athlon 1200 (pre-XP). Any suggestions for > which values to try? 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? Also, what does your server actually do? If you expect threads to be blocking in syscalls, which syscalls are they blocking in? The old pre-2.1 code had a tendency to wait up to a 100ms before doing anything, so if your code is syscall-heavy, it might have been using 2% CPU because the rest of the time Valgrind was just sleeping and doing nothing useful. If you run without Valgrind, what CPU usage do you get? If you're using 2.6 kernel, then there aren't really any tuneables which matter. It really depends on what your program is doing - if you have some CPU-bound threads and some IO-bound threads, then --lowlat-syscalls=yes might help, but I'd be surprised. J |
|
From: Jeremy F. <je...@go...> - 2004-01-03 22:30:49
|
On Fri, 2004-01-02 at 03:56, Doug Rabson wrote: > I've updated the port to work with the post FV valgrind. You can get a > patch against today's CVS from > http://people.freebsd.org/~dfr/valgrind-20040102-dfr.diff. That's great! I'll have a look at your latest patch in detail later today. > The only really dodgy bits in this patch are in stage1.c where I had to > stub out the stack alignment bits. The code couldn't code when the ^^^^ cope? > alignment offset wasn't exactly zero because it assumed that the new aux > entries would fit exactly into the gap. Do you mean the stuff in fix_auxv? > I also had problems moving the > brk() up past the end of stage2 so I punted on that and just overrode > brk() and sbrk() instead. Is that because FreeBSD doesn't overcommit by default? The reason for trying to get the brk base into the right place for stage2 is so that stage2 can use libraries which want to use brk (eg, libc malloc). If you override brk in stage2, will that definitely override all possible ways the brk() syscall can be called? Because it could get pretty disastrous if brk(2) accidentally got called. Also, in FreeBSD, is sbrk a syscall or just a library function? Also, what does FreeBSD's RLIMIT_DATA govern? In Linux it is effectively useless, because it only governs the brk syscall (and a.out executable BSS size). This is useless because glibc will always fall back to using mmap() if brk fails, so if brk fails because of RLIMIT_DATA, it will still keep allocating memory. I was thinking of taking advantage of this by setting RLIMIT_DATA to 0 so that I can be sure that brk(2) will always fail and not cause problems. > I had problems with vg_signals.c for the async signal handlers. > Currently FreeBSD has a bug (which will be fixed RSN) with sigaltstack > that means that all threads share the same stack setting. This meant > that async signals (intended for the proxylwp) were being delivered on > the signal stack instead of the proxylwp stack. I just changed the code > to not set SA_ONSTACK for those signals. That sounds OK. > Attaching GDB doesn't work very well with this port since we have no > equivalent of /proc/self/fd. I guess the code could be changed to > remember the exec filename and pass that instead of /proc/self/fd/$d. Yes, I was planning something like that anyway, cause all the /proc stuff is pretty non-portable. That said, the GDB attach stuff is broken anyway, because it's pretty hard to get right (it's very hard for a program to attach gdb to itself, and set its own state up into something which gdb wants to examine). In particular, the state of %ebp gets trashed as part of the exec of gdb, so gdb doesn't see a sane backtrace at the moment. > This also affected the implementation of VG_(resolve_filename) which I > worked around by using the file descriptor tracking code to lookup the > filename. For just the cases where the fd was obviously created out of a name? > I haven't tested this patch with a Linux box - my RH9 machine is several > miles away and switched off for the holidays. I've tried to keep things > decently conditional but there are almost certainly one or two nits. I think the best thing to do is use this as a basis for factoring all the OS-specific code into OS-specific files. J |
|
From: Robert W. <rj...@du...> - 2004-01-03 18:50:25
|
> Oops - that came from me. I didn't realise it was a BSD-sed thing.
I removed it, but the tests were still failing. I had to make this diff
to get the tests running on linux again:
7c7
< sed -E "s/(=3D=3D|--|\+\+|\*\*)[0-9]{1,5}(=3D=3D|--|\+\+|\*\*) //" =
|
---
> sed "s/\(=3D=3D\|--\|\+\+\|\*\*\)[0-9]\{1,5\}\(=3D=3D\|--\|\+\+\|\*\*\) /=
/" |
Regards,
Robert.
--=20
Robert Walsh
Amalgamated Durables, Inc. - "We don't make the things you buy."
Email: rj...@du...
|
|
From: Doug R. <df...@nl...> - 2004-01-03 18:49:03
|
On Sat, 2004-01-03 at 18:06, Nicholas Nethercote wrote: > On Sat, 3 Jan 2004, Doug Rabson wrote: > > > > Well done! A few people have tried this, but it sounds like you've got a > > > lot further than anyone else. Would you be able to write some kind of > > > summary describing the changes you had to make? That would be very useful > > > for people to get a grip on what you've done. > > > > I summarised most of the changes in a later message and you can get a > > patch against today's cvs at > > http://people.freebsd.org/~dfr/valgrind-20040103-dfr.diff. > > Er, which message? I only see a couple of brief descriptions... I was > thinking more along the lines of a page or two of summary -- more work for > you, I realise, but much easier for everyone else to understand than a > 130KB diff... Its earlier in this very thread. I'll just quote the relavent part: The only really dodgy bits in this patch are in stage1.c where I had to stub out the stack alignment bits. The code couldn't code when the alignment offset wasn't exactly zero because it assumed that the new aux entries would fit exactly into the gap. I also had problems moving the brk() up past the end of stage2 so I punted on that and just overrode brk() and sbrk() instead. I had problems with vg_signals.c for the async signal handlers. Currently FreeBSD has a bug (which will be fixed RSN) with sigaltstack that means that all threads share the same stack setting. This meant that async signals (intended for the proxylwp) were being delivered on the signal stack instead of the proxylwp stack. I just changed the code to not set SA_ONSTACK for those signals. Attaching GDB doesn't work very well with this port since we have no equivalent of /proc/self/fd. I guess the code could be changed to remember the exec filename and pass that instead of /proc/self/fd/$d. This also affected the implementation of VG_(resolve_filename) which I worked around by using the file descriptor tracking code to lookup the filename. > > > The most fiddly part was getting syscalls to work. FreeBSD (and probably > > all 4.4BSD derived systems) has a quite different syscall ABI with > > arguments on the stack and error-returns signalled with the carry flag. > > Add to that the fact that some (not all) syscalls return an extra 32bits > > in %edx and things get a bit tricky in vg_syscalls.c. > > That's exactly the sort of thing I'd like to see in a summary (I don't > think you mentioned this previously)... what are the details of "things > get a bit tricky"? Well the part which executes the system call has to be changed to account for the extra return values (eax, edx and eflags instead of just eax). It also needs to be able to preserve the value of edx for those syscalls which don't change its value. All the bits of code through the system which assume the linux-style error return value of -errno need to be tweaked to account for the BSD-style error return which has errno in eax and eflags.C set. Most of that can be hidden by a macro so: res = -VKI_EINVAL; changes to #define seterror(e) do {tst->m_eax = e; tst->m_eflags |= EFlagC;} while(0) ... seterror(VKI_EINVAL); |
|
From: Doug R. <df...@nl...> - 2004-01-03 18:42:47
|
Oops - that came from me. I didn't realise it was a BSD-sed thing. On Sat, 2004-01-03 at 18:38, Robert Walsh wrote: > The sed script in filter_stderr_basic had a -E creep in there some time > recently. Any idea what that is? It's not supported by gnu sed on my > Fedora Core 1 box, that's for sure, so all the tests are failing. > > Regards, > Robert. |
|
From: Robert W. <rj...@du...> - 2004-01-03 18:38:58
|
The sed script in filter_stderr_basic had a -E creep in there some time recently. Any idea what that is? It's not supported by gnu sed on my Fedora Core 1 box, that's for sure, so all the tests are failing. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Nicholas N. <nj...@ca...> - 2004-01-03 18:06:08
|
On Sat, 3 Jan 2004, Doug Rabson wrote: > > Well done! A few people have tried this, but it sounds like you've got a > > lot further than anyone else. Would you be able to write some kind of > > summary describing the changes you had to make? That would be very useful > > for people to get a grip on what you've done. > > I summarised most of the changes in a later message and you can get a > patch against today's cvs at > http://people.freebsd.org/~dfr/valgrind-20040103-dfr.diff. Er, which message? I only see a couple of brief descriptions... I was thinking more along the lines of a page or two of summary -- more work for you, I realise, but much easier for everyone else to understand than a 130KB diff... > The most fiddly part was getting syscalls to work. FreeBSD (and probably > all 4.4BSD derived systems) has a quite different syscall ABI with > arguments on the stack and error-returns signalled with the carry flag. > Add to that the fact that some (not all) syscalls return an extra 32bits > in %edx and things get a bit tricky in vg_syscalls.c. That's exactly the sort of thing I'd like to see in a summary (I don't think you mentioned this previously)... what are the details of "things get a bit tricky"? N |
|
From: Nicholas N. <nj...@ca...> - 2004-01-03 17:54:34
|
On Tue, 23 Dec 2003, Nicholas Seow wrote:
> I've been trying to get a valgrind skin i'm tinkering with to get a
> program to report whenever it calls or returns from a function. However,
> I'm getting some really wierd data.
I've attached a tool (skin) I wrote, called Sparrow, that does exactly
this. Here's some example output:
call _init
call __init_misc
call strrchr
exit strrchr
exit __init_misc
call __libc_global_ctors
call _IO_check_libio
exit _IO_check_libio
exit __libc_global_ctors
exit _init
Unfortunately, it falls over sometimes. The reason is, I maintain a stack
of activation records, and if the function returned from doesn't match
that on the top, it dies. Actually, I do some fiddling with %esp which
catches many uses of longjmp, but not all.
Generally, this function entry/exit tracking is a total pain, much harder
than you'd expect. Anyway, it might be useful for you.
N |
|
From: Dirk M. <mu...@kd...> - 2004-01-03 15:33:41
|
CVS commit by mueller: typo M +1 -1 Makefile.am 1.2 --- valgrind/coregrind/arch/Makefile.am #1.1:1.2 @@ -1,2 +1,2 @@ -SUBDIR=$(VG_PLATFORM) +SUBDIRS=$(VG_PLATFORM) |
|
From: Doug R. <df...@nl...> - 2004-01-03 15:33:36
|
On Sat, 2004-01-03 at 15:21, Dirk Mueller wrote: > CVS commit by mueller: > > infrastructure. Yes, it doesn't do much yet. Thanks! |
|
From: Dirk M. <mu...@kd...> - 2004-01-03 15:22:43
|
CVS commit by mueller: CVS_SILENT ignore M +1 -0 .cvsignore 1.8 --- valgrind/memcheck/tests/.cvsignore #1.7:1.8 @@ -56,2 +56,3 @@ threadederrno writev +zeropage |
|
From: Dirk M. <mu...@kd...> - 2004-01-03 15:22:28
|
CVS commit by mueller: CVS_SILENT ignore M +1 -0 .cvsignore 1.8 --- valgrind/none/tests/.cvsignore #1.7:1.8 @@ -44,2 +44,3 @@ *.stdout.out *.stderr.out +yield |
|
From: Dirk M. <mu...@kd...> - 2004-01-03 15:21:43
|
CVS commit by mueller:
infrastructure. Yes, it doesn't do much yet.
A coregrind/arch/.cvsignore 1.1
A coregrind/arch/Makefile.am 1.1
A coregrind/arch/x86-freebsd/.cvsignore 1.1
A coregrind/arch/x86-freebsd/Makefile.am 1.1
A coregrind/arch/x86-linux/.cvsignore 1.1
A coregrind/arch/x86-linux/Makefile.am 1.1
M +40 -28 configure.in 1.104
--- valgrind/configure.in #1.103:1.104
@@ -79,44 +79,53 @@
AC_MSG_CHECKING([for a supported OS])
+AC_SUBST(VG_PLATFORM)
case "${host_os}" in
- *linux*)
+ *linux*)
AC_MSG_RESULT([ok (${host_os})])
- ;;
+ VG_PLATFORM="x86-linux"
- *)
- AC_MSG_RESULT([no (${host_os})])
- AC_MSG_ERROR([Valgrind is Linux specific. Sorry])
- ;;
-esac
+ # Ok, this is linux. Check the kernel version
+ AC_MSG_CHECKING([for the kernel version])
+ kernel=`uname -r`
-# Ok, this is linux. Check the kernel version
-AC_MSG_CHECKING([for the kernel version])
+ case "${kernel}" in
+ 2.6.*)
+ AC_MSG_RESULT([2.6 family (${kernel})])
+ AC_DEFINE([KERNEL_2_6], 1, [Define to 1 if you're using Linux 2.6.x])
+ ;;
+
+ 2.4.*)
+ AC_MSG_RESULT([2.4 family (${kernel})])
+ AC_DEFINE([KERNEL_2_4], 1, [Define to 1 if you're using Linux 2.4.x])
+ ;;
+
+ 2.2.*)
+ AC_MSG_RESULT([2.2 family (${kernel})])
+ AC_DEFINE([KERNEL_2_2], 1, [Define to 1 if you're using Linux 2.2.x])
+ ;;
+
+ *)
+ AC_MSG_RESULT([unsupported (${kernel})])
+ AC_MSG_ERROR([Valgrind works on kernels 2.2, 2.4, 2.6])
+ ;;
+ esac
-kernel=`uname -r`
+ ;;
+
+ *freebsd*)
+ AC_MSG_RESULT([ok (${host_os})])
+ VG_PLATFORM="x86-freebsd"
-case "${kernel}" in
- 2.6.*)
- AC_MSG_RESULT([2.6 family (${kernel})])
- AC_DEFINE([KERNEL_2_6], 1, [Define to 1 if you're using Linux 2.6.x])
- ;;
-
- 2.4.*)
- AC_MSG_RESULT([2.4 family (${kernel})])
- AC_DEFINE([KERNEL_2_4], 1, [Define to 1 if you're using Linux 2.4.x])
- ;;
-
- 2.2.*)
- AC_MSG_RESULT([2.2 family (${kernel})])
- AC_DEFINE([KERNEL_2_2], 1, [Define to 1 if you're using Linux 2.2.x])
- ;;
+ ;;
*)
- AC_MSG_RESULT([unsupported (${kernel})])
- AC_MSG_ERROR([Valgrind works on kernels 2.2, 2.4, 2.6])
- ;;
+ AC_MSG_RESULT([no (${host_os})])
+ AC_MSG_ERROR([Valgrind is operating system specific. Sorry. Please consider doing a port.])
+ ;;
esac
+
AC_SUBST(DEFAULT_SUPP)
@@ -349,4 +358,7 @@
auxprogs/Makefile
coregrind/Makefile
+ coregrind/arch/Makefile
+ coregrind/arch/x86-linux/Makefile
+ coregrind/arch/x86-freebsd/Makefile
coregrind/demangle/Makefile
coregrind/docs/Makefile
|
|
From: Dirk M. <mu...@kd...> - 2004-01-03 15:03:28
|
CVS commit by mueller:
portability
M +1 -1 filter_addresses 1.3
M +6 -6 filter_stderr_basic 1.13
--- valgrind/tests/filter_addresses #1.2:1.3
@@ -1,4 +1,4 @@
#! /bin/sh
-sed "s/0x[0-9A-Fa-f]\+/0x......../g"
+sed "s/0x[0-9A-Fa-f]*/0x......../g"
--- valgrind/tests/filter_stderr_basic #1.12:1.13
@@ -5,5 +5,5 @@
# Remove ==pid== and --pid-- and ++pid++ and **pid** strings
-sed "s/\(==\|--\|\+\+\|\*\*\)[0-9]\{1,5\}\1 //" |
+sed -E "s/(==|--|\+\+|\*\*)[0-9]{1,5}(==|--|\+\+|\*\*) //" |
# Remove "<name>, a <description> for x86-linux." line and the following
@@ -12,18 +12,18 @@
# Remove other introductory lines
-sed "/Estimated CPU clock rate is [0-9]\+ MHz/d" |
+sed "/Estimated CPU clock rate is [0-9]* MHz/d" |
sed "/For more details, rerun with: -v/d" |
# Anonymise line numbers in vg_replace_malloc.c
-sed "s/vg_replace_malloc.c:[0-9]\+/vg_replace_malloc.c:.../" |
+sed "s/vg_replace_malloc.c:[0-9]*/vg_replace_malloc.c:.../" |
# Anonymise vg_intercept lines
-sed "s/vg_intercept.c:[0-9]\+/vg_intercept.c:.../" |
+sed "s/vg_intercept.c:[0-9]*/vg_intercept.c:.../" |
# Anonymise vg_libpthread lines
-sed "s/vg_libpthread.c:[0-9]\+/vg_libpthread.c:.../" |
+sed "s/vg_libpthread.c:[0-9]*/vg_libpthread.c:.../" |
# Hide suppressed error counts
-sed "s/^\(ERROR SUMMARY[^(]*(suppressed: \)[0-9]\+\( from \)[0-9]\+)$/\10\20)/" |
+sed "s/^\(ERROR SUMMARY[^(]*(suppressed: \)[0-9]*\( from \)[0-9]*)$/\10\20)/" |
|
|
From: Dirk M. <mu...@kd...> - 2004-01-03 15:03:05
|
CVS commit by mueller: portability M +2 -0 .cvsignore 1.5 M +1 -0 as_shm.c 1.2 M +7 -7 filter_fdleak 1.2 --- valgrind/corecheck/tests/.cvsignore #1.4:1.5 @@ -27,2 +27,4 @@ pth_exit vgprintf +as_shm +as_mmap --- valgrind/corecheck/tests/as_shm.c #1.1:1.2 @@ -1,2 +1,3 @@ +#include <sys/types.h> #include <sys/ipc.h> #include <sys/shm.h> --- valgrind/corecheck/tests/filter_fdleak #1.1:1.2 @@ -9,5 +9,5 @@ # Anonymise line numbers in mac_replace_strmem.c -sed "s/mac_replace_strmem.c:[0-9]\+/mac_replace_strmem.c:.../" | +sed "s/mac_replace_strmem.c:[0-9]*/mac_replace_strmem.c:.../" | $dir/../../tests/filter_test_paths | @@ -19,8 +19,8 @@ sed "s/__libc_\(.*\) (.*)$/__libc_\1 (...libc...)/" | -sed s/"^Open AF_UNIX socket [0-9]\+: <unknown>/Open AF_UNIX socket .: <unknown>/" | -sed s/"^Open \(AF_UNIX socket\|file descriptor\) [0-9]\+: \/dev\/null/Open \\1 .: \/dev\/null/" | -sed s/"^Open \(AF_UNIX socket\|file descriptor\) [0-9]\+: \/tmp\/\(sock\|data1\|data2\|file\)\.[0-9]\+/Open \\1 .: \/tmp\/\\2/" | -sed s/"^Open file descriptor [0-9]\+: .*/Open file descriptor .: ./" | -sed s/"^Open file descriptor [0-9]\+:$/Open file descriptor .:/" | -sed s/"127.0.0.1:[0-9]\+/127.0.0.1:.../g" +sed s/"^Open AF_UNIX socket [0-9]*: <unknown>/Open AF_UNIX socket .: <unknown>/" | +sed s/"^Open \(AF_UNIX socket\|file descriptor\) [0-9]*: \/dev\/null/Open \\1 .: \/dev\/null/" | +sed s/"^Open \(AF_UNIX socket\|file descriptor\) [0-9]*: \/tmp\/\(sock\|data1\|data2\|file\)\.[0-9]*/Open \\1 .: \/tmp\/\\2/" | +sed s/"^Open file descriptor [0-9]*: .*/Open file descriptor .: ./" | +sed s/"^Open file descriptor [0-9]*:$/Open file descriptor .:/" | +sed s/"127.0.0.1:[0-9]*/127.0.0.1:.../g" |
|
From: Dirk M. <mu...@kd...> - 2004-01-03 14:49:50
|
CVS commit by mueller: adding FreeBSD port made by Doug Rabson, thanks! Currently not compiled, since the autoconf magic is still missing. Will fill bits in when I have time. A vg_libpthread.c 1.1 [POSSIBLY UNSAFE: printf,system] [GPL (v2+)] A vg_syscall.S 1.1 |
|
From: Dirk M. <mu...@kd...> - 2004-01-03 14:27:48
|
CVS commit by mueller:
make it compile on FreeBSD
M +2 -0 .cvsignore 1.7
M +1 -1 bitfield1.c 1.3
M +1 -1 map_unmap.c 1.3
M +1 -1 munmap_exe.c 1.3
M +1 -0 resolv.c 1.3
M +9 -0 sha1_test.c 1.4
--- valgrind/none/tests/.cvsignore #1.6:1.7
@@ -15,5 +15,7 @@
fucomip
gxx304
+map_unmap
munmap_exe
+mremap
pluto
pth_blockedsig
--- valgrind/none/tests/bitfield1.c #1.2:1.3
@@ -1,4 +1,4 @@
-#include <malloc.h>
+#include <stdlib.h>
typedef
--- valgrind/none/tests/map_unmap.c #1.2:1.3
@@ -11,5 +11,5 @@ static unsigned int pagesize;
static void *domap(void)
{
- void *ret = mmap(0, LEN, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
+ void *ret = mmap(0, LEN, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0);
if (ret == (void *)-1) {
--- valgrind/none/tests/munmap_exe.c #1.2:1.3
@@ -12,5 +12,5 @@ int main()
void* m;
- m = mmap(NULL, 100, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
+ m = mmap(NULL, 100, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1, 0);
if (m == (void*)-1) {
--- valgrind/none/tests/resolv.c #1.2:1.3
@@ -1,3 +1,4 @@
+#include <netinet/in.h>
#include <resolv.h>
#include <stdio.h>
--- valgrind/none/tests/sha1_test.c #1.3:1.4
@@ -43,4 +43,6 @@ A million repetitions of "a"
#define SHA1HANDSOFF
+#include <config.h>
+
#include <string.h>
#include <sys/types.h> /* for u_int*_t */
@@ -64,5 +66,12 @@ void SHA1Update(SHA1_CTX* context, const
void SHA1Final(unsigned char digest[20], SHA1_CTX* context);
/* ================ end of sha1.h ================ */
+
+#ifdef HAVE_SYS_ENDIAN_H
+#include <sys/endian.h>
+#endif
+
+#ifdef HAVE_ENDIAN_H
#include <endian.h>
+#endif
#define rol(value, bits) (((value) << (bits)) | ((value) >> (32 - (bits))))
|
|
From: Dirk M. <mu...@kd...> - 2004-01-03 14:26:37
|
CVS commit by mueller: remove test for malloc.h add tests for endian.h and sys/endian.h (FreeBSD like) M +1 -1 configure.in 1.103 --- valgrind/configure.in #1.102:1.103 @@ -323,5 +323,5 @@ # Checks for header files. AC_HEADER_STDC -AC_CHECK_HEADERS([fcntl.h malloc.h stdlib.h string.h sys/socket.h sys/statfs.h sys/time.h termios.h unistd.h utime.h]) +AC_CHECK_HEADERS([fcntl.h stdlib.h string.h sys/socket.h sys/statfs.h sys/time.h sys/endian.h endian.h termios.h unistd.h utime.h]) # Checks for typedefs, structures, and compiler characteristics. |
|
From: Eyal L. <ey...@ey...> - 2004-01-03 14:24:46
|
Eyal Lebedinsky wrote: > I also need the --time-stamp patch which I mentioned on > the list a few times in the past, but it somehow was > never accepted (what do I have to get it in?). I really > need it for analysing reports in a client/server environment. > I am attaching this patch against cvs. Patch now really attached... -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Dirk M. <mu...@kd...> - 2004-01-03 14:18:41
|
CVS commit by mueller:
Fix compilation on FreeBSD. extracted from patch by Doug Rabson <df...@nl...>
M +1 -1 custom_alloc.c 1.2
M +2 -2 filter_allocs 1.3
M +1 -1 filter_leak_check_size 1.4
M +1 -1 filter_stderr 1.9
M +1 -1 manuel2.c 1.3
M +1 -1 manuel3.c 1.3
M +1 -1 metadata.c 1.2
M +1 -1 nanoleak.c 1.3
M +1 -1 realloc2.c 1.3
M +2 -2 sigaltstack.c 1.7
M +4 -4 zeropage.c 1.2
--- valgrind/memcheck/tests/custom_alloc.c #1.1:1.2
@@ -15,5 +15,5 @@ void* get_superblock(void)
{
void* p = mmap( 0, SUPERBLOCK_SIZE, PROT_READ|PROT_WRITE|PROT_EXEC,
- MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 );
+ MAP_PRIVATE|MAP_ANON, -1, 0 );
assert(p != ((void*)(-1)));
--- valgrind/memcheck/tests/filter_allocs #1.2:1.3
@@ -2,5 +2,5 @@
./filter_stderr |
-sed "s/malloc\/free: in use at exit: [0-9]\+ bytes in [0-9]\+ blocks./malloc\/free: in use at exit: ... bytes in ... blocks./" |
-sed "s/malloc.free: [0-9]\+ allocs, [0-9]\+ frees, [0-9]\+ bytes allocated./malloc\/free: ... allocs, ... frees, ... bytes allocated./"
+sed "s/malloc\/free: in use at exit: [0-9]* bytes in [0-9]* blocks./malloc\/free: in use at exit: ... bytes in ... blocks./" |
+sed "s/malloc.free: [0-9]* allocs, [0-9]* frees, [0-9]* bytes allocated./malloc\/free: ... allocs, ... frees, ... bytes allocated./"
--- valgrind/memcheck/tests/filter_leak_check_size #1.3:1.4
@@ -2,3 +2,3 @@
./filter_stderr |
-sed "s/checked [0-9]\+ bytes./checked ... bytes./"
+sed "s/checked [0-9]* bytes./checked ... bytes./"
--- valgrind/memcheck/tests/filter_stderr #1.8:1.9
@@ -9,5 +9,5 @@
# Anonymise line numbers in mac_replace_strmem.c
-sed "s/mac_replace_strmem.c:[0-9]\+/mac_replace_strmem.c:.../" |
+sed "s/mac_replace_strmem.c:[0-9]*/mac_replace_strmem.c:.../" |
$dir/../../tests/filter_test_paths |
--- valgrind/memcheck/tests/manuel2.c #1.2:1.3
@@ -1,4 +1,4 @@
#include <stdio.h>
-#include <malloc.h>
+#include <stdlib.h>
int main ()
--- valgrind/memcheck/tests/manuel3.c #1.2:1.3
@@ -1,4 +1,4 @@
#include <stdio.h>
-#include <malloc.h>
+#include <stdlib.h>
int gcc_cant_inline_me ( int );
--- valgrind/memcheck/tests/metadata.c #1.1:1.2
@@ -1,5 +1,5 @@
#include <stdio.h>
-#include <malloc.h>
+#include <stdlib.h>
#include "../memcheck.h"
--- valgrind/memcheck/tests/nanoleak.c #1.2:1.3
@@ -1,4 +1,4 @@
-#include <malloc.h>
+#include <stdlib.h>
int main ( void )
--- valgrind/memcheck/tests/realloc2.c #1.2:1.3
@@ -4,5 +4,5 @@
without error. */
-#include <malloc.h>
+#include <stdlib.h>
#include <stdio.h>
--- valgrind/memcheck/tests/sigaltstack.c #1.6:1.7
@@ -2,5 +2,5 @@
#include <stdio.h>
-#include <malloc.h>
+#include <stdlib.h>
#include <signal.h>
#include <sys/mman.h>
@@ -16,5 +16,5 @@ int main(int argv, char** argc) {
struct sigaction act;
static const int size = SIGSTKSZ*2;
- char *stk = (char *)mmap(0, size, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE, -1, 0);
+ char *stk = (char *)mmap(0, size, PROT_READ|PROT_WRITE, MAP_ANON|MAP_PRIVATE, -1, 0);
sigstk.ss_sp = stk;
--- valgrind/memcheck/tests/zeropage.c #1.1:1.2
@@ -13,5 +13,5 @@ int main(void)
/* mmap(0x0, ... FIXED) should fail */
int* m = mmap(0x0, 1000000, PROT_READ|PROT_WRITE,
- MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED, -1, 0);
+ MAP_PRIVATE|MAP_ANON|MAP_FIXED, -1, 0);
if (m != (int*)-1)
printf("succeeded?!\n");
@@ -19,5 +19,5 @@ int main(void)
/* mmap(0x1000, ... FIXED) should fail */
m = mmap((void*)0x1000, 1000000, PROT_READ|PROT_WRITE,
- MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED, -1, 0);
+ MAP_PRIVATE|MAP_ANON|MAP_FIXED, -1, 0);
if (m != (int*)-1)
printf("succeeded?!\n");
@@ -25,5 +25,5 @@ int main(void)
/* mmap(0xa000, ... FIXED) should fail */
m = mmap((void*)0xa000, 1000000, PROT_READ|PROT_WRITE,
- MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED, -1, 0);
+ MAP_PRIVATE|MAP_ANON|MAP_FIXED, -1, 0);
if (m != (int*)-1)
printf("succeeded?!\n");
@@ -31,5 +31,5 @@ int main(void)
/* mmap(0x10000, ... FIXED) should fail */
m = mmap((void*)0x10000, 1000000, PROT_READ|PROT_WRITE,
- MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED, -1, 0);
+ MAP_PRIVATE|MAP_ANON|MAP_FIXED, -1, 0);
if (m == (int*)-1)
printf("failed?!\n");
|
|
From: Eyal L. <ey...@ey...> - 2004-01-03 14:16:20
|
There is a problem with spawn. 2.0.0 is OK but later it went south (2.1.0 and current). I set --trace-children=no for now (this works OK). Basically, I get a "child got sig 11" type message. I am moving up to current cvs. I also notice that the old way where my servers (which launch many threads) were running with 98% idle CPU now run with 0% idle, but the whole run seems to take at lease the same amount of time. This suggests busy waiting. I will check the new timing options and see which gives better performance. I am running on an AMD Athlon 1200 (pre-XP). Any suggestions for which values to try? -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Eyal L. <ey...@ey...> - 2004-01-03 14:16:17
|
I have gone off the list in October and just re-enabled it. I also upgraded to 2.0.0. (and then 2.1.0) and I find that some code is using anonymous unions which the Debian stable (Woody) 2.95 compiler does not understand. Is it possible to refrain from using this? I am attaching a patch that names the unions for the cvs version. I also need the --time-stamp patch which I mentioned on the list a few times in the past, but it somehow was never accepted (what do I have to get it in?). I really need it for analysing reports in a client/server environment. I am attaching this patch against cvs. I also have problems where ASFLAGS is not being set. It may be the result of my using automake 1.5 (not 1.6) which is the one availabe for Debian Woody. -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Doug R. <df...@nl...> - 2004-01-03 13:39:18
|
On Sat, 2004-01-03 at 13:23, Nicholas Nethercote wrote: > On Sat, 27 Dec 2003, Doug Rabson wrote: > > > Since I've had a bit of festive spare time available, I thought I would > > attempt to port valgrind 2.1.0 to FreeBSD-5.x. After a bit of a > > struggle, two falls and a submission, I have most of it working well > > enough to pass most of the tests (with the notable exception of the > > pthread stuff which I haven't even tried to port yet). > > Well done! A few people have tried this, but it sounds like you've got a > lot further than anyone else. Would you be able to write some kind of > summary describing the changes you had to make? That would be very useful > for people to get a grip on what you've done. I summarised most of the changes in a later message and you can get a patch against today's cvs at http://people.freebsd.org/~dfr/valgrind-20040103-dfr.diff. The most fiddly part was getting syscalls to work. FreeBSD (and probably all 4.4BSD derived systems) has a quite different syscall ABI with arguments on the stack and error-returns signalled with the carry flag. Add to that the fact that some (not all) syscalls return an extra 32bits in %edx and things get a bit tricky in vg_syscalls.c. Still, it helped that I've been hacking the FreeBSD kernel for about eight years and understand it about as well as anyone :-) |
|
From: Nicholas N. <nj...@ca...> - 2004-01-03 13:23:13
|
On Sat, 27 Dec 2003, Doug Rabson wrote: > Since I've had a bit of festive spare time available, I thought I would > attempt to port valgrind 2.1.0 to FreeBSD-5.x. After a bit of a > struggle, two falls and a submission, I have most of it working well > enough to pass most of the tests (with the notable exception of the > pthread stuff which I haven't even tried to port yet). Well done! A few people have tried this, but it sounds like you've got a lot further than anyone else. Would you be able to write some kind of summary describing the changes you had to make? That would be very useful for people to get a grip on what you've done. N |