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
(9) |
2
(7) |
3
(15) |
4
(14) |
|
5
(12) |
6
(18) |
7
(16) |
8
(13) |
9
(14) |
10
(20) |
11
(26) |
|
12
(14) |
13
(25) |
14
(20) |
15
(15) |
16
(14) |
17
(13) |
18
(12) |
|
19
(8) |
20
(16) |
21
(15) |
22
(37) |
23
(15) |
24
(18) |
25
(12) |
|
26
(8) |
27
(13) |
28
(12) |
|
|
|
|
|
From: David K. <dav...@de...> - 2006-02-26 21:14:01
|
Hi,
The included patch suppresses a large number of errors such as :
==19907== Conditional jump or move depends on uninitialised value(s)
==19907== at 0x4011E5D: (within /lib/ld-2.3.6.so)
==19907== by 0x4006B1E: (within /lib/ld-2.3.6.so)
. . .
on a current Debian unstable x86 system.
If I replace /lib/ld-2.3.6.so with an unstripped version the errors go
away. This leads me to believe that Debian/glibc 2.3.6 based systems
have the same issue that caused this suppression to be added for
Ubuntu/glibc 2.3.5.
* glibc-2.3.supp (Ubuntu-stripped-ld.so) : Make this suppression more
generic so it matches a glibc 2.3.6 based system as well.
Index: glibc-2.3.supp
===================================================================
--- glibc-2.3.supp (revision 5699)
+++ glibc-2.3.supp (working copy)
@@ -576,10 +576,10 @@
{
Ubuntu-stripped-ld.so
Memcheck:Cond
- obj:/lib/ld-2.3.5.so
- obj:/lib/ld-2.3.5.so
- obj:/lib/ld-2.3.5.so
- obj:/lib/ld-2.3.5.so
- obj:/lib/ld-2.3.5.so
+ obj:/lib/ld-2.3.*
+ obj:/lib/ld-2.3.*
+ obj:/lib/ld-2.3.*
+ obj:/lib/ld-2.3.*
+ obj:/lib/ld-2.3.*
}
--
David Kimdon
Devicescape Software
|
|
From: <js...@ac...> - 2006-02-26 09:50:00
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-02-26 02:00:01 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 192 tests, 11 stderr failures, 5 stdout failures ================= memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/stack_changes (stdout) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: <js...@ac...> - 2006-02-26 04:03:49
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-02-26 03:30:01 GMT Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 223 tests, 6 stderr failures, 0 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <to...@co...> - 2006-02-26 03:44:03
|
Nightly build on dunsmere ( athlon, Fedora Core 4 ) started at 2006-02-26 03:30:07 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 225 tests, 8 stderr failures, 1 stdout failure ================= memcheck/tests/leak-tree (stderr) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-02-26 03:31:28
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-02-26 03:15:02 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 224 tests, 21 stderr failures, 1 stdout failure ================= memcheck/tests/addressable (stderr) memcheck/tests/badjump (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/mempool (stderr) memcheck/tests/partial_load_dflt (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) memcheck/tests/xml1 (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-02-26 03:27:54
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-02-26 03:00:02 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 245 tests, 7 stderr failures, 2 stdout failures ================= memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) none/tests/tls (stdout) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-02-26 03:25:19
|
Nightly build on dellow ( x86_64, Fedora Core 4 ) started at 2006-02-26 03:10:08 GMT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 245 tests, 6 stderr failures, 2 stdout failures ================= memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 245 tests, 5 stderr failures, 1 stdout failure ================= memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sun Feb 26 03:18:28 2006 --- new.short Sun Feb 26 03:25:03 2006 *************** *** 8,10 **** ! == 245 tests, 5 stderr failures, 1 stdout failure ================= memcheck/tests/x86/scalar (stderr) --- 8,12 ---- ! == 245 tests, 6 stderr failures, 2 stdout failures ================= ! memcheck/tests/leakotron (stdout) ! memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) |
|
From: Tom H. <th...@cy...> - 2006-02-26 03:22:09
|
Nightly build on aston ( x86_64, Fedora Core 3 ) started at 2006-02-26 03:05:16 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 245 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: <js...@ac...> - 2006-02-25 09:53:41
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-02-25 02:00:01 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 192 tests, 11 stderr failures, 5 stdout failures ================= memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/stack_changes (stdout) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: Eric P. <eri...@wa...> - 2006-02-25 09:18:16
|
A summary of where we stand for making Valgrind and Wine work well
together. The starting point is V 3.1.0 and Wine 0.9.7.
First of all (reminder) V & Wine now work (mostly) out of the box together.
Here's a list of (known) problems faced:
a/ missing support for some ioctl's (HDMA, serial). Added to V (now in
branch, at least of x86)
b/ missing support for tkill syscall. Added to V (now in branch), Wine
fixed to use the better tgkill syscall (0.9.8)
c/ some missing instrumentation of Wine (regarding stack manipulation).
Wine fixed (0.9.8)
d/ possibility to change EIP in signal handler. Added to V (now in
branch, for x86).
e/ trapno is not passed in signal handlers. A hacky patch proposed, and
rightfully rejected. Solution in sight (Tom Hughes), not yet in branch.
f/ missing instruction emulation in VEX (x86, and likely amd 64). Wine
needs:
push/pop [ds,es,ss]
iret (on 32bit intercall, cs not changed)(*)
int 3
cli/sti
(*) actually, Wine would require much more for 16bit emulation, but
I don't think it's reasonable, nor a short term goal, to use V &
Wine for 16bit code.
The push/pop code was easy to fix (it's already written). However
iret will be a bit trickier (I have a dirty hack for iret and int 3,
but likely Julian would rather do it himself ;-). We can try to get
rid of the cli/sti pair.
g/ missing stack backtrace information
As already explained, the first thread of a process is handled
as follows: it starts using the stack created from the process
creation (from Unix). As the process may require a larger stack
(from the Windows definition of the PE header), the Wine loader
always create a second stack at the loader startup, and switch
execution to that second stack when calling the PE module entry
point.
The outcome of this, from a V point of view, is that we get two
stacks (values are important):
- first stack at 0xBE??????
- second stack at 0x20?????? (ie below the first one).
The second stack is declared to V by Wine.
When V needs to print a backtrace (for any issue), in
get_StackTrace2 there's a test:
if (fp_min + VG_(clo_max_stackframe) <= fp_max) {
Here fp_min gets its value from the second stack (in the
0x20?????? area, and fp_max in the 0xbe?????? area). The outcome
is that no backtrace is generated :-/. Trying to remove the test
(or increase the max_stackframe value) provides some other
issues as not all the area in the 0x20????? - 0xbe000000 is
mapped, hence having a some crashes.
This one is a bit more hairy to fix. I have a patch that mixes
the max_stackframe test, with some extra test about the stacks
that are known by V (and checking that info for the backtrace
really points to the stack). But since V doesn't make use of
this information, it must be for good reasons.
The net result of this is:
- because of g/, we cannot get a full backtrace of an issue found by V.
Currently, we disabled the offending test in get_StackTrace2 pointed out
in g. With the listed side effects (crashes), and we'd like to have
something working out of the box (from the V branches)
- because of e/ and f/, we cannot use Wine and V on programs triggering
exceptions (the missing parts in e/ and f/ are only used in those
occasions).
I'd really like to see e/, f/ and g/ fixed. Let me know if you need some
help.
The good side of the story:
- we ran the regression tests (from the Wine regression test suite) on 5
DLLs under V, and fixed something like 15 potential issues and bugs
(even if some tests don't work under V yet)
- that's worth going further and run the full Wine regression tests under V.
A+
--
Eric Pouech
|
|
From: Stephen M.
|
>>>>> "NN" == Nicholas Nethercote <nj...@cs...> writes: NN> On Fri, 24 Feb 2006, Stephen McCamant wrote: SMcC> One potentially significant difference is that we still link SMcC> with glibc (I get the impression that's discouraged, but we're SMcC> loathe to give up fprintf() and friends), now statically. NN> What does fprintf() do that you need that VG_(printf)() doesn't? The usual, printing to file descriptors other than 2. So, you might ask, what does fprintf() do that VG_(sprintf)() and VG_(write)() don't? Buffering, though we haven't actually measured the speed difference. In general, there's nothing we're currently getting from glibc that couldn't be reimplemented on top of the primitives Valgrind provides, and we'd like to go in that direction eventually, but we're waiting for a reason that makes it worth the effort, and we haven't found one yet. In fact, I just checked now the list of symbols we're using from glibc (shown below). It's even longer than I'd remembered, and it includes a number of functions that have perfectly good VG_()() versions. (Many of them probably come from the readelf code that we've assimilated without much editing.) _IO_putc __assert_fail __ctype_b_loc __errno_location _exit abort atoi calloc close dup dup2 execv fclose fcntl fdopen fflush fgets fopen fopen64 fork fprintf fputc fputs fread free fscanf fseek ftell fwrite getenv getopt_long gmtime mkdir mkfifo open64 optarg pipe printf putchar puts remove setvbuf sprintf stat stderr stdout strerror strncpy strstr strtok strtoul tfind tsearch vfprintf waitpid -- Stephen |
|
From: <sv...@va...> - 2006-02-25 04:50:36
|
Author: njn
Date: 2006-02-25 04:50:26 +0000 (Sat, 25 Feb 2006)
New Revision: 5699
Log:
Previously in STOREV1 if the 4-byte word that encompassed the 1 byte bein=
g=20
written wasn't entirely addressible, we'd fall back to the slow case. No=
w,
if the 4-byte addressability test fails I check for 1-byte addressability=
.
This avoids the slow case a lot in some cases. It speeds up perf/bz2 fro=
m=20
21.5s to 19.5s on one machine, and the SPEC bzip2 benchmark with "test"=20
input goes from 208 seconds to 138 seconds.
Modified:
branches/COMPVBITS/memcheck/mc_main.c
Modified: branches/COMPVBITS/memcheck/mc_main.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/COMPVBITS/memcheck/mc_main.c 2006-02-24 10:36:54 UTC (rev 56=
98)
+++ branches/COMPVBITS/memcheck/mc_main.c 2006-02-25 04:50:26 UTC (rev 56=
99)
@@ -3171,9 +3171,13 @@
sm =3D get_secmap_readable_low(a);
sm_off =3D SM_OFF(a);
vabits8 =3D sm->vabits8[sm_off];
- if (EXPECTED_TAKEN( !is_distinguished_sm(sm) &&=20
- (VA_BITS8_READABLE =3D=3D vabits8 ||
- VA_BITS8_WRITABLE =3D=3D vabits8) ))
+ if (EXPECTED_TAKEN
+ ( !is_distinguished_sm(sm) &&
+ ( (VA_BITS8_READABLE =3D=3D vabits8 || VA_BITS8_WRITABLE =3D=3D=
vabits8)
+ || (VA_BITS2_NOACCESS !=3D extract_vabits2_from_vabits8(a, vab=
its8))
+ )
+ )
+ )
{
/* Handle common case quickly: a is mapped, the entire word32 it
lives in is addressible. */
|
|
From: <js...@ac...> - 2006-02-25 04:11:21
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-02-25 03:30:01 GMT Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 223 tests, 6 stderr failures, 0 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 223 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/leak-tree (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/tls (stdout) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sat Feb 25 03:52:53 2006 --- new.short Sat Feb 25 04:10:11 2006 *************** *** 10,12 **** ! == 223 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/leak-tree (stderr) --- 10,12 ---- ! == 223 tests, 6 stderr failures, 0 stdout failures ================= memcheck/tests/leak-tree (stderr) *************** *** 15,17 **** memcheck/tests/x86/scalar_supp (stderr) - none/tests/tls (stdout) none/tests/x86/faultstatus (stderr) --- 15,16 ---- |
|
From: Tom H. <to...@co...> - 2006-02-25 03:43:45
|
Nightly build on dunsmere ( athlon, Fedora Core 4 ) started at 2006-02-25 03:30:06 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 225 tests, 8 stderr failures, 1 stdout failure ================= memcheck/tests/leak-tree (stderr) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-02-25 03:31:26
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-02-25 03:15:03 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 224 tests, 21 stderr failures, 1 stdout failure ================= memcheck/tests/addressable (stderr) memcheck/tests/badjump (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/mempool (stderr) memcheck/tests/partial_load_dflt (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) memcheck/tests/xml1 (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-02-25 03:30:29
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-02-25 03:00:02 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 245 tests, 7 stderr failures, 2 stdout failures ================= memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) none/tests/tls (stdout) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-02-25 03:25:13
|
Nightly build on dellow ( x86_64, Fedora Core 4 ) started at 2006-02-25 03:10:11 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 245 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-02-25 03:22:13
|
Nightly build on aston ( x86_64, Fedora Core 3 ) started at 2006-02-25 03:05:12 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 245 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Nicholas N. <nj...@cs...> - 2006-02-25 01:45:48
|
On Fri, 24 Feb 2006, Stephen McCamant wrote: > One potentially significant difference is that we still > link with glibc (I get the impression that's discouraged, but we're > loathe to give up fprintf() and friends), now statically. What does fprintf() do that you need that VG_(printf)() doesn't? I have no idea about the MXCSR question... Nick |
|
From: Geoff S. <gs...@us...> - 2006-02-25 01:03:11
|
I took a look at the valgrind --tool=lackey --trace-mem=yes output. With the trace-mem implementation, adding instruction tracing here seems to make sense. So I'd like to propose two alternatives. Alternative A. A separate itrace tool, as I proposed in http://sourceforge.net/mailarchive/message.php?msg_id=14760370 Alternative B. Dovetailing itrace into lackey as follows. The biggest impact to lackey would be adding the option --trace-instr=, and changing the output format to the record-oriented one I proposed before. This would reduce volume of output while keeping postprocessing easy. I would change chapter 9 of the user manual as follows: ------------------------------------------------------ 9. LACKEY, a very simple profiler and trace tool To use this tool, specify --tool=lackey on the Valgrind command line. Lackey is a simple Valgrind tool that provides a simple trace capability and some basic program measurement. It adds quite a lot of simple instrumentation to the program's code. It is primarily intended to be of use as an example tool. _Tracing Output_ Tracing output (if specified) is generated during program execution. Lackey can provide a trace of each instruction that is executed in your program, or a trace of memory accesses, or both by showing memory accesses associated with each instruction. _Profiling Output_ Lackey reports profiling information at the conclusion of program execution. The report includes: o The number of calls to the function specified by --fnname switch o The number of conditional branches encountered and the number and proportion of those taken. o Statistics about the amount of work done during the execution of the client program: o The number of basic blocks entered and completed by the program. Note that due to optimisations done by the JIT, this is not really an accurate value. o The number of guest (x86, amd64, ppc, etc.) instructions and IR statements executed. IR is Valgrind's RISC-like intermediate representation via which all instrumentation is done. o Ratios between some of these counts. 9.2 Command-line options specific to lackey --fnname=<name> Specifies the function to profile (and trace). The default is _dl_runtime_resolve(), the function in glibc's dynamic linker that resolves function references to shared objects. --trace-extent=all,function,calltree Specifies whether to trace the entire program, the instructions in the function specified by --fnname, or all instructions from entry into the function until the function returns. The default is calltree. --trace-instrs=yes Enables tracing of instructions. --trace-mem=yes Enables tracing of memory accesses. --detailed-counts=yes Profiling output includes a table with counts of loads, stores and ALU operations for various types of operands. The types are identified by their IR name ("I1" ... "I128", "F32", "F64", and "V128"). Also prints the exit code of the client program. 9.3 Trace Output The trace output consists of an ASCII-formatted trace of the instructions executed. The format is very simple to facilitate post-processing. The first character of each line ("record") indicates what kind of data is included in the line. Trace output is provided only if enabled. --trace-instr enables H, I, J, and G records. --trace-mem=yes enables H, R, and W records. Example ("..." indicates skipped records) ==14778== valgrind-itrace, Instruction and memory tracer. ==14778== Copyright (C) 2005, and GNU GPL'd. ==14778== Using LibVEX rev 1471, a library for dynamic binary translation. ==14778== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==14778== Using valgrind-3.1.0, a dynamic binary instrumentation framework. ==14778== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==14778== For more details, rerun with: -v ==14778== H valgrind-itrace J 00244C67 55 ; dl_start ... J 08048394 55 ; main W BE8619A8 BE861A08 I 89E5 I 83EC08 I 83E4F0 I B800000000 I 83C00F I 83C00F I C1E804 I C1E004 I 29C4 I E8C7FFFFFF W BE86198C 080483B5 G J 0804837C 55 ; print W BE861988 BE8619A8 I 89E5 ... Record definitions H whatever ... Indicates the start of the trace, possibly with additional data in no specific format. J aaaa xxxx [; symbol] Instruction-with-address record. aaaa is the address of the instruction, xxxx is a byte dump of the instruction itself. All values are in hex. Optionally, a symbol name associated with the address may be provided. Note that "J" does not imply that a branch occurred, it merely indicates that the record includes the address of the instruction executed. I xxxx Instruction record for an instruction that immediately follows the previous instruction. The address can be determined from the length of the preceding instruction. G Indicates a gap in the trace. This will happen, for instance, when valgrind simulates a system call via an int 80 (on x86) or sc (on ppc) instruction, or when a branch occurs to code not being traced. R aaaaaaaa rrrr W aaaaaaaa wwwwwwww Indicates that the previous instruction caused a read of the bytes rrrr at the address, or a write of bytes wwww. The length of the read or write is indicated by the number of bytes shown. R and W records occur in logical order; for instance, an increment-memory instruction will show the read followed by the write. 9.4 Limitations Lackey runs quite slowly, especially when --detailed-counts=yes is specified. It could be made to run a lot faster by doing a slightly more sophisticated job of the instrumentation, but that would undermine its role as a simple example tool. Hence we have chosen not to do so. Memory tracing cannot catch every load and store access. See section 3.3.7 of Nicholas Nethercote's PhD dissertation "Dynamic Binary Analysis and Instrumentation", 2004, for details about the few loads and stores that is misses, and other caveats about the accuracy of the memory trace. When --trace-extent=calltree is specified, the tracing will stop only when the function returns to its caller. Tracing will not stop if the function does not return to its caller. Some examples of this are raising C++ or Ada exceptions and longjump. Also, signals and task switching may cause unexpected code to be included in the trace. |
|
From: Stephen M.
|
I've recently tried using callgrind and the self-hosting features of recent Valgrind versions in order to profile our Valgrind-based tracing and dynamic analysis tools (http://pag.csail.mit.edu/fjalar/). So far, this seems to work pretty well. However, I ran into one problem with an error coming from the following code in dispatch-x86-linux.S: /* We're leaving. Check that nobody messed with %mxcsr or %fpucw. We can't mess with %eax here as it holds the tentative return value, but any other is OK. */ #if !defined(ENABLE_INNER) /* This check fails for self-hosting, so skip in that case */ pushl $0 fstcw (%esp) cmpl $0x027F, (%esp) popl %esi /* get rid of the word without trashing %eflags */ jnz invariant_violation #endif cmpl $0, VG_(machine_x86_have_mxcsr) jz L2 pushl $0 stmxcsr (%esp) andl $0xFFFFFFC0, (%esp) /* mask out status flags */ cmpl $0x1F80, (%esp) popl %esi jnz invariant_violation L2: /* otherwise we're OK */ jmp run_innerloop_exit_REALLY (the eventual error message is: valgrind: m_scheduler/scheduler.c:994 (vgPlain_scheduler): the 'impossible' happened. valgrind: VG_(scheduler), phase 3: run_innerloop detected host state invariant failure ) Since the %fpucw check is commented out, the problems must have been coming from the %mxcsr check, and indeed when I ifdef'ed that out too, things seemed to run fine. I can't say I understand why the %fpucw check fails when you're self-hosting, but it seems at least plausible that a similar issue affects the %mxcsr check. I'm not sure what it is about our tool that tickles this problem; I didn't see similar failures with a memcheck built from a pristine valgrind source (our tool is based in part on memcheck). One potentially significant difference is that we still link with glibc (I get the impression that's discouraged, but we're loathe to give up fprintf() and friends), now statically. The computer I'm seeing this on is an older Athlon that I'm not sure even has an MXCSR register, if that makes a difference. Is ifdeffing out the second check the right fix? -- Stephen |
|
From: Josef W. <Jos...@gm...> - 2006-02-24 22:42:43
|
Hi, it had a short look over the code. On Friday 24 February 2006 13:29, Yao Qi wrote: > The output is simple, just record every instruction and memory access, > but two options in itrace are attractive, --trace-function and > --trace-calltree. The former could enable itrace to filter the output So you print out all instructions where debug info says that they are in this function, right? You decide this in the callback function, which is run for every instruction in the code. Why not decide this already in the instrumentation phase? > and only record instructions in this function you specified, while the > latter could enable itrace to record all instructions in this function > and instructions in functions called by this function. I am not sure if this very simple calltree tracing is the right thing to include into VG source. At least there should be a big warning in the code/docu that this does not work * with multithreaded code (switching to another thread while in the function will leave you with tracing on) * with signal handlers (which will be traced, too) * with functions which are left via a jump (_dl_runtime_resolve, longjmps, perhaps exception handling, handcrafted assembler ...) * only with ISAs where VEX can identify RET instructions (AFAIK for PPC the jumpkind is only a hint here as PPC has no explicit RET instructions) > I include a patch of valgrind-itrace in attachment, and please apply it > to valgrind-3.1.0. I am not the one to decide this, but I think it probably would be nice to add instruction tracing and function filtering (done at instrumentation time) to lackey. Why do you not simply provide an external tool package? You can look at the configure.in and Makefile.am's in callgrind which does exactly this (granted, with some problems regarding biarch support). Josef |
|
From: Yao Qi <qiy...@cn...> - 2006-02-24 12:30:15
|
On Fri, Feb 24, 2006 at 10:26:37AM +0100, Josef Weidendorfer wrote: > > That seems to be already violated: IMHO, lackey is already advanced tutorial stuff > about detecting memory accesses from VEX code. > And summary vs. trace output makes not a huge difference for a valgrind tool > example. The output is simple, just record every instruction and memory access, but two options in itrace are attractive, --trace-function and --trace-calltree. The former could enable itrace to filter the output and only record instructions in this function you specified, while the latter could enable itrace to record all instructions in this function and instructions in functions called by this function. For example, mostly, we are only interested in instructions in one function, they two could filter the output and only display what you want. > I did not see the source if itrace yet, but a problem to integrate it with > lackey would be if you have a lot of corner cases needing some special > handling, which would make it a bad tutorial. itrace/it_main.c is well-commented and less than 500 lines, and the code itself is simple and neat! We start itrace from lackey, and we could integrate itrace with lackey without breaking its simplicity and readability. I include a patch of valgrind-itrace in attachment, and please apply it to valgrind-3.1.0. [qiyao@plinuxt6 valgrind-3.1.0]$ patch -p1 < ../valgrind-3.1.0-itrace-notests.diff patching file configure.in patching file Makefile.am patching file docs/xml/manual.xml patching file itrace/docs/it-manual.xml patching file itrace/docs/Makefile.am patching file itrace/it_main.c patching file itrace/Makefile.am patching file itrace/tests/Makefile.am I did not add test cases into this patch, and I will submit them later when needed! -- Regards, Yao ------------ Yao Qi |
|
From: <sv...@va...> - 2006-02-24 10:36:58
|
Author: njn
Date: 2006-02-24 10:36:54 +0000 (Fri, 24 Feb 2006)
New Revision: 5698
Log:
Minor readability change.
Modified:
trunk/coregrind/m_oset.c
Modified: trunk/coregrind/m_oset.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_oset.c 2006-02-24 09:53:51 UTC (rev 5697)
+++ trunk/coregrind/m_oset.c 2006-02-24 10:36:54 UTC (rev 5698)
@@ -96,7 +96,7 @@
AvlNode* left;
AvlNode* right;
Char balance;
- Char padding[sizeof(void*)-3];
+ Char padding[sizeof(void*)-sizeof(Char)-sizeof(Short)];
Short magic;
};
=20
|
|
From: <sv...@va...> - 2006-02-24 09:53:56
|
Author: sewardj
Date: 2006-02-24 09:53:51 +0000 (Fri, 24 Feb 2006)
New Revision: 5697
Log:
Update.
Modified:
trunk/docs/internals/3_1_BUGSTATUS.txt
Modified: trunk/docs/internals/3_1_BUGSTATUS.txt
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/docs/internals/3_1_BUGSTATUS.txt 2006-02-24 09:53:11 UTC (rev 5=
696)
+++ trunk/docs/internals/3_1_BUGSTATUS.txt 2006-02-24 09:53:51 UTC (rev 5=
697)
@@ -37,7 +37,7 @@
(TODO: VERIFY 31BRANCH)
v5427 v5451 n-i-bz OSet 64-bit fastcmp bug
v5445 v5673 n-i-bz VG_(getgroups) fix (Shinichi Noda)
-vx1519 pending n-i-bz ppc32/64: allocate from callee-saved FP/VMX=
regs
+vx1519 vx1578 n-i-bz ppc32/64: allocate from callee-saved FP/VMX=
regs
v5500 v5674 n-i-bz misaligned path word-size bug in mc_main.c
vx1521/2 pending 119297 Incorrect error message for sse code
pending pending 120410 x86: prefetchw (0xF 0xD 0x48 0x4)
@@ -57,11 +57,10 @@
v5651 v5679 121901 no support for syscall tkill
=20
(next 3 are ppc32-specific FP problems)
-many pending n-i-bz ppc32 rounding mode problems
+many v5694/5 n-i-bz ppc32 rounding mode problems
Is fixed properly in head
For 31BRANCH copy in r5591 kludge
-many wontfix 119482 ppc32: mtfsb1
- [skip for 3.1.1 unless gcc/glibc requires i=
t]
+many vx1577 119482 ppc32: mtfsb1
many wontfix 120277 ppc32: fres, fctid, fctidz, frsqrte=20
[skip for 3.1.1 unless gcc/glibc requires i=
t]
=20
|