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
(23) |
2
(15) |
|
3
|
4
|
5
|
6
|
7
(3) |
8
(22) |
9
(12) |
|
10
|
11
|
12
(1) |
13
(13) |
14
(4) |
15
(12) |
16
|
|
17
(5) |
18
(13) |
19
(6) |
20
(10) |
21
(17) |
22
|
23
(3) |
|
24
(18) |
25
(17) |
26
(12) |
27
|
28
(1) |
29
(3) |
30
(12) |
|
From: Tom H. <to...@co...> - 2013-11-21 03:56:19
|
valgrind revision: 13715 VEX revision: 2799 C compiler: gcc (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2) GDB: GNU gdb (GDB) Fedora (7.3.1-48.fc15) Assembler: GNU assembler version 2.21.51.0.6-6.fc15 20110118 C library: GNU C Library stable release version 2.14.1 uname -mrs: Linux 3.9.5-301.fc19.x86_64 x86_64 Vendor version: Fedora release 15 (Lovelock) Nightly build on bristol ( x86_64, Fedora 15 ) Started at 2013-11-21 03:14:05 GMT Ended at 2013-11-21 03:56: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 == 672 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/origin5-bz2 (stderr) |
|
From: Tom H. <to...@co...> - 2013-11-21 03:47:05
|
valgrind revision: 13715 VEX revision: 2799 C compiler: gcc (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2) GDB: GNU gdb (GDB) Fedora (7.3.50.20110722-16.fc16) Assembler: GNU assembler version 2.21.53.0.1-6.fc16 20110716 C library: GNU C Library development release version 2.14.90 uname -mrs: Linux 3.9.5-301.fc19.x86_64 x86_64 Vendor version: Fedora release 16 (Verne) Nightly build on bristol ( x86_64, Fedora 16 ) Started at 2013-11-21 03:02:20 GMT Ended at 2013-11-21 03:46:47 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 == 672 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/origin5-bz2 (stderr) |
|
From: Tom H. <to...@co...> - 2013-11-21 03:33:36
|
valgrind revision: 13715 VEX revision: 2799 C compiler: gcc (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2) GDB: GNU gdb (GDB) Fedora (7.4.50.20120120-54.fc17) Assembler: GNU assembler version 2.22.52.0.1-10.fc17 20120131 C library: GNU C Library stable release version 2.15 uname -mrs: Linux 3.9.5-301.fc19.x86_64 x86_64 Vendor version: Fedora release 17 (Beefy Miracle) Nightly build on bristol ( x86_64, Fedora 17 (Beefy Miracle) ) Started at 2013-11-21 02:51:39 GMT Ended at 2013-11-21 03:33:17 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 == 672 tests, 5 stderr failures, 1 stdout failure, 0 stderrB failures, 0 stdoutB failures, 0 post failures == gdbserver_tests/mcinfcallRU (stderr) gdbserver_tests/mcinfcallWSRU (stderr) gdbserver_tests/mcmain_pic (stderr) memcheck/tests/origin5-bz2 (stderr) exp-sgcheck/tests/preen_invars (stdout) exp-sgcheck/tests/preen_invars (stderr) |
|
From: Tom H. <to...@co...> - 2013-11-21 03:18:53
|
valgrind revision: 13715 VEX revision: 2799 C compiler: gcc (GCC) 4.7.2 20121109 (Red Hat 4.7.2-8) GDB: GNU gdb (GDB) Fedora 7.5.1-42.fc18 Assembler: GNU assembler version 2.23.51.0.1-10.fc18 20120806 C library: GNU C Library stable release version 2.16 uname -mrs: Linux 3.9.5-301.fc19.x86_64 x86_64 Vendor version: Fedora release 18 (Spherical Cow) Nightly build on bristol ( x86_64, Fedora 18 (Spherical Cow) ) Started at 2013-11-21 02:41:41 GMT Ended at 2013-11-21 03:18:37 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 == 672 tests, 2 stderr failures, 1 stdout failure, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/origin5-bz2 (stderr) exp-sgcheck/tests/preen_invars (stdout) exp-sgcheck/tests/preen_invars (stderr) |
|
From: Tom H. <to...@co...> - 2013-11-21 03:09:08
|
valgrind revision: 13715 VEX revision: 2799 C compiler: gcc (GCC) 4.8.2 20131017 (Red Hat 4.8.2-1) GDB: GNU gdb (GDB) Fedora 7.6.1-42.fc19 Assembler: GNU assembler version 2.23.52.0.1-9.fc19 20130226 C library: GNU C Library (GNU libc) stable release version 2.17 uname -mrs: Linux 3.9.5-301.fc19.x86_64 x86_64 Vendor version: Fedora release 19 (Schrödingerâs Cat) Nightly build on bristol ( x86_64, Fedora 19 (Schrödingerâs Cat) ) Started at 2013-11-21 02:32:01 GMT Ended at 2013-11-21 03:08:52 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 == 672 tests, 3 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/dw4 (stderr) memcheck/tests/origin5-bz2 (stderr) exp-sgcheck/tests/hackedbz2 (stderr) |
|
From: Rich C. <rc...@wi...> - 2013-11-21 02:36:01
|
valgrind revision: 13715
VEX revision: 2799
C compiler: gcc (SUSE Linux) 4.8.1 20130909 [gcc-4_8-branch revision 202388]
GDB: GNU gdb (GDB; openSUSE Factory) 7.6.50.20130731-cvs
Assembler: GNU assembler (GNU Binutils; openSUSE Factory) 2.23.2
C library: GNU C Library (GNU libc) stable release version 2.18 (git )
uname -mrs: Linux 3.11.4-3-desktop x86_64
Vendor version: Welcome to openSUSE 13.1 "Bottle" Beta 1 - Kernel %r (%t).
Nightly build on rodan ( Linux 3.11.4-3-desktop x86_64 )
Started at 2013-11-20 19:22:01 CST
Ended at 2013-11-20 20:35:48 CST
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
== 587 tests, 8 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
memcheck/tests/dw4 (stderr)
memcheck/tests/err_disable3 (stderr)
memcheck/tests/err_disable4 (stderr)
memcheck/tests/origin5-bz2 (stderr)
memcheck/tests/threadname (stderr)
memcheck/tests/threadname_xml (stderr)
drd/tests/pth_mutex_reinit (stderr)
exp-sgcheck/tests/hackedbz2 (stderr)
=================================================
./valgrind-new/drd/tests/pth_mutex_reinit.stderr.diff
=================================================
--- pth_mutex_reinit.stderr.exp 2013-11-20 19:59:26.198551681 -0600
+++ pth_mutex_reinit.stderr.out 2013-11-20 20:29:22.141015960 -0600
@@ -1,11 +1,15 @@
+The object at address 0x........ is not a mutex.
+ at 0x........: pthread_mutex_init (drd_pthread_intercepts.c:?)
+ by 0x........: main (pth_mutex_reinit.c:?)
+
Mutex reinitialization: mutex 0x........, recursion count 0, owner 1.
at 0x........: pthread_mutex_init (drd_pthread_intercepts.c:?)
by 0x........: main (pth_mutex_reinit.c:?)
mutex 0x........ was first observed at:
- at 0x........: pthread_mutex_init (drd_pthread_intercepts.c:?)
+ at 0x........: pthread_mutex_lock (drd_pthread_intercepts.c:?)
by 0x........: main (pth_mutex_reinit.c:?)
Done.
-ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
+ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
=================================================
./valgrind-new/exp-sgcheck/tests/hackedbz2.stderr.diff-glibc28-amd64
=================================================
--- hackedbz2.stderr.exp-glibc28-amd64 2013-11-20 19:59:25.633546034 -0600
+++ hackedbz2.stderr.out 2013-11-20 20:35:00.252136466 -0600
@@ -1,7 +1,6 @@
Invalid read of size 1
- at 0x........: vex_strlen (hackedbz2.c:1006)
- by 0x........: add_to_myprintf_buf (hackedbz2.c:1284)
+ at 0x........: add_to_myprintf_buf (hackedbz2.c:1006)
by 0x........: vex_printf (hackedbz2.c:1155)
by 0x........: BZ2_compressBlock (hackedbz2.c:4039)
by 0x........: handle_compress (hackedbz2.c:4761)
=================================================
./valgrind-new/memcheck/tests/dw4.stderr.diff
=================================================
--- dw4.stderr.exp 2013-11-20 19:59:18.469474435 -0600
+++ dw4.stderr.out 2013-11-20 20:10:05.391929673 -0600
@@ -1,3 +1,11 @@
+
+parse_type_DIE: confused by:
+ <1><492>: DW_TAG_structure_type
+ DW_AT_signature : 8 byte signature: 9b d0 55 13 bb 1e e9 37
+
+WARNING: Serious error when reading debug info
+When reading debug info from /usr/local/src/valgrind/nightly/valgrind-new/memcheck/tests/dw4:
+parse_type_DIE: confused by the above DIE
Uninitialised byte(s) found during client check request
at 0x........: croak (dw4.c:27)
by 0x........: main (dw4.c:49)
@@ -8,12 +16,10 @@
Uninitialised byte(s) found during client check request
at 0x........: croak (dw4.c:27)
by 0x........: main (dw4.c:51)
- Location 0x........ is 0 bytes inside S2[0].i,
- a global variable declared at dw4.c:42
+ Address 0x........ is 4 bytes inside data symbol "S2"
Uninitialised byte(s) found during client check request
at 0x........: croak (dw4.c:27)
by 0x........: main (dw4.c:52)
- Location 0x........ is 0 bytes inside local.i,
- declared at dw4.c:46, in frame #1 of thread 1
+ Address 0x........ is on thread 1's stack
=================================================
./valgrind-new/memcheck/tests/err_disable3.stderr.diff
=================================================
--- err_disable3.stderr.exp 2013-11-20 19:59:17.788467629 -0600
+++ err_disable3.stderr.out 2013-11-20 20:10:09.647970425 -0600
@@ -10,8 +10,6 @@
Thread 2:
Invalid read of size 1
at 0x........: err (err_disable3.c:25)
- by 0x........: child_fn (err_disable3.c:31)
- ...
Address 0x........ is 5 bytes inside a block of size 10 free'd
at 0x........: free (vg_replace_malloc.c:...)
by 0x........: main (err_disable3.c:42)
=================================================
./valgrind-new/memcheck/tests/err_disable4.stderr.diff
=================================================
--- err_disable4.stderr.exp 2013-11-20 19:59:18.430474045 -0600
+++ err_disable4.stderr.out 2013-11-20 20:10:12.117994077 -0600
@@ -1501,8 +1501,6 @@
Thread x:
Invalid read of size 1
at 0x........: err (err_disable4.c:41)
- by 0x........: child_fn_2 (err_disable4.c:55)
- ...
Address 0x........ is 5 bytes inside a block of size 10 free'd
at 0x........: free (vg_replace_malloc.c:...)
by 0x........: main (err_disable4.c:68)
=================================================
./valgrind-new/memcheck/tests/origin5-bz2.stderr.diff-glibc212-s390x
=================================================
--- origin5-bz2.stderr.exp-glibc212-s390x 2013-11-20 19:59:18.221471957 -0600
+++ origin5-bz2.stderr.out 2013-11-20 20:11:53.128962230 -0600
@@ -75,17 +75,6 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
- at 0x........: mainSort (origin5-bz2.c:2859)
- by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
- by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
- by 0x........: handle_compress (origin5-bz2.c:4753)
- by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
- by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
- by 0x........: main (origin5-bz2.c:6484)
- Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6479)
-
-Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2963)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -131,6 +120,12 @@
Conditional jump or move depends on uninitialised value(s)
at 0x........: main (origin5-bz2.c:6512)
- Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6479)
+ Uninitialised value was created by a heap allocation
+ at 0x........: malloc (vg_replace_malloc.c:...)
+ by 0x........: g_serviceFn (origin5-bz2.c:6429)
+ by 0x........: default_bzalloc (origin5-bz2.c:4470)
+ by 0x........: BZ2_decompress (origin5-bz2.c:1578)
+ by 0x........: BZ2_bzDecompress (origin5-bz2.c:5192)
+ by 0x........: BZ2_bzBuffToBuffDecompress (origin5-bz2.c:5678)
+ by 0x........: main (origin5-bz2.c:6498)
=================================================
./valgrind-new/memcheck/tests/origin5-bz2.stderr.diff-glibc234-s390x
=================================================
--- origin5-bz2.stderr.exp-glibc234-s390x 2013-11-20 19:59:18.004469788 -0600
+++ origin5-bz2.stderr.out 2013-11-20 20:11:53.128962230 -0600
@@ -120,6 +120,12 @@
Conditional jump or move depends on uninitialised value(s)
at 0x........: main (origin5-bz2.c:6512)
- Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6479)
+ Uninitialised value was created by a heap allocation
+ at 0x........: malloc (vg_replace_malloc.c:...)
+ by 0x........: g_serviceFn (origin5-bz2.c:6429)
+ by 0x........: default_bzalloc (origin5-bz2.c:4470)
+ by 0x........: BZ2_decompress (origin5-bz2.c:1578)
+ by 0x........: BZ2_bzDecompress (origin5-bz2.c:5192)
+ by 0x........: BZ2_bzBuffToBuffDecompress (origin5-bz2.c:5678)
+ by 0x........: main (origin5-bz2.c:6498)
=================================================
./valgrind-new/memcheck/tests/origin5-bz2.stderr.diff-glibc25-amd64
=================================================
--- origin5-bz2.stderr.exp-glibc25-amd64 2013-11-20 19:59:18.005469798 -0600
+++ origin5-bz2.stderr.out 2013-11-20 20:11:53.128962230 -0600
@@ -120,6 +120,12 @@
Conditional jump or move depends on uninitialised value(s)
at 0x........: main (origin5-bz2.c:6512)
- Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6479)
+ Uninitialised value was created by a heap allocation
+ at 0x........: malloc (vg_replace_malloc.c:...)
+ by 0x........: g_serviceFn (origin5-bz2.c:6429)
+ by 0x........: default_bzalloc (origin5-bz2.c:4470)
+ by 0x........: BZ2_decompress (origin5-bz2.c:1578)
+ by 0x........: BZ2_bzDecompress (origin5-bz2.c:5192)
+ by 0x........: BZ2_bzBuffToBuffDecompress (origin5-bz2.c:5678)
+ by 0x........: main (origin5-bz2.c:6498)
=================================================
./valgrind-new/memcheck/tests/origin5-bz2.stderr.diff-glibc25-x86
=================================================
--- origin5-bz2.stderr.exp-glibc25-x86 2013-11-20 19:59:18.639476134 -0600
+++ origin5-bz2.stderr.out 2013-11-20 20:11:53.128962230 -0600
@@ -12,7 +12,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 4
+Use of uninitialised value of size 8
at 0x........: copy_input_until_stop (origin5-bz2.c:4686)
by 0x........: handle_compress (origin5-bz2.c:4750)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
@@ -21,7 +21,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 4
+Use of uninitialised value of size 8
at 0x........: copy_input_until_stop (origin5-bz2.c:4686)
by 0x........: handle_compress (origin5-bz2.c:4750)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
@@ -30,7 +30,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 4
+Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2820)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -41,7 +41,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 4
+Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2823)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -52,7 +52,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 4
+Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2854)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -63,7 +63,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 4
+Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2858)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -74,7 +74,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 4
+Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2963)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -85,7 +85,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 4
+Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2964)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -96,7 +96,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 4
+Use of uninitialised value of size 8
at 0x........: fallbackSort (origin5-bz2.c:2269)
by 0x........: BZ2_blockSort (origin5-bz2.c:3116)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -107,7 +107,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 4
+Use of uninitialised value of size 8
at 0x........: fallbackSort (origin5-bz2.c:2275)
by 0x........: BZ2_blockSort (origin5-bz2.c:3116)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -120,6 +120,12 @@
Conditional jump or move depends on uninitialised value(s)
at 0x........: main (origin5-bz2.c:6512)
- Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6479)
+ Uninitialised value was created by a heap allocation
+ at 0x........: malloc (vg_replace_malloc.c:...)
<truncated beyond 100 lines>
=================================================
./valgrind-new/memcheck/tests/origin5-bz2.stderr.diff-glibc27-ppc64
=================================================
--- origin5-bz2.stderr.exp-glibc27-ppc64 2013-11-20 19:59:18.487474615 -0600
+++ origin5-bz2.stderr.out 2013-11-20 20:11:53.128962230 -0600
@@ -1,7 +1,7 @@
Conditional jump or move depends on uninitialised value(s)
at 0x........: main (origin5-bz2.c:6481)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Conditional jump or move depends on uninitialised value(s)
at 0x........: copy_input_until_stop (origin5-bz2.c:4686)
@@ -10,7 +10,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
at 0x........: copy_input_until_stop (origin5-bz2.c:4686)
@@ -19,7 +19,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
at 0x........: copy_input_until_stop (origin5-bz2.c:4686)
@@ -28,7 +28,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2820)
@@ -39,7 +39,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2823)
@@ -50,7 +50,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2854)
@@ -61,7 +61,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2858)
@@ -72,7 +72,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2963)
@@ -83,7 +83,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2964)
@@ -94,7 +94,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
at 0x........: fallbackSort (origin5-bz2.c:2269)
@@ -105,7 +105,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
<truncated beyond 100 lines>
=================================================
./valgrind-new/memcheck/tests/threadname.stderr.diff
=================================================
--- threadname.stderr.exp 2013-11-20 19:59:18.472474465 -0600
+++ threadname.stderr.out 2013-11-20 20:13:32.090912426 -0600
@@ -9,36 +9,12 @@
Thread 2:
Invalid write of size 1
at 0x........: bad_things (threadname.c:16)
- by 0x........: child_fn_0 (threadname.c:53)
- ...
Address 0x........ is 0 bytes after a block of size 2 alloc'd
at 0x........: malloc (vg_replace_malloc.c:...)
by 0x........: bad_things (threadname.c:15)
by 0x........: child_fn_0 (threadname.c:53)
...
-Thread 3 try1:
-Invalid write of size 1
- at 0x........: bad_things (threadname.c:16)
- by 0x........: child_fn_1 (threadname.c:38)
- ...
- Address 0x........ is 0 bytes after a block of size 3 alloc'd
- at 0x........: malloc (vg_replace_malloc.c:...)
- by 0x........: bad_things (threadname.c:15)
- by 0x........: child_fn_1 (threadname.c:38)
- ...
-
-Thread 4 012345678901234:
-Invalid write of size 1
- at 0x........: bad_things (threadname.c:16)
- by 0x........: child_fn_2 (threadname.c:26)
- ...
- Address 0x........ is 0 bytes after a block of size 4 alloc'd
- at 0x........: malloc (vg_replace_malloc.c:...)
- by 0x........: bad_things (threadname.c:15)
- by 0x........: child_fn_2 (threadname.c:26)
- ...
-
Thread 1:
Invalid write of size 1
at 0x........: bad_things (threadname.c:16)
=================================================
./valgrind-new/memcheck/tests/threadname_xml.stderr.diff
=================================================
--- threadname_xml.stderr.exp 2013-11-20 19:59:17.787467619 -0600
+++ threadname_xml.stderr.out 2013-11-20 20:13:33.397924986 -0600
@@ -94,14 +94,6 @@
<file>threadname.c</file>
<line>...</line>
</frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>child_fn_0</fn>
- <dir>...</dir>
- <file>threadname.c</file>
- <line>...</line>
- </frame>
</stack>
<auxwhat>Address 0x........ is 0 bytes after a block of size 2 alloc'd</auxwhat>
<stack>
@@ -135,112 +127,6 @@
<error>
<unique>0x........</unique>
<tid>...</tid>
- <threadname>try1</threadname>
- <kind>InvalidWrite</kind>
- <what>Invalid write of size 1</what>
- <stack>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>bad_things</fn>
- <dir>...</dir>
- <file>threadname.c</file>
- <line>...</line>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>child_fn_1</fn>
- <dir>...</dir>
- <file>threadname.c</file>
- <line>...</line>
- </frame>
- </stack>
- <auxwhat>Address 0x........ is 0 bytes after a block of size 3 alloc'd</auxwhat>
- <stack>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>malloc</fn>
- <dir>...</dir>
- <file>vg_replace_malloc.c</file>
- <line>...</line>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>bad_things</fn>
- <dir>...</dir>
- <file>threadname.c</file>
- <line>...</line>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>child_fn_1</fn>
- <dir>...</dir>
- <file>threadname.c</file>
- <line>...</line>
- </frame>
- </stack>
-</error>
-
-<error>
- <unique>0x........</unique>
- <tid>...</tid>
- <threadname>012345678901234</threadname>
- <kind>InvalidWrite</kind>
- <what>Invalid write of size 1</what>
- <stack>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>bad_things</fn>
- <dir>...</dir>
- <file>threadname.c</file>
- <line>...</line>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>child_fn_2</fn>
- <dir>...</dir>
- <file>threadname.c</file>
- <line>...</line>
- </frame>
- </stack>
- <auxwhat>Address 0x........ is 0 bytes after a block of size 4 alloc'd</auxwhat>
- <stack>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
<truncated beyond 100 lines>
=================================================
./valgrind-old/drd/tests/pth_mutex_reinit.stderr.diff
=================================================
--- pth_mutex_reinit.stderr.exp 2013-11-20 19:23:18.590416626 -0600
+++ pth_mutex_reinit.stderr.out 2013-11-20 19:52:52.834626175 -0600
@@ -1,11 +1,15 @@
+The object at address 0x........ is not a mutex.
+ at 0x........: pthread_mutex_init (drd_pthread_intercepts.c:?)
+ by 0x........: main (pth_mutex_reinit.c:?)
+
Mutex reinitialization: mutex 0x........, recursion count 0, owner 1.
at 0x........: pthread_mutex_init (drd_pthread_intercepts.c:?)
by 0x........: main (pth_mutex_reinit.c:?)
mutex 0x........ was first observed at:
- at 0x........: pthread_mutex_init (drd_pthread_intercepts.c:?)
+ at 0x........: pthread_mutex_lock (drd_pthread_intercepts.c:?)
by 0x........: main (pth_mutex_reinit.c:?)
Done.
-ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
+ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
=================================================
./valgrind-old/exp-sgcheck/tests/hackedbz2.stderr.diff-glibc28-amd64
=================================================
--- hackedbz2.stderr.exp-glibc28-amd64 2013-11-20 19:22:53.428158180 -0600
+++ hackedbz2.stderr.out 2013-11-20 19:58:26.134951511 -0600
@@ -1,7 +1,6 @@
Invalid read of size 1
- at 0x........: vex_strlen (hackedbz2.c:1006)
- by 0x........: add_to_myprintf_buf (hackedbz2.c:1284)
+ at 0x........: add_to_myprintf_buf (hackedbz2.c:1006)
by 0x........: vex_printf (hackedbz2.c:1155)
by 0x........: BZ2_compressBlock (hackedbz2.c:4039)
by 0x........: handle_compress (hackedbz2.c:4761)
=================================================
./valgrind-old/memcheck/tests/dw4.stderr.diff
=================================================
--- dw4.stderr.exp 2013-11-20 19:23:40.654643259 -0600
+++ dw4.stderr.out 2013-11-20 19:33:59.438001528 -0600
@@ -1,3 +1,11 @@
+
+parse_type_DIE: confused by:
+ <1><492>: DW_TAG_structure_type
+ DW_AT_signature : 8 byte signature: 9b d0 55 13 bb 1e e9 37
+
+WARNING: Serious error when reading debug info
+When reading debug info from /usr/local/src/valgrind/nightly/valgrind-old/memcheck/tests/dw4:
+parse_type_DIE: confused by the above DIE
Uninitialised byte(s) found during client check request
at 0x........: croak (dw4.c:27)
by 0x........: main (dw4.c:49)
@@ -8,12 +16,10 @@
Uninitialised byte(s) found during client check request
at 0x........: croak (dw4.c:27)
by 0x........: main (dw4.c:51)
- Location 0x........ is 0 bytes inside S2[0].i,
- a global variable declared at dw4.c:42
+ Address 0x........ is 4 bytes inside data symbol "S2"
Uninitialised byte(s) found during client check request
at 0x........: croak (dw4.c:27)
by 0x........: main (dw4.c:52)
- Location 0x........ is 0 bytes inside local.i,
- declared at dw4.c:46, in frame #1 of thread 1
+ Address 0x........ is on thread 1's stack
=================================================
./valgrind-old/memcheck/tests/err_disable3.stderr.diff
=================================================
--- err_disable3.stderr.exp 2013-11-20 19:23:43.105668435 -0600
+++ err_disable3.stderr.out 2013-11-20 19:34:03.390042123 -0600
@@ -10,8 +10,6 @@
Thread 2:
Invalid read of size 1
at 0x........: err (err_disable3.c:25)
- by 0x........: child_fn (err_disable3.c:31)
- ...
Address 0x........ is 5 bytes inside a block of size 10 free'd
at 0x........: free (vg_replace_malloc.c:...)
by 0x........: main (err_disable3.c:42)
=================================================
./valgrind-old/memcheck/tests/err_disable4.stderr.diff
=================================================
--- err_disable4.stderr.exp 2013-11-20 19:23:46.612704408 -0600
+++ err_disable4.stderr.out 2013-11-20 19:34:06.120070163 -0600
@@ -1501,8 +1501,6 @@
Thread x:
Invalid read of size 1
at 0x........: err (err_disable4.c:41)
- by 0x........: child_fn_2 (err_disable4.c:55)
- ...
Address 0x........ is 5 bytes inside a block of size 10 free'd
at 0x........: free (vg_replace_malloc.c:...)
by 0x........: main (err_disable4.c:68)
=================================================
./valgrind-old/memcheck/tests/origin5-bz2.stderr.diff-glibc212-s390x
=================================================
--- origin5-bz2.stderr.exp-glibc212-s390x 2013-11-20 19:23:46.117699323 -0600
+++ origin5-bz2.stderr.out 2013-11-20 19:35:46.409100290 -0600
@@ -75,17 +75,6 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
- at 0x........: mainSort (origin5-bz2.c:2859)
- by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
- by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
- by 0x........: handle_compress (origin5-bz2.c:4753)
- by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
- by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
- by 0x........: main (origin5-bz2.c:6484)
- Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6479)
-
-Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2963)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -131,6 +120,12 @@
Conditional jump or move depends on uninitialised value(s)
at 0x........: main (origin5-bz2.c:6512)
- Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6479)
+ Uninitialised value was created by a heap allocation
+ at 0x........: malloc (vg_replace_malloc.c:...)
+ by 0x........: g_serviceFn (origin5-bz2.c:6429)
+ by 0x........: default_bzalloc (origin5-bz2.c:4470)
+ by 0x........: BZ2_decompress (origin5-bz2.c:1578)
+ by 0x........: BZ2_bzDecompress (origin5-bz2.c:5192)
+ by 0x........: BZ2_bzBuffToBuffDecompress (origin5-bz2.c:5678)
+ by 0x........: main (origin5-bz2.c:6498)
=================================================
./valgrind-old/memcheck/tests/origin5-bz2.stderr.diff-glibc234-s390x
=================================================
--- origin5-bz2.stderr.exp-glibc234-s390x 2013-11-20 19:23:45.358691527 -0600
+++ origin5-bz2.stderr.out 2013-11-20 19:35:46.409100290 -0600
@@ -120,6 +120,12 @@
Conditional jump or move depends on uninitialised value(s)
at 0x........: main (origin5-bz2.c:6512)
- Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6479)
+ Uninitialised value was created by a heap allocation
+ at 0x........: malloc (vg_replace_malloc.c:...)
+ by 0x........: g_serviceFn (origin5-bz2.c:6429)
+ by 0x........: default_bzalloc (origin5-bz2.c:4470)
+ by 0x........: BZ2_decompress (origin5-bz2.c:1578)
+ by 0x........: BZ2_bzDecompress (origin5-bz2.c:5192)
+ by 0x........: BZ2_bzBuffToBuffDecompress (origin5-bz2.c:5678)
+ by 0x........: main (origin5-bz2.c:6498)
=================================================
./valgrind-old/memcheck/tests/origin5-bz2.stderr.diff-glibc25-amd64
=================================================
--- origin5-bz2.stderr.exp-glibc25-amd64 2013-11-20 19:23:45.360691548 -0600
+++ origin5-bz2.stderr.out 2013-11-20 19:35:46.409100290 -0600
@@ -120,6 +120,12 @@
Conditional jump or move depends on uninitialised value(s)
at 0x........: main (origin5-bz2.c:6512)
- Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6479)
+ Uninitialised value was created by a heap allocation
+ at 0x........: malloc (vg_replace_malloc.c:...)
+ by 0x........: g_serviceFn (origin5-bz2.c:6429)
+ by 0x........: default_bzalloc (origin5-bz2.c:4470)
+ by 0x........: BZ2_decompress (origin5-bz2.c:1578)
+ by 0x........: BZ2_bzDecompress (origin5-bz2.c:5192)
+ by 0x........: BZ2_bzBuffToBuffDecompress (origin5-bz2.c:5678)
+ by 0x........: main (origin5-bz2.c:6498)
=================================================
./valgrind-old/memcheck/tests/origin5-bz2.stderr.diff-glibc25-x86
=================================================
--- origin5-bz2.stderr.exp-glibc25-x86 2013-11-20 19:23:42.085657957 -0600
+++ origin5-bz2.stderr.out 2013-11-20 19:35:46.409100290 -0600
@@ -12,7 +12,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 4
+Use of uninitialised value of size 8
at 0x........: copy_input_until_stop (origin5-bz2.c:4686)
by 0x........: handle_compress (origin5-bz2.c:4750)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
@@ -21,7 +21,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 4
+Use of uninitialised value of size 8
at 0x........: copy_input_until_stop (origin5-bz2.c:4686)
by 0x........: handle_compress (origin5-bz2.c:4750)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
@@ -30,7 +30,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 4
+Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2820)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -41,7 +41,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 4
+Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2823)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -52,7 +52,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 4
+Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2854)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -63,7 +63,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 4
+Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2858)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -74,7 +74,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 4
+Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2963)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -85,7 +85,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 4
+Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2964)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -96,7 +96,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 4
+Use of uninitialised value of size 8
at 0x........: fallbackSort (origin5-bz2.c:2269)
by 0x........: BZ2_blockSort (origin5-bz2.c:3116)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -107,7 +107,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 4
+Use of uninitialised value of size 8
at 0x........: fallbackSort (origin5-bz2.c:2275)
by 0x........: BZ2_blockSort (origin5-bz2.c:3116)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -120,6 +120,12 @@
Conditional jump or move depends on uninitialised value(s)
at 0x........: main (origin5-bz2.c:6512)
- Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6479)
+ Uninitialised value was created by a heap allocation
+ at 0x........: malloc (vg_replace_malloc.c:...)
<truncated beyond 100 lines>
=================================================
./valgrind-old/memcheck/tests/origin5-bz2.stderr.diff-glibc27-ppc64
=================================================
--- origin5-bz2.stderr.exp-glibc27-ppc64 2013-11-20 19:23:40.672643444 -0600
+++ origin5-bz2.stderr.out 2013-11-20 19:35:46.409100290 -0600
@@ -1,7 +1,7 @@
Conditional jump or move depends on uninitialised value(s)
at 0x........: main (origin5-bz2.c:6481)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Conditional jump or move depends on uninitialised value(s)
at 0x........: copy_input_until_stop (origin5-bz2.c:4686)
@@ -10,7 +10,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
at 0x........: copy_input_until_stop (origin5-bz2.c:4686)
@@ -19,7 +19,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
at 0x........: copy_input_until_stop (origin5-bz2.c:4686)
@@ -28,7 +28,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2820)
@@ -39,7 +39,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2823)
@@ -50,7 +50,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2854)
@@ -61,7 +61,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2858)
@@ -72,7 +72,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2963)
@@ -83,7 +83,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2964)
@@ -94,7 +94,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
at 0x........: fallbackSort (origin5-bz2.c:2269)
@@ -105,7 +105,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
<truncated beyond 100 lines>
=================================================
./valgrind-old/memcheck/tests/threadname.stderr.diff
=================================================
--- threadname.stderr.exp 2013-11-20 19:23:40.657643289 -0600
+++ threadname.stderr.out 2013-11-20 19:37:23.260095182 -0600
@@ -9,36 +9,12 @@
Thread 2:
Invalid write of size 1
at 0x........: bad_things (threadname.c:16)
- by 0x........: child_fn_0 (threadname.c:53)
- ...
Address 0x........ is 0 bytes after a block of size 2 alloc'd
at 0x........: malloc (vg_replace_malloc.c:...)
by 0x........: bad_things (threadname.c:15)
by 0x........: child_fn_0 (threadname.c:53)
...
-Thread 3 try1:
-Invalid write of size 1
- at 0x........: bad_things (threadname.c:16)
- by 0x........: child_fn_1 (threadname.c:38)
- ...
- Address 0x........ is 0 bytes after a block of size 3 alloc'd
- at 0x........: malloc (vg_replace_malloc.c:...)
- by 0x........: bad_things (threadname.c:15)
- by 0x........: child_fn_1 (threadname.c:38)
- ...
-
-Thread 4 012345678901234:
-Invalid write of size 1
- at 0x........: bad_things (threadname.c:16)
- by 0x........: child_fn_2 (threadname.c:26)
- ...
- Address 0x........ is 0 bytes after a block of size 4 alloc'd
- at 0x........: malloc (vg_replace_malloc.c:...)
- by 0x........: bad_things (threadname.c:15)
- by 0x........: child_fn_2 (threadname.c:26)
- ...
-
Thread 1:
Invalid write of size 1
at 0x........: bad_things (threadname.c:16)
=================================================
./valgrind-old/memcheck/tests/threadname_xml.stderr.diff
=================================================
--- threadname_xml.stderr.exp 2013-11-20 19:23:43.104668424 -0600
+++ threadname_xml.stderr.out 2013-11-20 19:37:24.310105968 -0600
@@ -94,14 +94,6 @@
<file>threadname.c</file>
<line>...</line>
</frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>child_fn_0</fn>
- <dir>...</dir>
- <file>threadname.c</file>
- <line>...</line>
- </frame>
</stack>
<auxwhat>Address 0x........ is 0 bytes after a block of size 2 alloc'd</auxwhat>
<stack>
@@ -135,112 +127,6 @@
<error>
<unique>0x........</unique>
<tid>...</tid>
- <threadname>try1</threadname>
- <kind>InvalidWrite</kind>
- <what>Invalid write of size 1</what>
- <stack>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>bad_things</fn>
- <dir>...</dir>
- <file>threadname.c</file>
- <line>...</line>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>child_fn_1</fn>
- <dir>...</dir>
- <file>threadname.c</file>
- <line>...</line>
- </frame>
- </stack>
- <auxwhat>Address 0x........ is 0 bytes after a block of size 3 alloc'd</auxwhat>
- <stack>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>malloc</fn>
- <dir>...</dir>
- <file>vg_replace_malloc.c</file>
- <line>...</line>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>bad_things</fn>
- <dir>...</dir>
- <file>threadname.c</file>
- <line>...</line>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>child_fn_1</fn>
- <dir>...</dir>
- <file>threadname.c</file>
- <line>...</line>
- </frame>
- </stack>
-</error>
-
-<error>
- <unique>0x........</unique>
- <tid>...</tid>
- <threadname>012345678901234</threadname>
- <kind>InvalidWrite</kind>
- <what>Invalid write of size 1</what>
- <stack>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>bad_things</fn>
- <dir>...</dir>
- <file>threadname.c</file>
- <line>...</line>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>child_fn_2</fn>
- <dir>...</dir>
- <file>threadname.c</file>
- <line>...</line>
- </frame>
- </stack>
- <auxwhat>Address 0x........ is 0 bytes after a block of size 4 alloc'd</auxwhat>
- <stack>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
<truncated beyond 100 lines>
|
|
From: Florian K. <fl...@ei...> - 2013-11-20 23:10:52
|
On 11/20/2013 11:31 PM, Yan wrote: > > I guess, from a philosophical prospective, it makes more sense to me to > have VEX in a separate repo if it's independent anyways. This way, projects > that use VEX and not Valgrind wouldn't have to pull the whole Valgrind repo > and so forth. Seems cleaner to me. No need to check out the whole tree just to get some subdir. E.g. svn co svn://svn.valgrind.org/valgrind/trunk/tests tests will just check out the 'tests' subdirectory. Florian |
|
From: Stephen M. <sm...@al...> - 2013-11-20 22:53:42
|
>>>>> "Y" == Yan <ya...@ya...> writes: Y> So I'm rather new to the list, and VEX development in general, but Y> I wanted to chime in. Feel free to ignore me. Y> I've been using VEX for static analysis, and am putting together a Y> set of patches to make VEX more usable to this goal. However, my Y> stuff is purely using VEX, not Valgrind, as the latter is Y> completely geared for dynamic analysis. If there's interest in Y> keeping VEX friendly for such uses, merging the VEX and Valgrind Y> repositories would be counter-productive to that goal. Y> In the security realm, there are a few projects (specifically, Vine Y> and BAP) that forked VEX several years back to do non-Valgrind Y> things with it. While it might be too late for BAP and Vine, I Y> think keeping VEX in a separate repository (and maybe even Y> individualizing VEX and Valgrind slightly more) could encourage Y> future projects like these to keep upstreaming their changes, as Y> opposed to forking off on their own. I wouldn't call Vine's use of VEX (or BAP's, which has been similar though I think they're moving away from it) a fork. We do have a few patches that we haven't gotten merged (cf. https://github.com/bitblaze-fuzzball/fuzzball/blob/master/vex-r2737.patch ), but Vine mostly wraps around VEX with new code to get something that's more suitable for non-Valgrind purposes. If there was a larger community of people building non-Valgrind tools from VEX, there would be some value on collaborating more closely, but I don't know if Yan's project plus Vine is yet getting close to a critical mass. I think from my perspective the layout of the repository is not a critical factor. Doing a larger "svn checkout" but then ignoring most of it would not be a major burden. Changing the build process so that it's necessary to build all of Valgrind would make other uses a bit slower, but there's a recurring inconsistency problem with the current two separate build processes so it might not be a loss overall. Obviously keeping VEX compiling as a separate library is important for external users, but I don't see anyone proposing to change that. Conversely external uses would be easier if VEX's interface were more stable (our code has a lot of #if VEX_VERSION > xxxx directives). But as long as Valgrind is by far the predominant use of VEX I think us external users are getting a pretty good deal. -- Stephen |
|
From: Yan <ya...@ya...> - 2013-11-20 22:32:19
|
Right, the core issue is VEX-Valgrind independence, which is already quite good. I guess, from a philosophical prospective, it makes more sense to me to have VEX in a separate repo if it's independent anyways. This way, projects that use VEX and not Valgrind wouldn't have to pull the whole Valgrind repo and so forth. Seems cleaner to me. However, I realize that there are other issues, from a project perspective and so on, that make it less clear-cut than that. On Wed, Nov 20, 2013 at 2:14 PM, Philippe Waroquiers < phi...@sk...> wrote: > On Wed, 2013-11-20 at 14:01 -0800, Yan wrote: > > So I'm rather new to the list, and VEX development in general, but I > > wanted to chime in. Feel free to ignore me. > > > > > > I've been using VEX for static analysis, and am putting together a set > > of patches to make VEX more usable to this goal. However, my stuff is > > purely using VEX, not Valgrind, as the latter is completely geared for > > dynamic analysis. If there's interest in keeping VEX friendly for such > > uses, merging the VEX and Valgrind repositories would be > > counter-productive to that goal. > > > > > > In the security realm, there are a few projects (specifically, Vine > > and BAP) that forked VEX several years back to do non-Valgrind things > > with it. While it might be too late for BAP and Vine, I think keeping > > VEX in a separate repository (and maybe even individualizing VEX and > > Valgrind slightly more) could encourage future projects like these to > > keep upstreaming their changes, as opposed to forking off on their > > own. > > Can you elaborate why having one single repository would be > counter-productive ? > > I guess that we just need to ensure that VEX (and its library) > can be used without the rest of valgrind. > But that does not seem to be "hard-linked" with having one or two > repos ? > > There are other "engineering" constraints which have to be ensured > e.g. in the Valgrind repository, the tools can depend on coregrind, > but coregrind cannot depend on tools. > > So, maybe what we need to see is how VEX could/should be made > more "valgrind independent". > > Philippe > > > > > > > > > - Yan > > > > > > On Wed, Nov 20, 2013 at 1:51 PM, Philippe Waroquiers > > <phi...@sk...> wrote: > > On Wed, 2013-11-20 at 12:39 +0100, Mark Wielaard wrote: > > > > > In general I like this proposal. But some nitpicks... > > > > > > The valgrind/VEX split makes B technically not always fully > > workable. > > > That is also why sometimes you want to document which > > revision in which > > > repo really fixed something. I would very much like us to > > merge the > > > repos just for this reason. > > > > Yes, merging the repos would make sense. > > Before that, I think a VEX only fix should be committed first, > > and then a second commit of NEWS document the change. > > > > > > > > > > It isn't totally clear to me how we will use the NEWS file > > for major and > > > minor releases. Where minor would be e.g. 3.9.1 which > > contains > > > cherry-picked bug fixes from the trunk (which itself will > > become 3.10.0 > > > or 4.0.0 at some point). > > > > Not completely clear to me. I would imagine NEWS is updated in > > the > > minor release branch, indicating which bugs were fixed there. > > After that, merging from minor release branch to trunk should > > bring the minor release NEWS update in the trunk, to have NEWS > > having the full history. > > > > > > > > > > The bug list is not just NEWS, but also the release managers > > (currently > > > Julian's) notepad about the status of various bugs on > > various branches > > > (minor/major). > > > > > > For this reason we might want to have both a BUGS file, > > which then > > > contains current status of various bugs and a NEWS file > > which only > > > contains descriptions of the bugs actually fixed (on the > > current > > > branch?). > > > > Maybe we better use bugzilla to maintain not yet fixed bug > > status ? > > But if a BUGS file under svn helps to maintain some info for > > not > > yet fixed bugs, that is for sure possible. > > To be seen with Julian what he deems needed. > > Maybe we could look at what other projects are doing ? > > (e.g. what is gdb doing for their major and minor release ?) > > > > > > > > > If ok to go for B, I will add a file > > README_DEVELOPERS_processes > > > > (or any better name?) in SVN to document the "process" > > > > with which a change is NEWS-documented as part of the > > commit. > > > > > > > > We might then later add descriptions of other processes > > > > (e.g. how to make a release maybe ?). > > > > > > Yes please! :) Is there a description of how minor release > > branches in > > > svn work (I am a bit of a svn noob, using a local git/svn > > bridge to > > > actually push commits). I am slowly accumulating some > > patches for the > > > fedora valgrind package which I think might make a good > > start for a > > > minor 3.9.1 branch. > > > > > > > Note that it would be preferable to have the 3.9.0 branch > > merged > > > > into the trunk to start editing NEWS for the next release. > > > > Not clear to me if there is a reason to delay this merge. > > > > > > And maybe in the future swap the updating of NEWS. All > > changes to NEWS > > > should first go onto trunk and only then > > backported/cherry-picked into a > > > release branch NEWS version? > > > > Or updated in branch and merged in trunk ? > > Unclear to me what is the best way to proceed (lack of svn > > knowledge > > being a problem to judge what would work well). > > > > Philippe > > > > > > > > > > > ------------------------------------------------------------------------------ > > Shape the Mobile Experience: Free Subscription > > Software experts and developers: Be at the forefront of tech > > innovation. > > Intel(R) Software Adrenaline delivers strategic insight and > > game-changing > > conversations that shape the rapidly evolving mobile > > landscape. Sign up now. > > > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > > _______________________________________________ > > Valgrind-developers mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > > > > > > > > |
|
From: Philippe W. <phi...@sk...> - 2013-11-20 22:14:32
|
On Wed, 2013-11-20 at 14:01 -0800, Yan wrote: > So I'm rather new to the list, and VEX development in general, but I > wanted to chime in. Feel free to ignore me. > > > I've been using VEX for static analysis, and am putting together a set > of patches to make VEX more usable to this goal. However, my stuff is > purely using VEX, not Valgrind, as the latter is completely geared for > dynamic analysis. If there's interest in keeping VEX friendly for such > uses, merging the VEX and Valgrind repositories would be > counter-productive to that goal. > > > In the security realm, there are a few projects (specifically, Vine > and BAP) that forked VEX several years back to do non-Valgrind things > with it. While it might be too late for BAP and Vine, I think keeping > VEX in a separate repository (and maybe even individualizing VEX and > Valgrind slightly more) could encourage future projects like these to > keep upstreaming their changes, as opposed to forking off on their > own. Can you elaborate why having one single repository would be counter-productive ? I guess that we just need to ensure that VEX (and its library) can be used without the rest of valgrind. But that does not seem to be "hard-linked" with having one or two repos ? There are other "engineering" constraints which have to be ensured e.g. in the Valgrind repository, the tools can depend on coregrind, but coregrind cannot depend on tools. So, maybe what we need to see is how VEX could/should be made more "valgrind independent". Philippe > > > - Yan > > > On Wed, Nov 20, 2013 at 1:51 PM, Philippe Waroquiers > <phi...@sk...> wrote: > On Wed, 2013-11-20 at 12:39 +0100, Mark Wielaard wrote: > > > In general I like this proposal. But some nitpicks... > > > > The valgrind/VEX split makes B technically not always fully > workable. > > That is also why sometimes you want to document which > revision in which > > repo really fixed something. I would very much like us to > merge the > > repos just for this reason. > > Yes, merging the repos would make sense. > Before that, I think a VEX only fix should be committed first, > and then a second commit of NEWS document the change. > > > > > > It isn't totally clear to me how we will use the NEWS file > for major and > > minor releases. Where minor would be e.g. 3.9.1 which > contains > > cherry-picked bug fixes from the trunk (which itself will > become 3.10.0 > > or 4.0.0 at some point). > > Not completely clear to me. I would imagine NEWS is updated in > the > minor release branch, indicating which bugs were fixed there. > After that, merging from minor release branch to trunk should > bring the minor release NEWS update in the trunk, to have NEWS > having the full history. > > > > > > The bug list is not just NEWS, but also the release managers > (currently > > Julian's) notepad about the status of various bugs on > various branches > > (minor/major). > > > > For this reason we might want to have both a BUGS file, > which then > > contains current status of various bugs and a NEWS file > which only > > contains descriptions of the bugs actually fixed (on the > current > > branch?). > > Maybe we better use bugzilla to maintain not yet fixed bug > status ? > But if a BUGS file under svn helps to maintain some info for > not > yet fixed bugs, that is for sure possible. > To be seen with Julian what he deems needed. > Maybe we could look at what other projects are doing ? > (e.g. what is gdb doing for their major and minor release ?) > > > > > > If ok to go for B, I will add a file > README_DEVELOPERS_processes > > > (or any better name?) in SVN to document the "process" > > > with which a change is NEWS-documented as part of the > commit. > > > > > > We might then later add descriptions of other processes > > > (e.g. how to make a release maybe ?). > > > > Yes please! :) Is there a description of how minor release > branches in > > svn work (I am a bit of a svn noob, using a local git/svn > bridge to > > actually push commits). I am slowly accumulating some > patches for the > > fedora valgrind package which I think might make a good > start for a > > minor 3.9.1 branch. > > > > > Note that it would be preferable to have the 3.9.0 branch > merged > > > into the trunk to start editing NEWS for the next release. > > > Not clear to me if there is a reason to delay this merge. > > > > And maybe in the future swap the updating of NEWS. All > changes to NEWS > > should first go onto trunk and only then > backported/cherry-picked into a > > release branch NEWS version? > > Or updated in branch and merged in trunk ? > Unclear to me what is the best way to proceed (lack of svn > knowledge > being a problem to judge what would work well). > > Philippe > > > > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech > innovation. > Intel(R) Software Adrenaline delivers strategic insight and > game-changing > conversations that shape the rapidly evolving mobile > landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > > |
|
From: Yan <ya...@ya...> - 2013-11-20 22:02:29
|
So I'm rather new to the list, and VEX development in general, but I wanted to chime in. Feel free to ignore me. I've been using VEX for static analysis, and am putting together a set of patches to make VEX more usable to this goal. However, my stuff is purely using VEX, not Valgrind, as the latter is completely geared for dynamic analysis. If there's interest in keeping VEX friendly for such uses, merging the VEX and Valgrind repositories would be counter-productive to that goal. In the security realm, there are a few projects (specifically, Vine and BAP) that forked VEX several years back to do non-Valgrind things with it. While it might be too late for BAP and Vine, I think keeping VEX in a separate repository (and maybe even individualizing VEX and Valgrind slightly more) could encourage future projects like these to keep upstreaming their changes, as opposed to forking off on their own. - Yan On Wed, Nov 20, 2013 at 1:51 PM, Philippe Waroquiers < phi...@sk...> wrote: > On Wed, 2013-11-20 at 12:39 +0100, Mark Wielaard wrote: > > > In general I like this proposal. But some nitpicks... > > > > The valgrind/VEX split makes B technically not always fully workable. > > That is also why sometimes you want to document which revision in which > > repo really fixed something. I would very much like us to merge the > > repos just for this reason. > Yes, merging the repos would make sense. > Before that, I think a VEX only fix should be committed first, > and then a second commit of NEWS document the change. > > > > > > It isn't totally clear to me how we will use the NEWS file for major and > > minor releases. Where minor would be e.g. 3.9.1 which contains > > cherry-picked bug fixes from the trunk (which itself will become 3.10.0 > > or 4.0.0 at some point). > Not completely clear to me. I would imagine NEWS is updated in the > minor release branch, indicating which bugs were fixed there. > After that, merging from minor release branch to trunk should > bring the minor release NEWS update in the trunk, to have NEWS > having the full history. > > > > > > The bug list is not just NEWS, but also the release managers (currently > > Julian's) notepad about the status of various bugs on various branches > > (minor/major). > > > > For this reason we might want to have both a BUGS file, which then > > contains current status of various bugs and a NEWS file which only > > contains descriptions of the bugs actually fixed (on the current > > branch?). > Maybe we better use bugzilla to maintain not yet fixed bug status ? > But if a BUGS file under svn helps to maintain some info for not > yet fixed bugs, that is for sure possible. > To be seen with Julian what he deems needed. > Maybe we could look at what other projects are doing ? > (e.g. what is gdb doing for their major and minor release ?) > > > > > > If ok to go for B, I will add a file README_DEVELOPERS_processes > > > (or any better name?) in SVN to document the "process" > > > with which a change is NEWS-documented as part of the commit. > > > > > > We might then later add descriptions of other processes > > > (e.g. how to make a release maybe ?). > > > > Yes please! :) Is there a description of how minor release branches in > > svn work (I am a bit of a svn noob, using a local git/svn bridge to > > actually push commits). I am slowly accumulating some patches for the > > fedora valgrind package which I think might make a good start for a > > minor 3.9.1 branch. > > > > > Note that it would be preferable to have the 3.9.0 branch merged > > > into the trunk to start editing NEWS for the next release. > > > Not clear to me if there is a reason to delay this merge. > > > > And maybe in the future swap the updating of NEWS. All changes to NEWS > > should first go onto trunk and only then backported/cherry-picked into a > > release branch NEWS version? > Or updated in branch and merged in trunk ? > Unclear to me what is the best way to proceed (lack of svn knowledge > being a problem to judge what would work well). > > Philippe > > > > > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up > now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Philippe W. <phi...@sk...> - 2013-11-20 21:51:31
|
On Wed, 2013-11-20 at 12:39 +0100, Mark Wielaard wrote: > In general I like this proposal. But some nitpicks... > > The valgrind/VEX split makes B technically not always fully workable. > That is also why sometimes you want to document which revision in which > repo really fixed something. I would very much like us to merge the > repos just for this reason. Yes, merging the repos would make sense. Before that, I think a VEX only fix should be committed first, and then a second commit of NEWS document the change. > > It isn't totally clear to me how we will use the NEWS file for major and > minor releases. Where minor would be e.g. 3.9.1 which contains > cherry-picked bug fixes from the trunk (which itself will become 3.10.0 > or 4.0.0 at some point). Not completely clear to me. I would imagine NEWS is updated in the minor release branch, indicating which bugs were fixed there. After that, merging from minor release branch to trunk should bring the minor release NEWS update in the trunk, to have NEWS having the full history. > > The bug list is not just NEWS, but also the release managers (currently > Julian's) notepad about the status of various bugs on various branches > (minor/major). > > For this reason we might want to have both a BUGS file, which then > contains current status of various bugs and a NEWS file which only > contains descriptions of the bugs actually fixed (on the current > branch?). Maybe we better use bugzilla to maintain not yet fixed bug status ? But if a BUGS file under svn helps to maintain some info for not yet fixed bugs, that is for sure possible. To be seen with Julian what he deems needed. Maybe we could look at what other projects are doing ? (e.g. what is gdb doing for their major and minor release ?) > > > If ok to go for B, I will add a file README_DEVELOPERS_processes > > (or any better name?) in SVN to document the "process" > > with which a change is NEWS-documented as part of the commit. > > > > We might then later add descriptions of other processes > > (e.g. how to make a release maybe ?). > > Yes please! :) Is there a description of how minor release branches in > svn work (I am a bit of a svn noob, using a local git/svn bridge to > actually push commits). I am slowly accumulating some patches for the > fedora valgrind package which I think might make a good start for a > minor 3.9.1 branch. > > > Note that it would be preferable to have the 3.9.0 branch merged > > into the trunk to start editing NEWS for the next release. > > Not clear to me if there is a reason to delay this merge. > > And maybe in the future swap the updating of NEWS. All changes to NEWS > should first go onto trunk and only then backported/cherry-picked into a > release branch NEWS version? Or updated in branch and merged in trunk ? Unclear to me what is the best way to proceed (lack of svn knowledge being a problem to judge what would work well). Philippe |
|
From: Philippe W. <phi...@sk...> - 2013-11-20 21:39:22
|
On Wed, 2013-11-20 at 13:24 +0100, Bart Van Assche wrote: > On 11/19/13 21:20, Philippe Waroquiers wrote: > > On Tue, 2013-11-19 at 09:08 -0800, Patrick J. LoPresti wrote: > > > >> When partial-loads-ok is working correctly, I believe all of > >> Valgrind's str/mem intercepts are technically unnecessary. True, they > >> are faster... But that is an argument for intercepting every function > >> in the C library :-). > > Not too sure I understand. The str/mem interceptions will usually > > run slower than the C lib functions (as in most cases, these > > interceptions run fully on the simulated cpu and are not as > > optimised as the c lib functions). > > If any of the str/mem intercepts would turn out to run significantly > slower than their optimized equivalents in the C library I will be happy > to optimize the relevant str/mem intercepts further. Fair enough. Would be worth doing perl perf/vg_perf --vg=../trunk --vg=../new --tool=helgrind,drd --reps=5 to have first indications of a possible performance impact. Philippe |
|
From: Bart V. A. <bva...@ac...> - 2013-11-20 12:24:30
|
On 11/19/13 21:20, Philippe Waroquiers wrote: > On Tue, 2013-11-19 at 09:08 -0800, Patrick J. LoPresti wrote: > >> When partial-loads-ok is working correctly, I believe all of >> Valgrind's str/mem intercepts are technically unnecessary. True, they >> are faster... But that is an argument for intercepting every function >> in the C library :-). > Not too sure I understand. The str/mem interceptions will usually > run slower than the C lib functions (as in most cases, these > interceptions run fully on the simulated cpu and are not as > optimised as the c lib functions). If any of the str/mem intercepts would turn out to run significantly slower than their optimized equivalents in the C library I will be happy to optimize the relevant str/mem intercepts further. >> In my opinion, "--partial-loads-ok=yes" should be the default. It >> would make 90% of the intercepts and default suppression rules >> unnecessary. OK that is just a guess... But this is certainly a >> pervasive source of Valgrind false positives. > You could try to run all the regression tests giving > --partial-load-ok=yes > and use -v to look at the used suppressions and see which one > are not used anymore. I will have a look at this but after this patch is in the Valgrind source code tree. Bart. |
|
From: <sv...@va...> - 2013-11-20 11:54:49
|
Author: mjw
Date: Wed Nov 20 11:54:38 2013
New Revision: 13715
Log:
dwz compressed alternate .debug_info and .debug_str not read correctly.
Bug #327837. The buildid from the .gnu_debugaltlink section was parsed
incorrectly (from the wrong offset). Causing the debug alt file not to
be found.
Modified:
trunk/coregrind/m_debuginfo/readelf.c
Modified: trunk/coregrind/m_debuginfo/readelf.c
==============================================================================
--- trunk/coregrind/m_debuginfo/readelf.c (original)
+++ trunk/coregrind/m_debuginfo/readelf.c Wed Nov 20 11:54:38 2013
@@ -2609,7 +2609,8 @@
vg_assert(aimg == NULL);
if (debugaltlink_escn.img != NULL) {
- UInt buildid_offset = ML_(img_strlen)(debugaltlink_escn.img, 0)+1;
+ UInt buildid_offset = ML_(img_strlen)(debugaltlink_escn.img,
+ debugaltlink_escn.ioff)+1;
vg_assert(buildid_offset < debugaltlink_escn.szB);
|
|
From: Mark W. <mj...@re...> - 2013-11-20 11:39:50
|
On Thu, 2013-11-14 at 20:09 +0100, Philippe Waroquiers wrote: > Up to now, I have seen various "methods" used to update NEWS > when a bug is fixed or a new feature is implemented. > > > A. NEWS is not modified when the bug is fixed or when the feature > is implemented, but a little bit before the release, some research > is done to find what was fixed or what was implemented, and then > NEWS is update. > B Some other changes (bug fixed or new feature) are accompanied > with the NEWS modification (in the commit that brings the change in > svn) > C Sometimes, NEWS is modified slightly after the commit that fixed > the bug or implemented the new feature. > D Also, various markers (for bugs) were used in NEWS e.g. to indicate > which revision fixed the bug and/or what was the release in which it > was fixed. These markers are then removed before the release. > E maybe some other conventions I have not seen/detected/... > > I think it would be cleaner/more understandable/... to have all of us > using the same technique. > > I have a strong preference for B, for the following reasons: > * NEWS in SVN is always up to date > * the code is always in sync with NEWS > * no need to dig into up to one year of past changes to discover what > was changed which is worth a NEWS entry. The NEWS entry can then > be reviewed/commented as part of the review (or post-commit review > if it was deemed no pre-commit review was needed) > * the fixed bug can be marked as fixed in bugzilla, with the comment > containing the revision that fixed the bug. > * svn annotate on NEWS will indicate which revision fixed the bug. > * I cannot see any disadvantage in doing B. It looks to be less work > for a better/always up to date result. > (and of course, fallback to C if NEWS was forgotten to be updated > in a commit :). > > Feedback/opinion/... ? In general I like this proposal. But some nitpicks... The valgrind/VEX split makes B technically not always fully workable. That is also why sometimes you want to document which revision in which repo really fixed something. I would very much like us to merge the repos just for this reason. It isn't totally clear to me how we will use the NEWS file for major and minor releases. Where minor would be e.g. 3.9.1 which contains cherry-picked bug fixes from the trunk (which itself will become 3.10.0 or 4.0.0 at some point). The bug list is not just NEWS, but also the release managers (currently Julian's) notepad about the status of various bugs on various branches (minor/major). For this reason we might want to have both a BUGS file, which then contains current status of various bugs and a NEWS file which only contains descriptions of the bugs actually fixed (on the current branch?). > If ok to go for B, I will add a file README_DEVELOPERS_processes > (or any better name?) in SVN to document the "process" > with which a change is NEWS-documented as part of the commit. > > We might then later add descriptions of other processes > (e.g. how to make a release maybe ?). Yes please! :) Is there a description of how minor release branches in svn work (I am a bit of a svn noob, using a local git/svn bridge to actually push commits). I am slowly accumulating some patches for the fedora valgrind package which I think might make a good start for a minor 3.9.1 branch. > Note that it would be preferable to have the 3.9.0 branch merged > into the trunk to start editing NEWS for the next release. > Not clear to me if there is a reason to delay this merge. And maybe in the future swap the updating of NEWS. All changes to NEWS should first go onto trunk and only then backported/cherry-picked into a release branch NEWS version? Cheers, Mark |
|
From: Philippe W. <phi...@sk...> - 2013-11-19 20:21:29
|
On Tue, 2013-11-19 at 09:08 -0800, Patrick J. LoPresti wrote: > When partial-loads-ok is working correctly, I believe all of > Valgrind's str/mem intercepts are technically unnecessary. True, they > are faster... But that is an argument for intercepting every function > in the C library :-). Not too sure I understand. The str/mem interceptions will usually run slower than the C lib functions (as in most cases, these interceptions run fully on the simulated cpu and are not as optimised as the c lib functions). > > In my opinion, "--partial-loads-ok=yes" should be the default. It > would make 90% of the intercepts and default suppression rules > unnecessary. OK that is just a guess... But this is certainly a > pervasive source of Valgrind false positives. You could try to run all the regression tests giving --partial-load-ok=yes and use -v to look at the used suppressions and see which one are not used anymore. Philippe |
|
From: Philippe W. <phi...@sk...> - 2013-11-19 20:17:06
|
On Tue, 2013-11-19 at 09:06 +0100, Bart Van Assche wrote: > On 11/18/13 23:43, Philippe Waroquiers wrote: > > On Sun, 2013-11-17 at 14:05 +0100, Bart Van Assche wrote: > > > I think for all the functions intercepted by vg_replace_strmem.c there > is a risk that the non-intercepted optimized versions in glibc read past > the end of the input range(s). That means that not intercepting these > functions creates a risk that subtle and hard to analyze false positive > data races will be reported. I think the choice we have is a choice > between a tool that runs fast or a tool that works correctly :-) Effectively, correctness is the main criteria. However, if replacing a function which currently does not cause a false positive has a big impact on performance, then we better do not replace it until a false positive is detected. Philippe |
|
From: Bart V. A. <bva...@ac...> - 2013-11-19 17:55:19
|
On 11/19/13 18:08, Patrick J. LoPresti wrote: > On Tue, Nov 19, 2013 at 12:06 AM, Bart Van Assche <bva...@ac...> wrote: >> >> I think for all the functions intercepted by vg_replace_strmem.c there >> is a risk that the non-intercepted optimized versions in glibc read past >> the end of the input range(s). That means that not intercepting these >> functions creates a risk that subtle and hard to analyze false positive >> data races will be reported. I think the choice we have is a choice >> between a tool that runs fast or a tool that works correctly :-) > > Note that "--partial-loads-ok=yes" fixes these false positives. A fair > amount of work went in to Valgrind 3.9.0 to make it work for > vectorized memory and string operations on x86 and x86_64: > > https://bugs.kde.org/show_bug.cgi?id=294285 > https://bugs.kde.org/show_bug.cgi?id=294523 > https://bugs.kde.org/show_bug.cgi?id=308627 > https://bugs.kde.org/show_bug.cgi?id=309921 > > (I needed this to handle the output of the Intel compiler, which has a > habit of inlining mem*() and str*() functions extensively.) > > When partial-loads-ok is working correctly, I believe all of > Valgrind's str/mem intercepts are technically unnecessary. True, they > are faster... But that is an argument for intercepting every function > in the C library :-). > > In my opinion, "--partial-loads-ok=yes" should be the default. It > would make 90% of the intercepts and default suppression rules > unnecessary. OK that is just a guess... But this is certainly a > pervasive source of Valgrind false positives. >From what I see in the Valgrind source code the --partial-loads-ok option is supported by memcheck and exp-sgcheck but not by Helgrind nor by DRD. And as you write for memcheck the intercepts work faster than --partial-loads-ok=yes. So I think the patch at the start of this thread is really needed for Helgrind and DRD. Bart. |
|
From: Patrick J. L. <pa...@pa...> - 2013-11-19 17:08:44
|
On Tue, Nov 19, 2013 at 12:06 AM, Bart Van Assche <bva...@ac...> wrote: > > I think for all the functions intercepted by vg_replace_strmem.c there > is a risk that the non-intercepted optimized versions in glibc read past > the end of the input range(s). That means that not intercepting these > functions creates a risk that subtle and hard to analyze false positive > data races will be reported. I think the choice we have is a choice > between a tool that runs fast or a tool that works correctly :-) Note that "--partial-loads-ok=yes" fixes these false positives. A fair amount of work went in to Valgrind 3.9.0 to make it work for vectorized memory and string operations on x86 and x86_64: https://bugs.kde.org/show_bug.cgi?id=294285 https://bugs.kde.org/show_bug.cgi?id=294523 https://bugs.kde.org/show_bug.cgi?id=308627 https://bugs.kde.org/show_bug.cgi?id=309921 (I needed this to handle the output of the Intel compiler, which has a habit of inlining mem*() and str*() functions extensively.) When partial-loads-ok is working correctly, I believe all of Valgrind's str/mem intercepts are technically unnecessary. True, they are faster... But that is an argument for intercepting every function in the C library :-). In my opinion, "--partial-loads-ok=yes" should be the default. It would make 90% of the intercepts and default suppression rules unnecessary. OK that is just a guess... But this is certainly a pervasive source of Valgrind false positives. - Pat |
|
From: Mark W. <mj...@re...> - 2013-11-19 09:31:15
|
Hi Valgrind Hackers and Users,
We are still looking for some more people wanting to present a talk or
just informally discuss some technical issues at the valgrind developer
room at FOSDEM, Sunday 2 Feb 2014 in Brussels, Belgium.
It would be helpful if proposals were submitted before:
SUNDAY 8 DECEMBER (<- PROPOSAL DEADLINE!)
That way we can create a schedule beforehand.
See below for some suggestions and details on how to submit a proposal.
But please do feel free to suggest anything you feel is interesting
around valgrind and just email us with a proposal or idea instead of
doing things through the penta system if that is easier or you just want
some feedback on an idea first.
We are also still looking for volunteers to create video recordings in
the developer room. Again, details below.
The important dates:
Video Volunteers: Before 30 Nov 2013
Talk/Discussion Submission deadline: Sunday 8 Dec 2013
Devroom Schedule announcement: Sunday 15 Dec 2013
Devroom day: Sunday 2 Feb 2014
Valgrind developer room at FOSDEM 2014 (Brussels, Belgium, 2 February).
FOSDEM is a free software event that offers open source communities a
place to meet, share ideas and collaborate. It is renowned for being
highly developer-oriented and brings together 5000+ hackers from all
over the world. Taking place in the city of Brussels (Belgium).
http://fosdem.org/
FOSDEM 2014 will take place during the weekend of Saturday, February 1st
and Sunday, February 2nd. On Sunday we will have a devroom for Valgrind.
Devrooms are a place for development teams to meet, discuss, hack and
publicly present the project latest improvements and future directions.
We will have a whole day to hang out together as Valgrind community.
Please join us whether you are a Valgrind core hacker, Valgrind tool
hacker, Valgrind user, Valgrind packager or hacker on a project that
integrates, extends or complements Valgrind.
Call For Participation
We would like to organize a series of talks/discussions on various
topics relevant to both core hackers, new developers, users, packagers
and cross project functionality. Please do submit a talk proposal before
Sunday December 8th 2013, so we can make a list of activities during the
day.
Some possible topics for talks/discussions are:
- The recently added functional changes (for valgrind users).
- State of the valgrind code base (core hackers).
- Helgrind - basic design, problems and opportunities (core and tools).
- Get feedback on what what kinds of new functionality would
be useful. Which tools users would like to see and/or which new
features for the existing tools. (valgrind developers and users).
- Modify memcheck to report the last leaked pointer to a block
integrate "omega" as a memcheck option or omega as a separate tool.
- Better support compiled and JITted code.
allowing the JIT compiler to indicate the link between
the JITted code and the source code.
- Valgrind and transactional memory.
- How to add simple features (adding syscalls for a platform or VEX
instructions for a architecture port). (new core developers).
- Making Valgrind really multi-threaded, parallelising Memcheck
parallelising the rest of the framework, and tools (for core hackers).
- Should we continue to support MacOS? What about Valgrind on
MS-Windows? Solaris? (attracting new hackers).
- Redo the JIT framework to reduce baseline overheads? (core hackers).
- Make Callgrind work sanely on ARM (core hackers).
- Discuss release/bugfixing strategy/policy (core hackers, packagers).
- Packaging valgrind for distros, handling patches, suppressions, etc.
(packagers).
- Valgrind/GDB integration (cross project).
- Valgrind vs the compiler. Compilers like GCC and clang now have
"valgrind like" features -fsanitize=address|thread|undefined.
How does valgrind complement or improve on these features?
- Eclipse and other visualisation tools for valgrind (cross project).
- Practical examples of using Valgrind in (big) systems automatic
regression testing (users).
Use the FOSDEM 'pentabarf' tool to submit your proposal.
https://penta.fosdem.org/submission/FOSDEM14/
- If necessary, create a Pentabarf account and activate it.
- In the "Person" section, provide First name, Last name
(in the "General" tab), Email (in the "Contact" tab)
and Bio ("Abstract" field in the "Description" tab).
- Submit a proposal by clicking on "Create event".
- Important! Select the "Valgrind devroom" track
(on the "General" tab).
- Provide the title of your talk ("Event title" in the "General" tab).
- Provide a description of the subject of the talk and the
intended audience (in the "Abstract" field of the "Description" tab)
- Provide a rough outline of the talk or goals of the session (a short
list of bullet points covering topics that will be discussed) in the
"Full description" field in the "Description" tab
Julian, Philippe and Mark will review the proposals and organize the
schedule for the day. Please feel free to suggest or discuss any ideas
for the devroom on the Valgrind developer mailinglist before creating a
proposal: val...@li...
Call For (Video) Volunteers
The FOSDEM organization can provide us with equipment to record some or
all of the talks in our devroom. But we need at least two volunteers to
do the actual recordings. An ideal candidate for this job would be
someone who is going to be watching talks in the Valgrind devroom most
(or all) of the time anyway, and who doesn't mind watching after a
camera and/or an audio mixer while watching the talk.
While some A/V experience is obviously useful for the volunteer, it is
absolutely not required; FOSDEM will provide the right gear and help set
it up, and FOSDEM organizers will also provide enough information so the
volunteers know what to do. This will include a live training session
during the opening talk (in Janson) for those who want it.
If you want to help record talks/discussions in the Valgrind devroom
please let us know before the end of November.
Important dates:
Video Volunteers: Before 30 Nov 2013
Talk/Discussion Submission deadline: Sunday 8 Dec 2013
Devroom Schedule announcement: Sunday 15 Dec 2013
Devroom day: Sunday 2 Feb 2014
Hope to see you all at FOSDEM 2014 in the Valgrind devroom.
Brussels (Belgium), Sunday 2 February, 2014.
https://fosdem.org/2014/schedule/track/valgrind/
|
|
From: Bart V. A. <bva...@ac...> - 2013-11-19 08:06:28
|
On 11/18/13 23:43, Philippe Waroquiers wrote: > On Sun, 2013-11-17 at 14:05 +0100, Bart Van Assche wrote: >> There is quite some duplicate code in mc_replace_strmem.c, hg_intercepts.c >> and drd_strmem_intercepts.c, hence this patch that merges these files. This >> patch moves memcheck/mc_replace_strmem.c to shared/vg_replace_strmem.c and >> adds several intercepts for SSE-variants. Include that source file from >> drd/drd_strmem_intercepts.c, helgrind/hg_intercepts.c and >> memcheck/mc_replace_strmem.c. The test filters that depend on the file >> name of the file with the intercept code are updated. > This patch looks a really good idea to me. > > Minor comments and a question below ... > >> diff --git a/shared/vg_replace_strmem.c b/shared/vg_replace_strmem.c >> new file mode 100644 >> index 0000000..110543c >> --- /dev/null >> +++ b/shared/vg_replace_strmem.c >> @@ -0,0 +1,1836 @@ >> + >> +/*--------------------------------------------------------------------*/ >> +/*--- Replacements for strcpy(), memcpy() et al, which run on the ---*/ >> +/*--- simulated CPU. ---*/ >> +/*--- mc_replace_strmem.c ---*/ > vg_replace_strmem.c > >> + >> +/* >> + This file is part of MemCheck, a heavyweight Valgrind tool for > part of Valgrind, used e.g. by memcheck/helgrind/drd ? > > >> +/* Assignment of behavioural equivalence class tags: 2NNNP is intended >> + to be reserved for Memcheck. Current usage: > ^^^^^^^^^^^^^^^^^^^^^ is that still the case ? > or is it now also used for helgrind and drd ? Thanks for the feedback, I will update that comment. > Finally, one question: > Currently, helgrind replaces a small nr of functions. With this patch, > a bigger nr of functions will be replaced. > Can there be a (significant) performance impact of these additional > (maybe not mandatory?) replacements ? I think for all the functions intercepted by vg_replace_strmem.c there is a risk that the non-intercepted optimized versions in glibc read past the end of the input range(s). That means that not intercepting these functions creates a risk that subtle and hard to analyze false positive data races will be reported. I think the choice we have is a choice between a tool that runs fast or a tool that works correctly :-) Bart. |
|
From: Philippe W. <phi...@sk...> - 2013-11-18 22:43:07
|
On Sun, 2013-11-17 at 14:05 +0100, Bart Van Assche wrote:
> There is quite some duplicate code in mc_replace_strmem.c, hg_intercepts.c
> and drd_strmem_intercepts.c, hence this patch that merges these files. This
> patch moves memcheck/mc_replace_strmem.c to shared/vg_replace_strmem.c and
> adds several intercepts for SSE-variants. Include that source file from
> drd/drd_strmem_intercepts.c, helgrind/hg_intercepts.c and
> memcheck/mc_replace_strmem.c. The test filters that depend on the file
> name of the file with the intercept code are updated.
This patch looks a really good idea to me.
Minor comments and a question below ...
> diff --git a/shared/vg_replace_strmem.c b/shared/vg_replace_strmem.c
> new file mode 100644
> index 0000000..110543c
> --- /dev/null
> +++ b/shared/vg_replace_strmem.c
> @@ -0,0 +1,1836 @@
> +
> +/*--------------------------------------------------------------------*/
> +/*--- Replacements for strcpy(), memcpy() et al, which run on the ---*/
> +/*--- simulated CPU. ---*/
> +/*--- mc_replace_strmem.c ---*/
vg_replace_strmem.c
> +
> +/*
> + This file is part of MemCheck, a heavyweight Valgrind tool for
part of Valgrind, used e.g. by memcheck/helgrind/drd ?
> +/* Assignment of behavioural equivalence class tags: 2NNNP is intended
> + to be reserved for Memcheck. Current usage:
^^^^^^^^^^^^^^^^^^^^^ is that still the case ?
or is it now also used for helgrind and drd ?
Finally, one question:
Currently, helgrind replaces a small nr of functions. With this patch,
a bigger nr of functions will be replaced.
Can there be a (significant) performance impact of these additional
(maybe not mandatory?) replacements ?
Thanks
Philippe
|
|
From: Philippe W. <phi...@sk...> - 2013-11-18 05:42:08
|
valgrind revision: 13714 VEX revision: 2799 C compiler: gcc (GCC) 4.7.2 20121109 (Red Hat 4.7.2-8) GDB: GNU gdb (GDB) Fedora (7.5.1-37.fc18) Assembler: GNU assembler version 2.23.51.0.1-7.fc18 20120806 C library: GNU C Library stable release version 2.16 uname -mrs: Linux 3.8.8-202.fc18.ppc64p7 ppc64 Vendor version: Fedora release 18 (Spherical Cow) Nightly build on gcc110 ( Fedora release 18 (Spherical Cow), ppc64 ) Started at 2013-11-17 20:00:06 PST Ended at 2013-11-17 21:39:22 PST 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 == 570 tests, 32 stderr failures, 3 stdout failures, 0 stderrB failures, 0 stdoutB failures, 2 post failures == memcheck/tests/linux/getregset (stdout) memcheck/tests/linux/getregset (stderr) memcheck/tests/ppc64/power_ISA2_05 (stdout) memcheck/tests/supp_unknown (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/wrap8 (stdout) memcheck/tests/wrap8 (stderr) massif/tests/big-alloc (post) massif/tests/deep-D (post) helgrind/tests/annotate_rwlock (stderr) helgrind/tests/free_is_write (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/locked_vs_unlocked1_fwd (stderr) helgrind/tests/locked_vs_unlocked1_rev (stderr) helgrind/tests/locked_vs_unlocked2 (stderr) helgrind/tests/locked_vs_unlocked3 (stderr) helgrind/tests/pth_barrier1 (stderr) helgrind/tests/pth_barrier2 (stderr) helgrind/tests/pth_barrier3 (stderr) helgrind/tests/pth_cond_destroy_busy (stderr) helgrind/tests/pth_destroy_cond (stderr) helgrind/tests/rwlock_race (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) --tools=none,memcheck,callgrind,helgrind,cachegrind,drd,massif --reps=3 --vg=../valgrind-new --vg=../valgrind-old -- Running tests in perf ---------------------------------------------- -- bigcode1 -- bigcode1 valgrind-new:0.26s no: 1.7s ( 6.5x, -----) me: 3.1s (11.9x, -----) ca:18.7s (71.8x, -----) he: 1.7s ( 6.5x, -----) ca: 5.3s (20.5x, -----) dr: 1.6s ( 6.3x, -----) ma: 2.1s ( 8.1x, -----) bigcode1 valgrind-old:0.26s no: 1.6s ( 6.0x, 8.8%) me: 2.8s (10.8x, 9.0%) ca:18.8s (72.2x, -0.5%) he: 1.7s ( 6.5x, -0.0%) ca: 5.5s (21.0x, -2.8%) dr: 1.6s ( 6.3x, 0.0%) ma: 2.1s ( 8.1x, 0.5%) -- bigcode2 -- bigcode2 valgrind-new:0.23s no: 1.5s ( 6.7x, -----) me: 2.9s (12.7x, -----) ca:18.9s (82.0x, -----) he: 2.1s ( 9.0x, -----) ca: 5.4s (23.7x, -----) dr: 1.8s ( 7.9x, -----) ma: 2.1s ( 9.2x, -----) bigcode2 valgrind-old:0.23s no: 1.5s ( 6.6x, 1.9%) me: 2.9s (12.6x, 0.7%) ca:18.9s (82.0x, 0.1%) he: 2.1s ( 9.1x, -1.0%) ca: 5.5s (23.7x, -0.2%) dr: 1.8s ( 7.9x, 0.0%) ma: 2.1s ( 9.2x, 0.5%) -- bz2 -- bz2 valgrind-new:0.72s no: 4.6s ( 6.3x, -----) me:12.0s (16.6x, -----) ca:26.6s (37.0x, -----) he:14.5s (20.2x, -----) ca:24.5s (34.0x, -----) dr:19.4s (26.9x, -----) ma: 4.7s ( 6.5x, -----) bz2 valgrind-old:0.72s no: 4.5s ( 6.3x, 0.2%) me:12.1s (16.8x, -1.2%) ca:26.6s (36.9x, 0.2%) he:15.0s (20.9x, -3.4%) ca:24.3s (33.7x, 0.9%) dr:19.4s (26.9x, 0.2%) ma: 4.7s ( 6.5x, 0.0%) -- fbench -- fbench valgrind-new:0.34s no: 2.1s ( 6.1x, -----) me: 5.3s (15.5x, -----) ca: 8.6s (25.3x, -----) he: 5.1s (14.9x, -----) ca: 7.6s (22.4x, -----) dr: 5.0s (14.6x, -----) ma: 2.1s ( 6.3x, -----) fbench valgrind-old:0.34s no: 2.1s ( 6.2x, -1.9%) me: 5.2s (15.3x, 1.5%) ca: 8.6s (25.2x, 0.3%) he: 5.0s (14.9x, 0.6%) ca: 7.5s (22.1x, 1.3%) dr: 4.9s (14.4x, 1.6%) ma: 2.1s ( 6.3x, -0.5%) -- ffbench -- ffbench valgrind-new:0.45s no: 1.3s ( 2.9x, -----) me: 2.5s ( 5.7x, -----) ca: 2.5s ( 5.6x, -----) he: 6.9s (15.3x, -----) ca: 7.3s (16.3x, -----) dr: 5.1s (11.4x, -----) ma: 1.0s ( 2.3x, -----) ffbench valgrind-old:0.45s no: 1.3s ( 2.9x, 0.8%) me: 2.6s ( 5.7x, -0.8%) ca: 2.5s ( 5.6x, 0.4%) he: 7.0s (15.5x, -1.0%) ca: 7.1s (15.8x, 3.1%) dr: 5.2s (11.5x, -0.4%) ma: 1.0s ( 2.2x, 1.0%) -- heap -- heap valgrind-new:0.41s no: 2.5s ( 6.0x, -----) me: 9.9s (24.1x, -----) ca:13.5s (32.9x, -----) he:12.7s (30.9x, -----) ca:12.0s (29.2x, -----) dr: 7.9s (19.3x, -----) ma: 8.7s (21.3x, -----) heap valgrind-old:0.41s no: 2.4s ( 5.7x, 4.1%) me:10.0s (24.4x, -1.1%) ca:13.5s (33.0x, -0.2%) he:12.8s (31.1x, -0.9%) ca:12.1s (29.5x, -0.8%) dr: 8.0s (19.5x, -1.3%) ma: 8.6s (20.9x, 1.8%) -- heap_pdb4 -- heap_pdb4 valgrind-new:0.42s no: 2.6s ( 6.3x, -----) me:14.0s (33.4x, -----) ca:14.4s (34.3x, -----) he:14.5s (34.5x, -----) ca:13.3s (31.6x, -----) dr: 9.0s (21.4x, -----) ma: 8.9s (21.2x, -----) heap_pdb4 valgrind-old:0.42s no: 2.6s ( 6.1x, 3.4%) me:14.1s (33.7x, -0.9%) ca:14.4s (34.4x, -0.3%) he:14.4s (34.4x, 0.3%) ca:13.1s (31.1x, 1.6%) dr: 8.9s (21.2x, 1.0%) ma: 8.9s (21.2x, -0.1%) -- many-loss-records -- many-loss-records valgrind-new:0.03s no: 0.5s (17.3x, -----) me: 2.9s (95.0x, -----) ca: 2.0s (66.3x, -----) he: 2.0s (66.3x, -----) ca: 1.8s (61.3x, -----) dr: 1.6s (51.7x, -----) ma: 1.6s (53.3x, -----) many-loss-records valgrind-old:0.03s no: 0.5s (17.3x, 0.0%) me: 2.2s (73.3x, 22.8%) ca: 1.9s (62.7x, 5.5%) he: 2.0s (66.3x, 0.0%) ca: 1.8s (61.3x, -0.0%) dr: 1.6s (51.7x, 0.0%) ma: 1.6s (53.0x, 0.6%) -- many-xpts -- many-xpts valgrind-new:0.07s no: 0.7s (10.3x, -----) me: 3.4s (48.3x, -----) ca: 4.7s (67.6x, -----) he: 5.0s (71.9x, -----) ca: 2.9s (41.4x, -----) dr: 2.3s (32.7x, -----) ma: 2.3s (33.1x, -----) many-xpts valgrind-old:0.07s no: 0.7s (10.4x, -1.4%) me: 3.4s (48.4x, -0.3%) ca: 4.7s (67.6x, 0.0%) he: 5.0s (71.9x, 0.0%) ca: 2.9s (41.3x, 0.3%) dr: 2.3s (32.7x, 0.0%) ma: 2.3s (33.3x, -0.4%) -- sarp -- sarp valgrind-new:0.02s no: 0.4s (20.0x, -----) me: 3.5s (176.0x, -----) ca: 2.9s (145.0x, -----) he:11.0s (551.5x, -----) ca: 1.7s (84.0x, -----) dr: 1.2s (58.0x, -----) ma: 0.4s (21.0x, -----) sarp valgrind-old:0.02s no: 0.4s (19.5x, 2.5%) me: 3.5s (176.0x, 0.0%) ca: 2.9s (145.0x, 0.0%) he:11.1s (556.0x, -0.8%) ca: 1.7s (83.5x, 0.6%) dr: 1.2s (58.0x, 0.0%) ma: 0.4s (21.0x, 0.0%) -- tinycc -- tinycc valgrind-new:0.28s no: 3.0s (10.6x, -----) me:14.0s (50.1x, -----) ca:17.4s (62.2x, -----) he:18.9s (67.6x, -----) ca:15.7s (56.2x, -----) dr:12.0s (42.9x, -----) ma: 3.8s (13.7x, -----) tinycc valgrind-old:0.28s no: 3.0s (10.6x, -0.3%) me:14.0s (50.0x, 0.2%) ca:17.4s (62.2x, 0.0%) he:18.9s (67.6x, 0.1%) ca:15.7s (56.0x, 0.3%) dr:11.9s (42.7x, 0.4%) ma: 3.8s (13.7x, 0.0%) -- Finished tests in perf ---------------------------------------------- == 11 programs, 154 timings ================= real 54m56.095s user 53m6.800s sys 0m20.648s |
|
From: Tom H. <to...@co...> - 2013-11-18 04:35:46
|
valgrind revision: 13714 VEX revision: 2799 C compiler: gcc (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8) GDB: Assembler: GNU assembler version 2.18.50.0.6-2 20080403 C library: GNU C Library stable release version 2.8 uname -mrs: Linux 3.9.5-301.fc19.x86_64 x86_64 Vendor version: Fedora release 9 (Sulphur) Nightly build on bristol ( x86_64, Fedora 9 ) Started at 2013-11-18 03:57:53 GMT Ended at 2013-11-18 04:35:28 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 == 645 tests, 1 stderr failure, 1 stdout failure, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/amd64/insn-pcmpistri (stderr) none/tests/amd64/sse4-64 (stdout) |