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
(3) |
|
2
(8) |
3
(19) |
4
(24) |
5
(23) |
6
(16) |
7
(33) |
8
(5) |
|
9
(4) |
10
(23) |
11
(22) |
12
(40) |
13
(30) |
14
(31) |
15
(17) |
|
16
(18) |
17
(20) |
18
(41) |
19
(36) |
20
(25) |
21
(8) |
22
(9) |
|
23
(17) |
24
(12) |
25
(15) |
26
(15) |
27
(16) |
28
(22) |
29
(6) |
|
30
(7) |
31
(10) |
|
|
|
|
|
|
From: Nicholas N. <n.n...@gm...> - 2009-08-04 22:24:50
|
[Resending; please respond to the list, not just to me personally. That's standard etiquette for mailing lists.] On Wed, Aug 5, 2009 at 7:31 AM, Ayan Chowdhury<ach...@vm...> wrote: > Please bear with my ignorance. I am really new to valgrind debugging. > > Did you want me to run the program with valgrind -d -v option and give you the output? OR you just valgrind -d -v output? I am pasting both below. Thanks a lot for looking at them. I meant: use your original command line, but with -v and -d added (after 'valgrind', but before the name of your program). Nick > If it is without the program: > ================================== > > [root@osdc-vimcpd005 bin]# ./valgrind -d -v > --23544:1:debuglog DebugLog system started by Stage 1, level 1 logging requested > --23544:1:launcher no tool requested, defaulting to 'memcheck' > --23544:1:launcher no client specified, defaulting platform to 'x86-linux' > --23544:1:launcher launching /root/valgrind341/lib/valgrind/x86-linux/memcheck > --23544:1:debuglog DebugLog system started by Stage 2 (main), level 1 logging requested > --23544:1:main Welcome to Valgrind version 3.4.1 debug logging > --23544:1:main Checking current stack is plausible > --23544:1:main Checking initial stack was noted > --23544:1:main Starting the address space manager > --23544:1:main Address space manager is running > --23544:1:main Starting the dynamic memory manager > --23544:1:mallocfr newSuperblock at 0x61FFF000 (pszB 4194288) owner VALGRIND/tool > --23544:1:main Dynamic memory manager is running > --23544:1:main Initialise m_debuginfo > --23544:1:main Getting stage1's name > --23544:1:main Get hardware capabilities ... > --23544:1:main ... arch = X86, hwcaps = x86-sse1-sse2 > --23544:1:main Getting the working directory at startup > --23544:1:main ... /root/valgrind341/bin > --23544:1:main Split up command line > --23544:1:main (early_) Process Valgrind's command line options > --23544:1:main Create initial image > --23544:1:initimg Loading client > valgrind: no program specified > > > With the program: > ================ > > ==23409== Memcheck, a memory error detector. > ==23409== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al. > ==23409== Using LibVEX rev 1884, a library for dynamic binary translation. > ==23409== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. > ==23409== Using valgrind-3.4.1, a dynamic binary instrumentation framework. > ==23409== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. > ==23409== > ==23409== My PID = 23409, parent PID = 23404. Prog and args are: > ==23409== /opt/vmware/aam/bin/ftAgent > ==23409== -d > ==23409== vmware > ==23409== about > ==23409== to > ==23409== execute: > ==23409== /root/valgrind341/bin/valgrind > ==23409== -d > ==23409== -v > ==23409== --trace-children=yes > ==23409== --track-fds=yes > ==23409== --log-file=/var/log/vmware/aam/valgrind.out.%p > ==23409== --leak-check=yes > ==23409== /opt/vmware/aam/bin/ftAgent > ==23409== -d > ==23409== vmware > ==23409== > --23409-- > --23409-- Command line > --23409-- /opt/vmware/aam/bin/ftAgent > --23409-- -d > --23409-- vmware > --23409-- about > --23409-- to > --23409-- execute: > --23409-- /root/valgrind341/bin/valgrind > --23409-- -d > --23409-- -v > --23409-- --trace-children=yes > --23409-- --track-fds=yes > --23409-- --log-file=/var/log/vmware/aam/valgrind.out.%p > --23409-- --leak-check=yes > --23409-- /opt/vmware/aam/bin/ftAgent > --23409-- -d > --23409-- vmware > --23409-- Startup, with flags: > --23409-- -d > --23409-- -v > --23409-- --trace-children=yes > --23409-- --track-fds=yes > --23409-- --log-file=/var/log/vmware/aam/valgrind.out.%p > --23409-- --leak-check=yes > --23409-- Contents of /proc/version: > --23409-- Linux version 2.4.21-57.ELvmnix (mt...@pa...) (gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-14)) #1 Fri Mar 13 14:33:50 PDT 2009[VMnix version 153875] > --23409-- Arch and hwcaps: X86, x86-sse1-sse2 > --23409-- Page sizes: currently 4096, max supported 4096 > --23409-- Valgrind library directory: /root/valgrind341/lib/valgrind > --23409-- Reading syms from /lib/ld-2.3.2.so (0x4000000) > --23409-- Reading syms from /opt/vmware/aam/bin/ftAgent (0x8048000) > --23409-- object doesn't have a symbol table > --23409-- Reading syms from /root/valgrind341/lib/valgrind/x86-linux/memcheck (0x38000000) > --23409-- object doesn't have a dynamic symbol table > --23409-- Reading suppressions file: /root/valgrind341/lib/valgrind/default.supp > --23409-- REDIR: 0x4012140 (index) redirected to 0x38031193 (vgPlain_x86_linux_REDIR_FOR_index) > --23409-- Reading syms from /root/valgrind341/lib/valgrind/x86-linux/vgpreload_core.so (0x4017000) > --23409-- Reading syms from /root/valgrind341/lib/valgrind/x86-linux/vgpreload_memcheck.so (0x4019000) > ==23409== WARNING: new redirection conflicts with existing -- ignoring it > --23409-- new: 0x04012140 (index ) R-> 0x0401c8dc index > --23409-- REDIR: 0x40122e0 (strlen) redirected to 0x401cb00 (strlen) > --23409-- Reading syms from /opt/vmware/aam/lib/libramd_svr.so (0x4020000) > --23409-- Reading syms from /opt/vmware/aam/lib/libadm_ramd.so (0x404b000) > --23409-- Reading syms from /opt/vmware/aam/lib/libapm_ramd.so (0x4053000) > --23409-- Reading syms from /opt/vmware/aam/lib/libatm_ramd.so (0x4071000) > --23409-- Reading syms from /opt/vmware/aam/lib/libcm_ramd.so (0x4075000) > --23409-- Reading syms from /opt/vmware/aam/lib/libfdm_ramd.so (0x4080000) > --23409-- Reading syms from /opt/vmware/aam/lib/libim_ramd.so (0x4085000) > --23409-- Reading syms from /opt/vmware/aam/lib/libnm_ramd.so (0x4092000) > --23409-- Reading syms from /opt/vmware/aam/lib/librum_ramd.so (0x40a1000) > --23409-- Reading syms from /opt/vmware/aam/lib/librmgr_clt.so (0x40ac000) > --23409-- Reading syms from /opt/vmware/aam/lib/libsam_ramd.so (0x40af000) > --23409-- Reading syms from /opt/vmware/aam/lib/libsm_pxy.so (0x40c5000) > --23409-- Reading syms from /opt/vmware/aam/lib/libsm_clt.so (0x40c8000) > --23409-- Reading syms from /opt/vmware/aam/lib/libprocmon_clt.so (0x40ca000) > --23409-- Reading syms from /opt/vmware/aam/lib/libsec_ramd.so (0x40cd000) > --23409-- Reading syms from /opt/vmware/aam/lib/libem_ramd.so (0x40d5000) > --23409-- Reading syms from /opt/vmware/aam/lib/libem.so (0x40dc000) > --23409-- Reading syms from /opt/vmware/aam/lib/libupm_ramd.so (0x40e0000) > --23409-- Reading syms from /opt/vmware/aam/lib/libramd_pxy.so (0x40e8000) > --23409-- Reading syms from /opt/vmware/aam/lib/libramd_clt.so (0x4102000) > --23409-- Reading syms from /opt/vmware/aam/lib/libapm.so (0x411c000) > --23409-- Reading syms from /opt/vmware/aam/lib/libdbm_ramd.so (0x411f000) > --23409-- Reading syms from /opt/vmware/aam/lib/libencode.so (0x41b7000) > --23409-- Reading syms from /opt/vmware/aam/lib/libconsts.so (0x4210000) > --23409-- Reading syms from /opt/vmware/aam/lib/libcommon_ramd.so (0x4256000) > --23409-- Reading syms from /opt/vmware/aam/lib/libcommon.so (0x4274000) > --23409-- Reading syms from /opt/vmware/aam/lib/librc_tnet.so (0x4288000) > --23409-- Reading syms from /opt/vmware/aam/lib/libtrace.so (0x428b000) > --23409-- Reading syms from /lib/libnsl-2.3.2.so (0x42b2000) > --23409-- Reading syms from /lib/tls/libpthread-0.60.so (0x42c7000) > --23409-- Reading syms from /lib/libdl-2.3.2.so (0x42d7000) > --23409-- Reading syms from /opt/vmware/aam/lib/libvmkuser.so.0 (0x42da000) > --23409-- Reading syms from /lib/tls/libm-2.3.2.so (0x4338000) > --23409-- Reading syms from /lib/tls/libc-2.3.2.so (0x435a000) > --23409-- Reading syms from /lib/libgcc_s-3.2.3-20040701.so.1 (0x4494000) > --23409-- object doesn't have a symbol table > --23409-- REDIR: 0x43d3fd0 (memset) redirected to 0x401d5e4 (memset) > --23409-- REDIR: 0x43d2ad0 (rindex) redirected to 0x401c804 (rindex) > --23409-- REDIR: 0x43d27a0 (strlen) redirected to 0x401cae4 (strlen) > --23409-- REDIR: 0x43d2980 (strncmp) redirected to 0x401cd14 (strncmp) > --23409-- REDIR: 0x43d2a40 (strncpy) redirected to 0x401cbf0 (strncpy) > --23409-- REDIR: 0x43d1300 (strcat) redirected to 0x401c924 (strcat) > --23409-- REDIR: 0x43d4020 (mempcpy) redirected to 0x401d7e0 (mempcpy) > --23409-- REDIR: 0x43cb1f0 (free) redirected to 0x401b874 (free) > ==23409== > ==23409== FILE DESCRIPTORS: 4 open at exit. > ==23409== Open file descriptor 3: /var/log/vmware/aam/valgrind.out.23409 > ==23409== <inherited from parent> > ==23409== > ==23409== Open file descriptor 2: > ==23409== <inherited from parent> > ==23409== > ==23409== Open file descriptor 1: > ==23409== <inherited from parent> > ==23409== > ==23409== Open file descriptor 0: /dev/null > ==23409== <inherited from parent> > ==23409== > ==23409== > ==23409== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 83 from 1) > --23409-- > --23409-- supp: 83 Ubuntu-stripped-ld.so > ==23409== malloc/free: in use at exit: 0 bytes in 0 blocks. > ==23409== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. > ==23409== > ==23409== All heap blocks were freed -- no leaks are possible. > --23409-- memcheck: sanity checks: 5 cheap, 2 expensive > --23409-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use > --23409-- memcheck: auxmaps_L1: 0 searches, 0 cmps, ratio 0:10 > --23409-- memcheck: auxmaps_L2: 0 searches, 0 nodes > --23409-- memcheck: SMs: n_issued = 32 (512k, 0M) > --23409-- memcheck: SMs: n_deissued = 0 (0k, 0M) > --23409-- memcheck: SMs: max_noaccess = 65535 (1048560k, 1023M) > --23409-- memcheck: SMs: max_undefined = 0 (0k, 0M) > --23409-- memcheck: SMs: max_defined = 59 (944k, 0M) > --23409-- memcheck: SMs: max_non_DSM = 32 (512k, 0M) > --23409-- memcheck: max sec V bit nodes: 1 (0k, 0M) > --23409-- memcheck: set_sec_vbits8 calls: 1 (new: 1, updates: 0) > --23409-- memcheck: max shadow mem size: 816k, 0M > --23409-- translate: fast SP updates identified: 3,321 ( 89.5%) > --23409-- translate: generic_known SP updates identified: 111 ( 2.9%) > --23409-- translate: generic_unknown SP updates identified: 275 ( 7.4%) > --23409-- tt/tc: 5,576 tt lookups requiring 5,682 probes > --23409-- tt/tc: 5,576 fast-cache updates, 3 flushes > --23409-- transtab: new 2,678 (53,537 -> 808,737; ratio 151:10) [0 scs] > --23409-- transtab: dumped 0 (0 -> ??) > --23409-- transtab: discarded 8 (193 -> ??) > --23409-- scheduler: 592,395 jumps (bb entries). > --23409-- scheduler: 5/3,245 major/minor sched events. > --23409-- sanity: 6 cheap, 2 expensive checks. > --23409-- exectx: 769 lists, 383 contexts (avg 0 per list) > --23409-- exectx: 508 searches, 219 full compares (431 per 1000) > --23409-- exectx: 0 cmp2, 192 cmp4, 0 cmpAll > --23409-- errormgr: 10 supplist searches, 12 comparisons during search > --23409-- errormgr: 83 errlist searches, 192 comparisons during search > > > > -----Original Message----- > From: Nicholas Nethercote [mailto:n.n...@gm...] > Sent: Monday, August 03, 2009 6:19 PM > To: Ayan Chowdhury > Cc: val...@li... > Subject: Re: [Valgrind-developers] A urgent help needed > > On Tue, Aug 4, 2009 at 6:50 AM, Ayan Chowdhury<ach...@vm...> wrote: >> Hi, >> >> I was trying to get my application up with valgrind. I was using the >> following valgrind options. >> >> "/root/valgrind341/bin/valgrind --trace-children=yes --track-fds=yes >> --log-file=/var/log/vmware/aam/valgrind.out.%p --leak-check=yes >> --show-reachable=yes --leak-resolution=high --num-callers=40 >> >> But getting the following error when getting the program running. >> >> >> valgrind: mmap(0x38000000, 1503232) failed in UME with error 22 >> (Invalid argument). >> valgrind: this can be caused by executables with very large text, data >> or bss segments. > > Does your program have a very large text, data or bss segment? Eg. > does it contain any very large static arrays? > > If you give the output of "valgrind -d -v" that would be helpful. > > Nick > |
|
From: Nicholas N. <n.n...@gm...> - 2009-08-04 17:35:37
|
Nightly build on ocean32 ( Ubuntu 9.04, x86_64 (32-bit only) )
Started at 2009-08-05 03:00:01 EST
Ended at 2009-08-05 03:35:22 EST
Results differ from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... failed
Regression test results follow
== 482 tests, 9 stderr failures, 1 stdout failure, 0 post failures ==
memcheck/tests/origin5-bz2 (stderr)
none/tests/empty-exe (stderr)
none/tests/shell (stdout)
none/tests/shell (stderr)
none/tests/shell_valid1 (stderr)
none/tests/shell_valid2 (stderr)
none/tests/shell_valid3 (stderr)
none/tests/shell_zerolength (stderr)
helgrind/tests/tc06_two_races_xml (stderr)
exp-ptrcheck/tests/supp (stderr)
=================================================
== Results from 24 hours ago ==
=================================================
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... failed
Regression test results follow
== 483 tests, 9 stderr failures, 1 stdout failure, 0 post failures ==
memcheck/tests/origin5-bz2 (stderr)
none/tests/empty-exe (stderr)
none/tests/shell (stdout)
none/tests/shell (stderr)
none/tests/shell_valid1 (stderr)
none/tests/shell_valid2 (stderr)
none/tests/shell_valid3 (stderr)
none/tests/shell_zerolength (stderr)
helgrind/tests/tc06_two_races_xml (stderr)
exp-ptrcheck/tests/supp (stderr)
=================================================
== Difference between 24 hours ago and now ==
=================================================
*** old.short Wed Aug 5 03:19:16 2009
--- new.short Wed Aug 5 03:35:22 2009
***************
*** 8,10 ****
! == 483 tests, 9 stderr failures, 1 stdout failure, 0 post failures ==
memcheck/tests/origin5-bz2 (stderr)
--- 8,10 ----
! == 482 tests, 9 stderr failures, 1 stdout failure, 0 post failures ==
memcheck/tests/origin5-bz2 (stderr)
=================================================
./valgrind-new/exp-ptrcheck/tests/supp.stderr.diff
=================================================
--- supp.stderr.exp 2009-08-05 03:19:58.000000000 +1000
+++ supp.stderr.out 2009-08-05 03:35:19.000000000 +1000
@@ -1,7 +1,7 @@
Syscall param write(buf) is non-contiguous
- at 0x........: write (in /...libc...)
- by 0x........: main (supp.c:16)
+ at 0x........: ??? (in /lib32/ld-2.9.so)
+ by 0x........: (below main)
First byte (0x........) is 3 bytes inside a 6-byte block alloc'd
at 0x........: malloc (vg_replace_malloc.c:...)
by 0x........: main (supp.c:12)
=================================================
./valgrind-new/helgrind/tests/tc06_two_races_xml.stderr.diff
=================================================
--- tc06_two_races_xml.stderr.exp 2009-08-05 03:19:46.000000000 +1000
+++ tc06_two_races_xml.stderr.out 2009-08-05 03:32:49.000000000 +1000
@@ -44,16 +44,6 @@
<frame>
<ip>0x........</ip>
<obj>...</obj>
- <fn>do_clone</fn>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>pthread_create@@GLIBC_2.2.5</fn>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
<fn>pthread_create_WRK</fn>
<dir>...</dir>
<file>hg_intercepts.c</file>
=================================================
./valgrind-new/memcheck/tests/origin5-bz2.stderr.diff-glibc25-amd64
=================================================
--- origin5-bz2.stderr.exp-glibc25-amd64 2009-08-05 03:21:23.000000000 +1000
+++ origin5-bz2.stderr.out 2009-08-05 03:30:20.000000000 +1000
@@ -11,7 +11,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: handle_compress (origin5-bz2.c:4686)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
@@ -19,7 +19,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: handle_compress (origin5-bz2.c:4686)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
@@ -27,7 +27,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2820)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -38,7 +38,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2823)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -49,7 +49,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2854)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -60,7 +60,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2858)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -71,7 +71,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2963)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -82,7 +82,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2964)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -93,7 +93,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: fallbackSort (origin5-bz2.c:2269)
by 0x........: BZ2_blockSort (origin5-bz2.c:3116)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -104,7 +104,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: fallbackSort (origin5-bz2.c:2275)
by 0x........: BZ2_blockSort (origin5-bz2.c:3116)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
=================================================
./valgrind-new/memcheck/tests/origin5-bz2.stderr.diff-glibc25-x86
=================================================
--- origin5-bz2.stderr.exp-glibc25-x86 2009-08-05 03:21:23.000000000 +1000
+++ origin5-bz2.stderr.out 2009-08-05 03:30:20.000000000 +1000
@@ -28,7 +28,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2820)
+ at 0x........: mainSort (origin5-bz2.c:2820)
+ 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)
@@ -38,7 +39,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2823)
+ at 0x........: mainSort (origin5-bz2.c:2823)
+ 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)
@@ -48,7 +50,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2855)
+ at 0x........: mainSort (origin5-bz2.c:2854)
+ 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)
@@ -58,7 +61,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2859)
+ at 0x........: mainSort (origin5-bz2.c:2858)
+ 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)
@@ -68,7 +72,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2963)
+ at 0x........: mainSort (origin5-bz2.c:2963)
+ 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)
@@ -78,7 +83,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2964)
+ at 0x........: mainSort (origin5-bz2.c:2964)
+ 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)
=================================================
./valgrind-new/memcheck/tests/origin5-bz2.stderr.diff-glibc27-ppc64
=================================================
--- origin5-bz2.stderr.exp-glibc27-ppc64 2009-08-05 03:21:23.000000000 +1000
+++ origin5-bz2.stderr.out 2009-08-05 03:30:20.000000000 +1000
@@ -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........: handle_compress (origin5-bz2.c:4686)
@@ -9,85 +9,91 @@
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
+Use of uninitialised value of size 4
at 0x........: handle_compress (origin5-bz2.c:4686)
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:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: handle_compress (origin5-bz2.c:4686)
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:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2820)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2820)
+ 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:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2823)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2823)
+ 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:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2854)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2854)
+ 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:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2858)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2858)
+ 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:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2963)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2963)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
<truncated beyond 100 lines>
=================================================
./valgrind-new/none/tests/empty-exe.stderr.diff
=================================================
--- empty-exe.stderr.exp 2009-08-05 03:22:45.000000000 +1000
+++ empty-exe.stderr.out 2009-08-05 03:31:43.000000000 +1000
@@ -1,2 +1,2 @@
-
-
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./empty-exe: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-new/none/tests/shell.stderr.diff
=================================================
--- shell.stderr.exp 2009-08-05 03:22:45.000000000 +1000
+++ shell.stderr.out 2009-08-05 03:32:04.000000000 +1000
@@ -1,8 +1,3 @@
-./shell: ./x86/: is a directory
-./shell: ./shell.vgtest: Permission denied
-execve(0x........(./shell_badinterp), 0x........, 0x........) failed, errno 2
-EXEC FAILED: I can't recover from execve() failing, so I'm dying.
-Add more stringent tests in PRE(sys_execve), or work out how to recover.
-./shell: ./shell_binaryfile: cannot execute binary file
-./shell: ./shell_nosuchfile: No such file or directory
-./shell: shell_nosuchfile: command not found
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./shell: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-new/none/tests/shell.stderr.diff-dash
=================================================
--- shell.stderr.exp-dash 2009-08-05 03:22:45.000000000 +1000
+++ shell.stderr.out 2009-08-05 03:32:04.000000000 +1000
@@ -1,8 +1,3 @@
-./shell: 10: ./x86/: Permission denied
-./shell: 13: ./shell.vgtest: Permission denied
-execve(0x........(./shell_badinterp), 0x........, 0x........) failed, errno 2
-EXEC FAILED: I can't recover from execve() failing, so I'm dying.
-Add more stringent tests in PRE(sys_execve), or work out how to recover.
-./shell_binaryfile: 4: Syntax error: ")" unexpected
-./shell: 22: ./shell_nosuchfile: not found
-./shell: 25: shell_nosuchfile: not found
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./shell: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-new/none/tests/shell.stdout.diff
=================================================
--- shell.stdout.exp 2009-08-05 03:22:45.000000000 +1000
+++ shell.stdout.out 2009-08-05 03:32:04.000000000 +1000
@@ -1,10 +0,0 @@
-Execute a directory
-Execute a non-executable file
-Execute a script with a bad interpreter name
-Execute a binary file
-Execute a non-existent file
-Execute a non-existent file (2)
-Execute a valid script with a #! line
-Execute a valid script without a #! line
-Execute a valid script with #! but no interpname
-Execute a zero-length file
=================================================
./valgrind-new/none/tests/shell_valid1.stderr.diff
=================================================
--- shell_valid1.stderr.exp 2009-08-05 03:22:45.000000000 +1000
+++ shell_valid1.stderr.out 2009-08-05 03:32:04.000000000 +1000
@@ -0,0 +1,3 @@
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./shell_valid1: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-new/none/tests/shell_valid2.stderr.diff
=================================================
--- shell_valid2.stderr.exp 2009-08-05 03:22:45.000000000 +1000
+++ shell_valid2.stderr.out 2009-08-05 03:32:04.000000000 +1000
@@ -0,0 +1,2 @@
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./shell_valid2: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-new/none/tests/shell_valid3.stderr.diff
=================================================
--- shell_valid3.stderr.exp 2009-08-05 03:22:45.000000000 +1000
+++ shell_valid3.stderr.out 2009-08-05 03:32:04.000000000 +1000
@@ -0,0 +1,2 @@
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./shell_valid3: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-new/none/tests/shell_zerolength.stderr.diff
=================================================
--- shell_zerolength.stderr.exp 2009-08-05 03:22:45.000000000 +1000
+++ shell_zerolength.stderr.out 2009-08-05 03:32:04.000000000 +1000
@@ -0,0 +1,2 @@
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./shell_zerolength: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-new/none/tests/shell_zerolength.stderr.diff-dash
=================================================
--- shell_zerolength.stderr.exp-dash 2009-08-05 03:22:45.000000000 +1000
+++ shell_zerolength.stderr.out 2009-08-05 03:32:04.000000000 +1000
@@ -1 +1,2 @@
-Bus error
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./shell_zerolength: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-old/exp-ptrcheck/tests/supp.stderr.diff
=================================================
--- supp.stderr.exp 2009-08-05 03:00:53.000000000 +1000
+++ supp.stderr.out 2009-08-05 03:19:13.000000000 +1000
@@ -1,7 +1,7 @@
Syscall param write(buf) is non-contiguous
- at 0x........: write (in /...libc...)
- by 0x........: main (supp.c:16)
+ at 0x........: ??? (in /lib32/ld-2.9.so)
+ by 0x........: (below main)
First byte (0x........) is 3 bytes inside a 6-byte block alloc'd
at 0x........: malloc (vg_replace_malloc.c:...)
by 0x........: main (supp.c:12)
=================================================
./valgrind-old/helgrind/tests/tc06_two_races_xml.stderr.diff
=================================================
--- tc06_two_races_xml.stderr.exp 2009-08-05 03:00:44.000000000 +1000
+++ tc06_two_races_xml.stderr.out 2009-08-05 03:16:46.000000000 +1000
@@ -43,16 +43,6 @@
<frame>
<ip>0x........</ip>
<obj>...</obj>
- <fn>do_clone</fn>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>pthread_create@@GLIBC_2.2.5</fn>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
<fn>pthread_create_WRK</fn>
<dir>...</dir>
<file>hg_intercepts.c</file>
=================================================
./valgrind-old/memcheck/tests/origin5-bz2.stderr.diff-glibc25-amd64
=================================================
--- origin5-bz2.stderr.exp-glibc25-amd64 2009-08-05 03:02:30.000000000 +1000
+++ origin5-bz2.stderr.out 2009-08-05 03:14:20.000000000 +1000
@@ -11,7 +11,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: handle_compress (origin5-bz2.c:4686)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
@@ -19,7 +19,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: handle_compress (origin5-bz2.c:4686)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
@@ -27,7 +27,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2820)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -38,7 +38,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2823)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -49,7 +49,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2854)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -60,7 +60,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2858)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -71,7 +71,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2963)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -82,7 +82,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2964)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -93,7 +93,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: fallbackSort (origin5-bz2.c:2269)
by 0x........: BZ2_blockSort (origin5-bz2.c:3116)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -104,7 +104,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: fallbackSort (origin5-bz2.c:2275)
by 0x........: BZ2_blockSort (origin5-bz2.c:3116)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
=================================================
./valgrind-old/memcheck/tests/origin5-bz2.stderr.diff-glibc25-x86
=================================================
--- origin5-bz2.stderr.exp-glibc25-x86 2009-08-05 03:02:30.000000000 +1000
+++ origin5-bz2.stderr.out 2009-08-05 03:14:20.000000000 +1000
@@ -28,7 +28,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2820)
+ at 0x........: mainSort (origin5-bz2.c:2820)
+ 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)
@@ -38,7 +39,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2823)
+ at 0x........: mainSort (origin5-bz2.c:2823)
+ 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)
@@ -48,7 +50,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2855)
+ at 0x........: mainSort (origin5-bz2.c:2854)
+ 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)
@@ -58,7 +61,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2859)
+ at 0x........: mainSort (origin5-bz2.c:2858)
+ 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)
@@ -68,7 +72,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2963)
+ at 0x........: mainSort (origin5-bz2.c:2963)
+ 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)
@@ -78,7 +83,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2964)
+ at 0x........: mainSort (origin5-bz2.c:2964)
+ 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)
=================================================
./valgrind-old/memcheck/tests/origin5-bz2.stderr.diff-glibc27-ppc64
=================================================
--- origin5-bz2.stderr.exp-glibc27-ppc64 2009-08-05 03:02:30.000000000 +1000
+++ origin5-bz2.stderr.out 2009-08-05 03:14:20.000000000 +1000
@@ -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........: handle_compress (origin5-bz2.c:4686)
@@ -9,85 +9,91 @@
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
+Use of uninitialised value of size 4
at 0x........: handle_compress (origin5-bz2.c:4686)
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:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: handle_compress (origin5-bz2.c:4686)
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:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2820)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2820)
+ 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:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2823)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2823)
+ 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:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2854)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2854)
+ 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:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2858)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2858)
+ 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:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2963)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2963)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
<truncated beyond 100 lines>
=================================================
./valgrind-old/none/tests/empty-exe.stderr.diff
=================================================
--- empty-exe.stderr.exp 2009-08-05 03:05:05.000000000 +1000
+++ empty-exe.stderr.out 2009-08-05 03:15:40.000000000 +1000
@@ -1,2 +1,2 @@
-
-
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./empty-exe: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-old/none/tests/shell.stderr.diff
=================================================
--- shell.stderr.exp 2009-08-05 03:05:05.000000000 +1000
+++ shell.stderr.out 2009-08-05 03:16:01.000000000 +1000
@@ -1,8 +1,3 @@
-./shell: ./x86/: is a directory
-./shell: ./shell.vgtest: Permission denied
-execve(0x........(./shell_badinterp), 0x........, 0x........) failed, errno 2
-EXEC FAILED: I can't recover from execve() failing, so I'm dying.
-Add more stringent tests in PRE(sys_execve), or work out how to recover.
-./shell: ./shell_binaryfile: cannot execute binary file
-./shell: ./shell_nosuchfile: No such file or directory
-./shell: shell_nosuchfile: command not found
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./shell: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-old/none/tests/shell.stderr.diff-dash
=================================================
--- shell.stderr.exp-dash 2009-08-05 03:05:05.000000000 +1000
+++ shell.stderr.out 2009-08-05 03:16:01.000000000 +1000
@@ -1,8 +1,3 @@
-./shell: 10: ./x86/: Permission denied
-./shell: 13: ./shell.vgtest: Permission denied
-execve(0x........(./shell_badinterp), 0x........, 0x........) failed, errno 2
-EXEC FAILED: I can't recover from execve() failing, so I'm dying.
-Add more stringent tests in PRE(sys_execve), or work out how to recover.
-./shell_binaryfile: 4: Syntax error: ")" unexpected
-./shell: 22: ./shell_nosuchfile: not found
-./shell: 25: shell_nosuchfile: not found
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./shell: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-old/none/tests/shell.stdout.diff
=================================================
--- shell.stdout.exp 2009-08-05 03:05:05.000000000 +1000
+++ shell.stdout.out 2009-08-05 03:16:01.000000000 +1000
@@ -1,10 +0,0 @@
-Execute a directory
-Execute a non-executable file
-Execute a script with a bad interpreter name
-Execute a binary file
-Execute a non-existent file
-Execute a non-existent file (2)
-Execute a valid script with a #! line
-Execute a valid script without a #! line
-Execute a valid script with #! but no interpname
-Execute a zero-length file
=================================================
./valgrind-old/none/tests/shell_valid1.stderr.diff
=================================================
--- shell_valid1.stderr.exp 2009-08-05 03:05:05.000000000 +1000
+++ shell_valid1.stderr.out 2009-08-05 03:16:01.000000000 +1000
@@ -0,0 +1,3 @@
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./shell_valid1: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-old/none/tests/shell_valid2.stderr.diff
=================================================
--- shell_valid2.stderr.exp 2009-08-05 03:05:05.000000000 +1000
+++ shell_valid2.stderr.out 2009-08-05 03:16:01.000000000 +1000
@@ -0,0 +1,2 @@
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./shell_valid2: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-old/none/tests/shell_valid3.stderr.diff
=================================================
--- shell_valid3.stderr.exp 2009-08-05 03:05:05.000000000 +1000
+++ shell_valid3.stderr.out 2009-08-05 03:16:01.000000000 +1000
@@ -0,0 +1,2 @@
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./shell_valid3: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-old/none/tests/shell_zerolength.stderr.diff
=================================================
--- shell_zerolength.stderr.exp 2009-08-05 03:05:05.000000000 +1000
+++ shell_zerolength.stderr.out 2009-08-05 03:16:01.000000000 +1000
@@ -0,0 +1,2 @@
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./shell_zerolength: bad interpreter (/bin/sh): VG_(strerror): unknown error
=================================================
./valgrind-old/none/tests/shell_zerolength.stderr.diff-dash
=================================================
--- shell_zerolength.stderr.exp-dash 2009-08-05 03:05:05.000000000 +1000
+++ shell_zerolength.stderr.out 2009-08-05 03:16:01.000000000 +1000
@@ -1 +1,2 @@
-Bus error
+valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit)
+valgrind: ./shell_zerolength: bad interpreter (/bin/sh): VG_(strerror): unknown error
|
|
From: Rich C. <Ric...@me...> - 2009-08-04 16:33:51
|
Nightly build on macbook ( Darwin 9.7.0 i386 )
Started at 2009-08-03 23:21:56 CDT
Ended at 2009-08-03 23:47:33 CDT
Results differ from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... failed
Regression test results follow
== 378 tests, 6 stderr failures, 1 stdout failure, 0 post failures ==
memcheck/tests/origin5-bz2 (stderr)
memcheck/tests/varinfo3 (stderr)
memcheck/tests/varinfo5 (stderr)
memcheck/tests/vcpu_fnfns (stdout)
none/tests/async-sigs (stderr)
none/tests/faultstatus (stderr)
none/tests/pth_blockedsig (stderr)
=================================================
== Results from 24 hours ago ==
=================================================
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... failed
Regression test results follow
== 379 tests, 6 stderr failures, 2 stdout failures, 0 post failures ==
memcheck/tests/origin5-bz2 (stderr)
memcheck/tests/varinfo3 (stderr)
memcheck/tests/varinfo5 (stderr)
memcheck/tests/vcpu_fnfns (stdout)
none/tests/async-sigs (stderr)
none/tests/faultstatus (stderr)
none/tests/pth_blockedsig (stderr)
none/tests/res_search (stdout)
=================================================
== Difference between 24 hours ago and now ==
=================================================
*** old.short 2009-08-03 23:35:11.000000000 -0500
--- new.short 2009-08-03 23:47:33.000000000 -0500
***************
*** 8,10 ****
! == 379 tests, 6 stderr failures, 2 stdout failures, 0 post failures ==
memcheck/tests/origin5-bz2 (stderr)
--- 8,10 ----
! == 378 tests, 6 stderr failures, 1 stdout failure, 0 post failures ==
memcheck/tests/origin5-bz2 (stderr)
***************
*** 16,18 ****
none/tests/pth_blockedsig (stderr)
- none/tests/res_search (stdout)
--- 16,17 ----
=================================================
./valgrind-new/memcheck/tests/origin5-bz2.stderr.diff-glibc25-amd64
=================================================
--- origin5-bz2.stderr.exp-glibc25-amd64 2009-08-03 23:35:23.000000000 -0500
+++ origin5-bz2.stderr.out 2009-08-03 23:41:34.000000000 -0500
@@ -11,7 +11,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: handle_compress (origin5-bz2.c:4686)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
@@ -19,7 +19,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: handle_compress (origin5-bz2.c:4686)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
@@ -27,7 +27,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2820)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -38,7 +38,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2823)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -49,8 +49,8 @@
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:2854)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2855)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
by 0x........: handle_compress (origin5-bz2.c:4753)
@@ -60,8 +60,8 @@
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:2858)
+Use of uninitialised value of size 4
+ 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)
@@ -71,7 +71,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2963)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -82,7 +82,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2964)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -93,7 +93,18 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2964)
+ 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 4
at 0x........: fallbackSort (origin5-bz2.c:2269)
by 0x........: BZ2_blockSort (origin5-bz2.c:3116)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -104,7 +115,7 @@
Uninitialised value was created by a client request
<truncated beyond 100 lines>
=================================================
./valgrind-new/memcheck/tests/origin5-bz2.stderr.diff-glibc25-x86
=================================================
--- origin5-bz2.stderr.exp-glibc25-x86 2009-08-03 23:35:24.000000000 -0500
+++ origin5-bz2.stderr.out 2009-08-03 23:41:34.000000000 -0500
@@ -28,7 +28,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2820)
+ at 0x........: mainSort (origin5-bz2.c:2820)
+ 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)
@@ -38,7 +39,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2823)
+ at 0x........: mainSort (origin5-bz2.c:2823)
+ 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)
@@ -48,7 +50,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2855)
+ at 0x........: mainSort (origin5-bz2.c:2855)
+ 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)
@@ -58,7 +61,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2859)
+ 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)
@@ -68,7 +72,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2963)
+ at 0x........: mainSort (origin5-bz2.c:2963)
+ 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)
@@ -78,7 +83,19 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2964)
+ at 0x........: mainSort (origin5-bz2.c:2964)
+ 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 4
+ at 0x........: mainSort (origin5-bz2.c:2964)
+ 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)
=================================================
./valgrind-new/memcheck/tests/origin5-bz2.stderr.diff-glibc27-ppc64
=================================================
--- origin5-bz2.stderr.exp-glibc27-ppc64 2009-08-03 23:35:23.000000000 -0500
+++ origin5-bz2.stderr.out 2009-08-03 23:41:34.000000000 -0500
@@ -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........: handle_compress (origin5-bz2.c:4686)
@@ -9,85 +9,102 @@
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
+Use of uninitialised value of size 4
at 0x........: handle_compress (origin5-bz2.c:4686)
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:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: handle_compress (origin5-bz2.c:4686)
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:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2820)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2820)
+ 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:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2823)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2823)
+ 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:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2854)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2855)
+ 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:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2858)
+Use of uninitialised value of size 4
+ 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:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2963)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2963)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
<truncated beyond 100 lines>
=================================================
./valgrind-new/memcheck/tests/varinfo3.stderr.diff
=================================================
--- varinfo3.stderr.exp 2009-08-03 23:35:23.000000000 -0500
+++ varinfo3.stderr.out 2009-08-03 23:42:30.000000000 -0500
@@ -31,7 +31,7 @@
by 0x........: bar (varinfo3.c:42)
by 0x........: foo (varinfo3.c:58)
by 0x........: main (varinfo3.c:66)
- Address 0x........ is 5 bytes inside data symbol "static_local_def.XXXX"
+ Address 0x........ is in the Data segment of ./varinfo3
Uninitialised byte(s) found during client check request
at 0x........: croak (varinfo3.c:28)
@@ -46,7 +46,7 @@
by 0x........: bar (varinfo3.c:44)
by 0x........: foo (varinfo3.c:58)
by 0x........: main (varinfo3.c:66)
- Address 0x........ is 7 bytes inside data symbol "static_local_undef.XXXX"
+ Address 0x........ is in the Data segment of ./varinfo3
Uninitialised byte(s) found during client check request
at 0x........: croak (varinfo3.c:28)
=================================================
./valgrind-new/memcheck/tests/varinfo5.stderr.diff
=================================================
--- varinfo5.stderr.exp 2009-08-03 23:35:24.000000000 -0500
+++ varinfo5.stderr.out 2009-08-03 23:42:32.000000000 -0500
@@ -119,7 +119,7 @@
by 0x........: varinfo3_main (varinfo5so.c:118)
by 0x........: varinfo5_main (varinfo5so.c:156)
by 0x........: main (varinfo5.c:5)
- Address 0x........ is 5 bytes inside data symbol "static_local_def.XXXX"
+ Address 0x........ is in the Data segment of /Users/minime/src/vg/nightly/valgrind-new/memcheck/tests/varinfo5so.so
Uninitialised byte(s) found during client check request
at 0x........: croak (varinfo5so.c:29)
@@ -138,7 +138,7 @@
by 0x........: varinfo3_main (varinfo5so.c:118)
by 0x........: varinfo5_main (varinfo5so.c:156)
by 0x........: main (varinfo5.c:5)
- Address 0x........ is 7 bytes inside data symbol "static_local_undef.XXXX"
+ Address 0x........ is in the Data segment of /Users/minime/src/vg/nightly/valgrind-new/memcheck/tests/varinfo5so.so
Uninitialised byte(s) found during client check request
at 0x........: croak (varinfo5so.c:29)
=================================================
./valgrind-new/memcheck/tests/vcpu_fnfns.stdout.diff
=================================================
--- vcpu_fnfns.stdout.exp 2009-08-03 23:35:23.000000000 -0500
+++ vcpu_fnfns.stdout.out 2009-08-03 23:42:40.000000000 -0500
@@ -91,16 +91,16 @@
ceilD(-1.2000000008000e+00) = -1.0000000000000e+00
ceilD(-1.1000000009000e+00) = -1.0000000000000e+00
ceilD(-1.0000000010000e+00) = -1.0000000000000e+00
- ceilD(-9.0000000110000e-01) = -0.0000000000000e+00
- ceilD(-8.0000000120000e-01) = -0.0000000000000e+00
- ceilD(-7.0000000130000e-01) = -0.0000000000000e+00
- ceilD(-6.0000000140000e-01) = -0.0000000000000e+00
- ceilD(-5.0000000150000e-01) = -0.0000000000000e+00
- ceilD(-4.0000000160000e-01) = -0.0000000000000e+00
- ceilD(-3.0000000170000e-01) = -0.0000000000000e+00
- ceilD(-2.0000000180000e-01) = -0.0000000000000e+00
- ceilD(-1.0000000190000e-01) = -0.0000000000000e+00
- ceilD(-1.9999992495467e-09) = -0.0000000000000e+00
+ ceilD(-9.0000000110000e-01) = +0.0000000000000e+00
+ ceilD(-8.0000000120000e-01) = +0.0000000000000e+00
+ ceilD(-7.0000000130000e-01) = +0.0000000000000e+00
+ ceilD(-6.0000000140000e-01) = +0.0000000000000e+00
+ ceilD(-5.0000000150000e-01) = +0.0000000000000e+00
+ ceilD(-4.0000000160000e-01) = +0.0000000000000e+00
+ ceilD(-3.0000000170000e-01) = +0.0000000000000e+00
+ ceilD(-2.0000000180000e-01) = +0.0000000000000e+00
+ ceilD(-1.0000000190000e-01) = +0.0000000000000e+00
+ ceilD(-1.9999992495467e-09) = +0.0000000000000e+00
ceilD(+9.9999997900001e-02) = +1.0000000000000e+00
ceilD(+1.9999999780000e-01) = +1.0000000000000e+00
ceilD(+2.9999999770000e-01) = +1.0000000000000e+00
@@ -132,16 +132,16 @@
ceilF( -1.2008e+00) = -1.0000e+00
ceilF( -1.1009e+00) = -1.0000e+00
ceilF( -1.0010e+00) = -1.0000e+00
- ceilF( -9.0110e-01) = -0.0000e+00
- ceilF( -8.0120e-01) = -0.0000e+00
- ceilF( -7.0130e-01) = -0.0000e+00
- ceilF( -6.0140e-01) = -0.0000e+00
- ceilF( -5.0150e-01) = -0.0000e+00
- ceilF( -4.0160e-01) = -0.0000e+00
- ceilF( -3.0170e-01) = -0.0000e+00
- ceilF( -2.0180e-01) = -0.0000e+00
- ceilF( -1.0190e-01) = -0.0000e+00
- ceilF( -1.9999e-03) = -0.0000e+00
+ ceilF( -9.0110e-01) = +0.0000e+00
+ ceilF( -8.0120e-01) = +0.0000e+00
+ ceilF( -7.0130e-01) = +0.0000e+00
+ ceilF( -6.0140e-01) = +0.0000e+00
+ ceilF( -5.0150e-01) = +0.0000e+00
+ ceilF( -4.0160e-01) = +0.0000e+00
+ ceilF( -3.0170e-01) = +0.0000e+00
+ ceilF( -2.0180e-01) = +0.0000e+00
+ ceilF( -1.0190e-01) = +0.0000e+00
+ ceilF( -1.9999e-03) = +0.0000e+00
ceilF( +9.7900e-02) = +1.0000e+00
ceilF( +1.9780e-01) = +1.0000e+00
ceilF( +2.9770e-01) = +1.0000e+00
@@ -305,7 +305,7 @@
cosF( -3.0170e-01) = +9.5483e-01
cosF( -2.0180e-01) = +9.7971e-01
cosF( -1.0190e-01) = +9.9481e-01
- cosF( -1.9999e-03) = +1.0000e-00
+ cosF( -1.9999e-03) = +1.0000e+00
cosF( +9.7900e-02) = +9.9521e-01
cosF( +1.9780e-01) = +9.8050e-01
cosF( +2.9770e-01) = +9.5601e-01
@@ -536,7 +536,7 @@
logD(+9.9999999900000e-02) = -2.3025850939940e+00
logD(+1.9999999980000e-01) = -1.6094379134341e+00
logD(+2.9999999970000e-01) = -1.2039728053259e+00
- logD(+3.9999999960000e-01) = -9.1629073287415e-01
+ logD(+3.9999999960000e-01) = -9.1629073287416e-01
logD(+4.9999999950000e-01) = -6.9314718155995e-01
logD(+5.9999999940000e-01) = -5.1082562476599e-01
logD(+6.9999999930000e-01) = -3.5667494493873e-01
@@ -617,7 +617,7 @@
log10F( +1.8981e+00) = +2.7832e-01
log10F( +1.9980e+00) = +3.0060e-01
asinD(-1.0000000000000e+00) = -1.5707963267949e+00
- asinD(-9.0000000010000e-01) = -1.1197695152281e+00
+ asinD(-9.0000000010000e-01) = -1.1197695152280e+00
asinD(-8.0000000020000e-01) = -9.2729521833495e-01
asinD(-7.0000000030000e-01) = -7.7539749703084e-01
asinD(-6.0000000040000e-01) = -6.4350110929328e-01
=================================================
./valgrind-new/memcheck/tests/vcpu_fnfns.stdout.diff-glibc28-amd64
=================================================
--- vcpu_fnfns.stdout.exp-glibc28-amd64 2009-08-03 23:35:23.000000000 -0500
+++ vcpu_fnfns.stdout.out 2009-08-03 23:42:40.000000000 -0500
@@ -91,16 +91,16 @@
ceilD(-1.2000000008000e+00) = -1.0000000000000e+00
ceilD(-1.1000000009000e+00) = -1.0000000000000e+00
ceilD(-1.0000000010000e+00) = -1.0000000000000e+00
- ceilD(-9.0000000110000e-01) = -0.0000000000000e+00
- ceilD(-8.0000000120000e-01) = -0.0000000000000e+00
- ceilD(-7.0000000130000e-01) = -0.0000000000000e+00
- ceilD(-6.0000000140000e-01) = -0.0000000000000e+00
- ceilD(-5.0000000150000e-01) = -0.0000000000000e+00
- ceilD(-4.0000000160000e-01) = -0.0000000000000e+00
- ceilD(-3.0000000170000e-01) = -0.0000000000000e+00
- ceilD(-2.0000000180000e-01) = -0.0000000000000e+00
- ceilD(-1.0000000190000e-01) = -0.0000000000000e+00
- ceilD(-1.9999992495467e-09) = -0.0000000000000e+00
+ ceilD(-9.0000000110000e-01) = +0.0000000000000e+00
+ ceilD(-8.0000000120000e-01) = +0.0000000000000e+00
+ ceilD(-7.0000000130000e-01) = +0.0000000000000e+00
+ ceilD(-6.0000000140000e-01) = +0.0000000000000e+00
+ ceilD(-5.0000000150000e-01) = +0.0000000000000e+00
+ ceilD(-4.0000000160000e-01) = +0.0000000000000e+00
+ ceilD(-3.0000000170000e-01) = +0.0000000000000e+00
+ ceilD(-2.0000000180000e-01) = +0.0000000000000e+00
+ ceilD(-1.0000000190000e-01) = +0.0000000000000e+00
+ ceilD(-1.9999992495467e-09) = +0.0000000000000e+00
ceilD(+9.9999997900001e-02) = +1.0000000000000e+00
ceilD(+1.9999999780000e-01) = +1.0000000000000e+00
ceilD(+2.9999999770000e-01) = +1.0000000000000e+00
@@ -132,16 +132,16 @@
ceilF( -1.2008e+00) = -1.0000e+00
ceilF( -1.1009e+00) = -1.0000e+00
ceilF( -1.0010e+00) = -1.0000e+00
- ceilF( -9.0110e-01) = -0.0000e+00
- ceilF( -8.0120e-01) = -0.0000e+00
- ceilF( -7.0130e-01) = -0.0000e+00
- ceilF( -6.0140e-01) = -0.0000e+00
- ceilF( -5.0150e-01) = -0.0000e+00
- ceilF( -4.0160e-01) = -0.0000e+00
- ceilF( -3.0170e-01) = -0.0000e+00
- ceilF( -2.0180e-01) = -0.0000e+00
- ceilF( -1.0190e-01) = -0.0000e+00
- ceilF( -1.9999e-03) = -0.0000e+00
+ ceilF( -9.0110e-01) = +0.0000e+00
+ ceilF( -8.0120e-01) = +0.0000e+00
+ ceilF( -7.0130e-01) = +0.0000e+00
+ ceilF( -6.0140e-01) = +0.0000e+00
+ ceilF( -5.0150e-01) = +0.0000e+00
+ ceilF( -4.0160e-01) = +0.0000e+00
+ ceilF( -3.0170e-01) = +0.0000e+00
+ ceilF( -2.0180e-01) = +0.0000e+00
+ ceilF( -1.0190e-01) = +0.0000e+00
+ ceilF( -1.9999e-03) = +0.0000e+00
ceilF( +9.7900e-02) = +1.0000e+00
ceilF( +1.9780e-01) = +1.0000e+00
ceilF( +2.9770e-01) = +1.0000e+00
@@ -536,7 +536,7 @@
logD(+9.9999999900000e-02) = -2.3025850939940e+00
logD(+1.9999999980000e-01) = -1.6094379134341e+00
logD(+2.9999999970000e-01) = -1.2039728053259e+00
- logD(+3.9999999960000e-01) = -9.1629073287415e-01
+ logD(+3.9999999960000e-01) = -9.1629073287416e-01
logD(+4.9999999950000e-01) = -6.9314718155995e-01
logD(+5.9999999940000e-01) = -5.1082562476599e-01
logD(+6.9999999930000e-01) = -3.5667494493873e-01
@@ -617,7 +617,7 @@
log10F( +1.8981e+00) = +2.7832e-01
log10F( +1.9980e+00) = +3.0060e-01
asinD(-1.0000000000000e+00) = -1.5707963267949e+00
- asinD(-9.0000000010000e-01) = -1.1197695152281e+00
+ asinD(-9.0000000010000e-01) = -1.1197695152280e+00
asinD(-8.0000000020000e-01) = -9.2729521833495e-01
asinD(-7.0000000030000e-01) = -7.7539749703084e-01
asinD(-6.0000000040000e-01) = -6.4350110929328e-01
=================================================
./valgrind-new/none/tests/async-sigs.stderr.diff
=================================================
--- async-sigs.stderr.exp 2009-08-03 23:35:32.000000000 -0500
+++ async-sigs.stderr.out 2009-08-03 23:44:00.000000000 -0500
@@ -1,8 +1,30 @@
-testing: blocking=0 caught=11 fatal=7... PASSED
+testing: blocking=0 caught=11 fatal=10...
+Process terminating with default action of signal 10 (SIGBUS)
+ Non-existent physical address at address 0x........
+ at 0x........: test (async-sigs.c:94)
+ by 0x........: main (async-sigs.c:129)
+PASSED
testing: blocking=0 caught=11 fatal=1... PASSED
-testing: blocking=0 caught=10 fatal=7... PASSED
-testing: blocking=0 caught=10 fatal=1... PASSED
-testing: blocking=1 caught=11 fatal=7... PASSED
+testing: blocking=0 caught=30 fatal=10...
+Process terminating with default action of signal 10 (SIGBUS)
+ Non-existent physical address at address 0x........
+ at 0x........: test (async-sigs.c:94)
+ by 0x........: main (async-sigs.c:131)
+PASSED
+testing: blocking=0 caught=30 fatal=1... PASSED
+testing: blocking=1 caught=11 fatal=10...
+Process terminating with default action of signal 10 (SIGBUS)
+ Non-existent physical address at address 0x........
+ at 0x........: __sigsuspend (in /...libc...)
+ by 0x........: test (async-sigs.c:95)
+ by 0x........: main (async-sigs.c:133)
+PASSED
testing: blocking=1 caught=11 fatal=1... PASSED
-testing: blocking=1 caught=10 fatal=7... PASSED
-testing: blocking=1 caught=10 fatal=1... PASSED
+testing: blocking=1 caught=30 fatal=10...
+Process terminating with default action of signal 10 (SIGBUS)
+ Non-existent physical address at address 0x........
+ at 0x........: __sigsuspend (in /...libc...)
+ by 0x........: test (async-sigs.c:95)
+ by 0x........: main (async-sigs.c:135)
+PASSED
+testing: blocking=1 caught=30 fatal=1... PASSED
=================================================
./valgrind-new/none/tests/faultstatus.stderr.diff
=================================================
--- faultstatus.stderr.exp 2009-08-03 23:35:33.000000000 -0500
+++ faultstatus.stderr.out 2009-08-03 23:44:05.000000000 -0500
@@ -1,6 +1,6 @@
-Test 1: PASS
-Test 2: PASS
-Test 3: PASS
-Test 4: PASS
+Test 1: FAIL: expected signal 11, not 10
+Test 2: FAIL: expected signal 11, not 10
+Test 3: FAIL: no fault, or handler returned
+Test 4: FAIL: expected si_code==7, not 0
=================================================
./valgrind-new/none/tests/pth_blockedsig.stderr.diff
=================================================
--- pth_blockedsig.stderr.exp 2009-08-03 23:35:32.000000000 -0500
+++ pth_blockedsig.stderr.out 2009-08-03 23:45:07.000000000 -0500
@@ -1,2 +1,4 @@
+UNKNOWN __pthread_sigmask is unsupported. This warning will not be repeated.
+SHOULD NOT BE HERE (SIGUSR1)!!!!
=================================================
./valgrind-old/memcheck/tests/origin5-bz2.stderr.diff-glibc25-amd64
=================================================
--- origin5-bz2.stderr.exp-glibc25-amd64 2009-08-03 23:22:13.000000000 -0500
+++ origin5-bz2.stderr.out 2009-08-03 23:28:43.000000000 -0500
@@ -11,7 +11,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: handle_compress (origin5-bz2.c:4686)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
@@ -19,7 +19,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: handle_compress (origin5-bz2.c:4686)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
@@ -27,7 +27,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2820)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -38,7 +38,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2823)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -49,8 +49,8 @@
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:2854)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2855)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
by 0x........: handle_compress (origin5-bz2.c:4753)
@@ -60,8 +60,8 @@
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:2858)
+Use of uninitialised value of size 4
+ 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)
@@ -71,7 +71,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2963)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -82,7 +82,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: mainSort (origin5-bz2.c:2964)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -93,7 +93,18 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2964)
+ 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 4
at 0x........: fallbackSort (origin5-bz2.c:2269)
by 0x........: BZ2_blockSort (origin5-bz2.c:3116)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -104,7 +115,7 @@
Uninitialised value was created by a client request
<truncated beyond 100 lines>
=================================================
./valgrind-old/memcheck/tests/origin5-bz2.stderr.diff-glibc25-x86
=================================================
--- origin5-bz2.stderr.exp-glibc25-x86 2009-08-03 23:22:14.000000000 -0500
+++ origin5-bz2.stderr.out 2009-08-03 23:28:43.000000000 -0500
@@ -28,7 +28,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2820)
+ at 0x........: mainSort (origin5-bz2.c:2820)
+ 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)
@@ -38,7 +39,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2823)
+ at 0x........: mainSort (origin5-bz2.c:2823)
+ 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)
@@ -48,7 +50,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2855)
+ at 0x........: mainSort (origin5-bz2.c:2855)
+ 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)
@@ -58,7 +61,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2859)
+ 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)
@@ -68,7 +72,8 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2963)
+ at 0x........: mainSort (origin5-bz2.c:2963)
+ 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)
@@ -78,7 +83,19 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2964)
+ at 0x........: mainSort (origin5-bz2.c:2964)
+ 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 4
+ at 0x........: mainSort (origin5-bz2.c:2964)
+ 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)
=================================================
./valgrind-old/memcheck/tests/origin5-bz2.stderr.diff-glibc27-ppc64
=================================================
--- origin5-bz2.stderr.exp-glibc27-ppc64 2009-08-03 23:22:13.000000000 -0500
+++ origin5-bz2.stderr.out 2009-08-03 23:28:43.000000000 -0500
@@ -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........: handle_compress (origin5-bz2.c:4686)
@@ -9,85 +9,102 @@
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
+Use of uninitialised value of size 4
at 0x........: handle_compress (origin5-bz2.c:4686)
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:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
+Use of uninitialised value of size 4
at 0x........: handle_compress (origin5-bz2.c:4686)
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:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2820)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2820)
+ 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:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2823)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2823)
+ 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:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2854)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2855)
+ 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:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2858)
+Use of uninitialised value of size 4
+ 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:6481)
+ at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 8
- at 0x........: BZ2_blockSort (origin5-bz2.c:2963)
+Use of uninitialised value of size 4
+ at 0x........: mainSort (origin5-bz2.c:2963)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
<truncated beyond 100 lines>
=================================================
./valgrind-old/memcheck/tests/varinfo3.stderr.diff
=================================================
--- varinfo3.stderr.exp 2009-08-03 23:22:13.000000000 -0500
+++ varinfo3.stderr.out 2009-08-03 23:29:39.000000000 -0500
@@ -31,7 +31,7 @@
by 0x........: bar (varinfo3.c:42)
by 0x........: foo (varinfo3.c:58)
by 0x........: main (varinfo3.c:66)
- Address 0x........ is 5 bytes inside data symbol "static_local_def.XXXX"
+ Address 0x........ is in the Data segment of ./varinfo3
Uninitialised byte(s) found during client check request
at 0x........: croak (varinfo3.c:28)
@@ -46,7 +46,7 @@
by 0x........: bar (varinfo3.c:44)
by 0x........: foo (varinfo3.c:58)
by 0x........: main (varinfo3.c:66)
- Address 0x........ is 7 bytes inside data symbol "static_local_undef.XXXX"
+ Address 0x........ is in the Data segment of ./varinfo3
Uninitialised byte(s) found during client check request
at 0x........: croak (varinfo3.c:28)
=================================================
./valgrind-old/memcheck/tests/varinfo5.stderr.diff
=================================================
--- varinfo5.stderr.exp 2009-08-03 23:22:13.000000000 -0500
+++ varinfo5.stderr.out 2009-08-03 23:29:40.000000000 -0500
@@ -119,7 +119,7 @@
by 0x........: varinfo3_main (varinfo5so.c:118)
by 0x........: varinfo5_main (varinfo5so.c:156)
by 0x........: main (varinfo5.c:5)
- Address 0x........ is 5 bytes inside data symbol "static_local_def.XXXX"
+ Address 0x........ is in the Data segment of /Users/minime/src/vg/nightly/valgrind-old/memcheck/tests/varinfo5so.so
Uninitialised byte(s) found during client check request
at 0x........: croak (varinfo5so.c:29)
@@ -138,7 +138,7 @@
by 0x........: varinfo3_main (varinfo5so.c:118)
by 0x........: varinfo5_main (varinfo5so.c:156)
by 0x........: main (varinfo5.c:5)
- Address 0x........ is 7 bytes inside data symbol "static_local_undef.XXXX"
+ Address 0x........ is in the Data segment of /Users/minime/src/vg/nightly/valgrind-old/memcheck/tests/varinfo5so.so
Uninitialised byte(s) found during client check request
at 0x........: croak (varinfo5so.c:29)
=================================================
./valgrind-old/memcheck/tests/vcpu_fnfns.stdout.diff
=================================================
--- vcpu_fnfns.stdout.exp 2009-08-03 23:22:13.000000000 -0500
+++ vcpu_fnfns.stdout.out 2009-08-03 23:29:48.000000000 -0500
@@ -91,16 +91,16 @@
ceilD(-1.2000000008000e+00) = -1.0000000000000e+00
ceilD(-1.1000000009000e+00) = -1.0000000000000e+00
ceilD(-1.0000000010000e+00) = -1.0000000000000e+00
- ceilD(-9.0000000110000e-01) = -0.0000000000000e+00
- ceilD(-8.0000000120000e-01) = -0.0000000000000e+00
- ceilD(-7.0000000130000e-01) = -0.0000000000000e+00
- ceilD(-6.0000000140000e-01) = -0.0000000000000e+00
- ceilD(-5.0000000150000e-01) = -0.0000000000000e+00
- ceilD(-4.0000000160000e-01) = -0.0000000000000e+00
- ceilD(-3.0000000170000e-01) = -0.0000000000000e+00
- ceilD(-2.0000000180000e-01) = -0.0000000000000e+00
- ceilD(-1.0000000190000e-01) = -0.0000000000000e+00
- ceilD(-1.9999992495467e-09) = -0.0000000000000e+00
+ ceilD(-9.0000000110000e-01) = +0.0000000000000e+00
+ ceilD(-8.0000000120000e-01) = +0.0000000000000e+00
+ ceilD(-7.0000000130000e-01) = +0.0000000000000e+00
+ ceilD(-6.0000000140000e-01) = +0.0000000000000e+00
+ ceilD(-5.0000000150000e-01) = +0.0000000000000e+00
+ ceilD(-4.0000000160000e-01) = +0.0000000000000e+00
+ ceilD(-3.0000000170000e-01) = +0.0000000000000e+00
+ ceilD(-2.0000000180000e-01) = +0.0000000000000e+00
+ ceilD(-1.0000000190000e-01) = +0.0000000000000e+00
+ ceilD(-1.9999992495467e-09) = +0.0000000000000e+00
ceilD(+9.9999997900001e-02) = +1.0000000000000e+00
ceilD(+1.9999999780000e-01) = +1.0000000000000e+00
ceilD(+2.9999999770000e-01) = +1.0000000000000e+00
@@ -132,16 +132,16 @@
ceilF( -1.2008e+00) = -1.0000e+00
ceilF( -1.1009e+00) = -1.0000e+00
ceilF( -1.0010e+00) = -1.0000e+00
- ceilF( -9.0110e-01) = -0.0000e+00
- ceilF( -8.0120e-01) = -0.0000e+00
- ceilF( -7.0130e-01) = -0.0000e+00
- ceilF( -6.0140e-01) = -0.0000e+00
- ceilF( -5.0150e-01) = -0.0000e+00
- ceilF( -4.0160e-01) = -0.0000e+00
- ceilF( -3.0170e-01) = -0.0000e+00
- ceilF( -2.0180e-01) = -0.0000e+00
- ceilF( -1.0190e-01) = -0.0000e+00
- ceilF( -1.9999e-03) = -0.0000e+00
+ ceilF( -9.0110e-01) = +0.0000e+00
+ ceilF( -8.0120e-01) = +0.0000e+00
+ ceilF( -7.0130e-01) = +0.0000e+00
+ ceilF( -6.0140e-01) = +0.0000e+00
+ ceilF( -5.0150e-01) = +0.0000e+00
+ ceilF( -4.0160e-01) = +0.0000e+00
+ ceilF( -3.0170e-01) = +0.0000e+00
+ ceilF( -2.0180e-01) = +0.0000e+00
+ ceilF( -1.0190e-01) = +0.0000e+00
+ ceilF( -1.9999e-03) = +0.0000e+00
ceilF( +9.7900e-02) = +1.0000e+00
ceilF( +1.9780e-01) = +1.0000e+00
ceilF( +2.9770e-01) = +1.0000e+00
@@ -305,7 +305,7 @@
cosF( -3.0170e-01) = +9.5483e-01
cosF( -2.0180e-01) = +9.7971e-01
cosF( -1.0190e-01) = +9.9481e-01
- cosF( -1.9999e-03) = +1.0000e-00
+ cosF( -1.9999e-03) = +1.0000e+00
cosF( +9.7900e-02) = +9.9521e-01
cosF( +1.9780e-01) = +9.8050e-01
cosF( +2.9770e-01) = +9.5601e-01
@@ -536,7 +536,7 @@
logD(+9.9999999900000e-02) = -2.3025850939940e+00
logD(+1.9999999980000e-01) = -1.6094379134341e+00
logD(+2.9999999970000e-01) = -1.2039728053259e+00
- logD(+3.9999999960000e-01) = -9.1629073287415e-01
+ logD(+3.9999999960000e-01) = -9.1629073287416e-01
logD(+4.9999999950000e-01) = -6.9314718155995e-01
logD(+5.9999999940000e-01) = -5.1082562476599e-01
logD(+6.9999999930000e-01) = -3.5667494493873e-01
@@ -617,7 +617,7 @@
log10F( +1.8981e+00) = +2.7832e-01
log10F( +1.9980e+00) = +3.0060e-01
asinD(-1.0000000000000e+00) = -1.5707963267949e+00
- asinD(-9.0000000010000e-01) = -1.1197695152281e+00
+ asinD(-9.0000000010000e-01) = -1.1197695152280e+00
asinD(-8.0000000020000e-01) = -9.2729521833495e-01
asinD(-7.0000000030000e-01) = -7.7539749703084e-01
asinD(-6.0000000040000e-01) = -6.4350110929328e-01
=================================================
./valgrind-old/memcheck/tests/vcpu_fnfns.stdout.diff-glibc28-amd64
=================================================
--- vcpu_fnfns.stdout.exp-glibc28-amd64 2009-08-03 23:22:13.000000000 -0500
+++ vcpu_fnfns.stdout.out 2009-08-03 23:29:48.000000000 -0500
@@ -91,16 +91,16 @@
ceilD(-1.2000000008000e+00) = -1.0000000000000e+00
ceilD(-1.1000000009000e+00) = -1.0000000000000e+00
ceilD(-1.0000000010000e+00) = -1.0000000000000e+00
- ceilD(-9.0000000110000e-01) = -0.0000000000000e+00
- ceilD(-8.0000000120000e-01) = -0.0000000000000e+00
- ceilD(-7.0000000130000e-01) = -0.0000000000000e+00
- ceilD(-6.0000000140000e-01) = -0.0000000000000e+00
- ceilD(-5.0000000150000e-01) = -0.0000000000000e+00
- ceilD(-4.0000000160000e-01) = -0.0000000000000e+00
- ceilD(-3.0000000170000e-01) = -0.0000000000000e+00
- ceilD(-2.0000000180000e-01) = -0.0000000000000e+00
- ceilD(-1.0000000190000e-01) = -0.0000000000000e+00
- ceilD(-1.9999992495467e-09) = -0.0000000000000e+00
+ ceilD(-9.0000000110000e-01) = +0.0000000000000e+00
+ ceilD(-8.0000000120000e-01) = +0.0000000000000e+00
+ ceilD(-7.0000000130000e-01) = +0.0000000000000e+00
+ ceilD(-6.0000000140000e-01) = +0.0000000000000e+00
+ ceilD(-5.0000000150000e-01) = +0.0000000000000e+00
+ ceilD(-4.0000000160000e-01) = +0.0000000000000e+00
+ ceilD(-3.0000000170000e-01) = +0.0000000000000e+00
+ ceilD(-2.0000000180000e-01) = +0.0000000000000e+00
+ ceilD(-1.0000000190000e-01) = +0.0000000000000e+00
+ ceilD(-1.9999992495467e-09) = +0.0000000000000e+00
ceilD(+9.9999997900001e-02) = +1.0000000000000e+00
ceilD(+1.9999999780000e-01) = +1.0000000000000e+00
ceilD(+2.9999999770000e-01) = +1.0000000000000e+00
@@ -132,16 +132,16 @@
ceilF( -1.2008e+00) = -1.0000e+00
ceilF( -1.1009e+00) = -1.0000e+00
ceilF( -1.0010e+00) = -1.0000e+00
- ceilF( -9.0110e-01) = -0.0000e+00
- ceilF( -8.0120e-01) = -0.0000e+00
- ceilF( -7.0130e-01) = -0.0000e+00
- ceilF( -6.0140e-01) = -0.0000e+00
- ceilF( -5.0150e-01) = -0.0000e+00
- ceilF( -4.0160e-01) = -0.0000e+00
- ceilF( -3.0170e-01) = -0.0000e+00
- ceilF( -2.0180e-01) = -0.0000e+00
- ceilF( -1.0190e-01) = -0.0000e+00
- ceilF( -1.9999e-03) = -0.0000e+00
+ ceilF( -9.0110e-01) = +0.0000e+00
+ ceilF( -8.0120e-01) = +0.0000e+00
+ ceilF( -7.0130e-01) = +0.0000e+00
+ ceilF( -6.0140e-01) = +0.0000e+00
+ ceilF( -5.0150e-01) = +0.0000e+00
+ ceilF( -4.0160e-01) = +0.0000e+00
+ ceilF( -3.0170e-01) = +0.0000e+00
+ ceilF( -2.0180e-01) = +0.0000e+00
+ ceilF( -1.0190e-01) = +0.0000e+00
+ ceilF( -1.9999e-03) = +0.0000e+00
ceilF( +9.7900e-02) = +1.0000e+00
ceilF( +1.9780e-01) = +1.0000e+00
ceilF( +2.9770e-01) = +1.0000e+00
@@ -536,7 +536,7 @@
logD(+9.9999999900000e-02) = -2.3025850939940e+00
logD(+1.9999999980000e-01) = -1.6094379134341e+00
logD(+2.9999999970000e-01) = -1.2039728053259e+00
- logD(+3.9999999960000e-01) = -9.1629073287415e-01
+ logD(+3.9999999960000e-01) = -9.1629073287416e-01
logD(+4.9999999950000e-01) = -6.9314718155995e-01
logD(+5.9999999940000e-01) = -5.1082562476599e-01
logD(+6.9999999930000e-01) = -3.5667494493873e-01
@@ -617,7 +617,7 @@
log10F( +1.8981e+00) = +2.7832e-01
log10F( +1.9980e+00) = +3.0060e-01
asinD(-1.0000000000000e+00) = -1.5707963267949e+00
- asinD(-9.0000000010000e-01) = -1.1197695152281e+00
+ asinD(-9.0000000010000e-01) = -1.1197695152280e+00
asinD(-8.0000000020000e-01) = -9.2729521833495e-01
asinD(-7.0000000030000e-01) = -7.7539749703084e-01
asinD(-6.0000000040000e-01) = -6.4350110929328e-01
=================================================
./valgrind-old/none/tests/async-sigs.stderr.diff
=================================================
--- async-sigs.stderr.exp 2009-08-03 23:22:22.000000000 -0500
+++ async-sigs.stderr.out 2009-08-03 23:31:08.000000000 -0500
@@ -1,8 +1,30 @@
-testing: blocking=0 caught=11 fatal=7... PASSED
+testing: blocking=0 caught=11 fatal=10...
+Process terminating with default action of signal 10 (SIGBUS)
+ Non-existent physical address at address 0x........
+ at 0x........: test (async-sigs.c:94)
+ by 0x........: main (async-sigs.c:129)
+PASSED
testing: blocking=0 caught=11 fatal=1... PASSED
-testing: blocking=0 caught=10 fatal=7... PASSED
-testing: blocking=0 caught=10 fatal=1... PASSED
-testing: blocking=1 caught=11 fatal=7... PASSED
+testing: blocking=0 caught=30 fatal=10...
+Process terminating with default action of signal 10 (SIGBUS)
+ Non-existent physical address at address 0x........
+ at 0x........: test (async-sigs.c:94)
+ by 0x........: main (async-sigs.c:131)
+PASSED
+testing: blocking=0 caught=30 fatal=1... PASSED
+testing: blocking=1 caught=11 fatal=10...
+Process terminating with default action of signal 10 (SIGBUS)
+ Non-existent physical address at address 0x........
+ at 0x........: __sigsuspend (in /...libc...)
+ by 0x........: test (async-sigs.c:95)
+ by 0x........: main (async-sigs.c:133)
+PASSED
testing: blocking=1 caught=11 fatal=1... PASSED
-testing: blocking=1 caught=10 fatal=7... PASSED
-testing: blocking=1 caught=10 fatal=1... PASSED
+testing: blocking=1 caught=30 fatal=10...
+Process terminating with default action of signal 10 (SIGBUS)
+ Non-existent physical address at address 0x........
+ at 0x........: __sigsuspend (in /...libc...)
+ by 0x........: test (async-sigs.c:95)
+ by 0x........: main (async-sigs.c:135)
+PASSED
+testing: blocking=1 caught=30 fatal=1... PASSED
=================================================
./valgrind-old/none/tests/faultstatus.stderr.diff
=================================================
--- faultstatus.stderr.exp 2009-08-03 23:22:23.000000000 -0500
+++ faultstatus.stderr.out 2009-08-03 23:31:14.000000000 -0500
@@ -1,6 +1,6 @@
-Test 1: PASS
-Test 2: PASS
-Test 3: PASS
-Test 4: PASS
+Test 1: FAIL: expected signal 11, not 10
+Test 2: FAIL: expected signal 11, not 10
+Test 3: FAIL: no fault, or handler returned
+Test 4: FAIL: expected si_code==7, not 0
=================================================
./valgrind-old/none/tests/pth_blockedsig.stderr.diff
=================================================
--- pth_blockedsig.stderr.exp 2009-08-03 23:22:22.000000000 -0500
+++ pth_blockedsig.stderr.out 2009-08-03 23:32:15.000000000 -0500
@@ -1,2 +1,4 @@
+UNKNOWN __pthread_sigmask is unsupported. This warning will not be repeated.
+SHOULD NOT BE HERE (SIGUSR1)!!!!
=================================================
./valgrind-old/none/tests/res_search.stdout.diff
=================================================
--- res_search.stdout.exp 2009-08-03 23:22:22.000000000 -0500
+++ res_search.stdout.out 2009-08-03 23:32:54.000000000 -0500
@@ -1 +1 @@
-Success!
+Error: res_search()
|
|
From: Nicholas N. <n.n...@gm...> - 2009-08-04 16:24:52
|
Nightly build on ocean ( Ubuntu 9.04, x86_64 )
Started at 2009-08-05 02:00:01 EST
Ended at 2009-08-05 02:24:33 EST
Results differ from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... failed
Regression test results follow
== 526 tests, 1 stderr failure, 0 stdout failures, 0 post failures ==
helgrind/tests/tc06_two_races_xml (stderr)
=================================================
== Results from 24 hours ago ==
=================================================
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... failed
Regression test results follow
== 527 tests, 1 stderr failure, 0 stdout failures, 0 post failures ==
helgrind/tests/tc06_two_races_xml (stderr)
=================================================
== Difference between 24 hours ago and now ==
=================================================
*** old.short Wed Aug 5 02:12:10 2009
--- new.short Wed Aug 5 02:24:33 2009
***************
*** 8,10 ****
! == 527 tests, 1 stderr failure, 0 stdout failures, 0 post failures ==
helgrind/tests/tc06_two_races_xml (stderr)
--- 8,10 ----
! == 526 tests, 1 stderr failure, 0 stdout failures, 0 post failures ==
helgrind/tests/tc06_two_races_xml (stderr)
=================================================
./valgrind-new/helgrind/tests/tc06_two_races_xml.stderr.diff
=================================================
--- tc06_two_races_xml.stderr.exp 2009-08-05 02:12:28.000000000 +1000
+++ tc06_two_races_xml.stderr.out 2009-08-05 02:22:17.000000000 +1000
@@ -44,11 +44,6 @@
<frame>
<ip>0x........</ip>
<obj>...</obj>
- <fn>do_clone</fn>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
<fn>pthread_create@@GLIBC_2.2.5</fn>
</frame>
<frame>
=================================================
./valgrind-old/helgrind/tests/tc06_two_races_xml.stderr.diff
=================================================
--- tc06_two_races_xml.stderr.exp 2009-08-05 02:00:27.000000000 +1000
+++ tc06_two_races_xml.stderr.out 2009-08-05 02:09:53.000000000 +1000
@@ -43,11 +43,6 @@
<frame>
<ip>0x........</ip>
<obj>...</obj>
- <fn>do_clone</fn>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
<fn>pthread_create@@GLIBC_2.2.5</fn>
</frame>
<frame>
|
|
From: Alexander P. <gl...@go...> - 2009-08-04 08:30:47
|
What linker do you use? This error can appear if you link Valgrind using gold. On Tue, Aug 4, 2009 at 12:50 AM, Ayan Chowdhury<ach...@vm...> wrote: > Hi, > > I was trying to get my application up with valgrind. I was using the > following valgrind options. > > "/root/valgrind341/bin/valgrind --trace-children=yes --track-fds=yes > --log-file=/var/log/vmware/aam/valgrind.out.%p --leak-check=yes > --show-reachable=yes --leak-resolution=high --num-callers=40 > > But getting the following error when getting the program running. > > > valgrind: mmap(0x38000000, 1503232) failed in UME with error 22 (Invalid > argument). > valgrind: this can be caused by executables with very large text, data or > bss segments. > > > Any idea how to work around the problem. Any help will be appreciated. > > Thanks, > Ayan > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > -- WBR, Alexander Potapenko Software Engineer Google Moscow |
|
From: Bart V. A. <bar...@gm...> - 2009-08-04 07:59:36
|
Nightly build on georgia-tech-cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) Started at 2009-08-04 02:15:16 EDT Ended at 2009-08-04 03:59:13 EDT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 437 tests, 44 stderr failures, 9 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cases-full (stderr) memcheck/tests/leak-cases-summary (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/wrap8 (stderr) none/tests/empty-exe (stderr) none/tests/linux/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-vmx (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/test_gx (stdout) none/tests/ppc64/jm-fp (stdout) none/tests/ppc64/jm-vmx (stdout) none/tests/ppc64/round (stdout) none/tests/shell (stdout) none/tests/shell (stderr) none/tests/shell_valid1 (stderr) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) none/tests/shell_zerolength (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/fp (stderr) exp-ptrcheck/tests/globalerr (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) exp-ptrcheck/tests/hp_bounds (stderr) exp-ptrcheck/tests/hp_dangle (stderr) exp-ptrcheck/tests/hsg (stderr) exp-ptrcheck/tests/justify (stderr) exp-ptrcheck/tests/partial_bad (stderr) exp-ptrcheck/tests/partial_good (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) exp-ptrcheck/tests/realloc (stderr) exp-ptrcheck/tests/stackerr (stderr) exp-ptrcheck/tests/strcpy (stderr) exp-ptrcheck/tests/supp (stderr) exp-ptrcheck/tests/tricky (stderr) exp-ptrcheck/tests/unaligned (stderr) exp-ptrcheck/tests/zero (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 438 tests, 44 stderr failures, 9 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cases-full (stderr) memcheck/tests/leak-cases-summary (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/wrap8 (stderr) none/tests/empty-exe (stderr) none/tests/linux/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-vmx (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/test_gx (stdout) none/tests/ppc64/jm-fp (stdout) none/tests/ppc64/jm-vmx (stdout) none/tests/ppc64/round (stdout) none/tests/shell (stdout) none/tests/shell (stderr) none/tests/shell_valid1 (stderr) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) none/tests/shell_zerolength (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/fp (stderr) exp-ptrcheck/tests/globalerr (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) exp-ptrcheck/tests/hp_bounds (stderr) exp-ptrcheck/tests/hp_dangle (stderr) exp-ptrcheck/tests/hsg (stderr) exp-ptrcheck/tests/justify (stderr) exp-ptrcheck/tests/partial_bad (stderr) exp-ptrcheck/tests/partial_good (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) exp-ptrcheck/tests/realloc (stderr) exp-ptrcheck/tests/stackerr (stderr) exp-ptrcheck/tests/strcpy (stderr) exp-ptrcheck/tests/supp (stderr) exp-ptrcheck/tests/tricky (stderr) exp-ptrcheck/tests/unaligned (stderr) exp-ptrcheck/tests/zero (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Tue Aug 4 03:08:05 2009 --- new.short Tue Aug 4 03:59:13 2009 *************** *** 8,10 **** ! == 438 tests, 44 stderr failures, 9 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) --- 8,10 ---- ! == 437 tests, 44 stderr failures, 9 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) |
|
From: <sv...@va...> - 2009-08-04 07:03:05
|
Author: njn Date: 2009-08-04 08:02:54 +0100 (Tue, 04 Aug 2009) New Revision: 10709 Log: Various minor tweaks to the distribution docs. Modified: trunk/AUTHORS trunk/README trunk/README_DEVELOPERS trunk/README_PACKAGERS Modified: trunk/AUTHORS =================================================================== --- trunk/AUTHORS 2009-08-04 06:48:09 UTC (rev 10708) +++ trunk/AUTHORS 2009-08-04 07:02:54 UTC (rev 10709) @@ -14,17 +14,18 @@ overhauled low-level syscall/signal and address space layout stuff, among many other things. -Josef Weidendorfer wrote Callgrind and the associated KCachegrind GUI. +Josef Weidendorfer wrote and maintains Callgrind and the associated +KCachegrind GUI. Paul Mackerras did a lot of the initial per-architecture factoring -that forms the basis of the 3.0 line and is also to be seen in 2.4.0. +that forms the basis of the 3.0 line and was also seen in 2.4.0. He also did UCode-based dynamic translation support for PowerPC, and created a set of ppc-linux derivatives of the 2.X release line. Greg Parker wrote the Mac OS X port. -Dirk Mueller contributed the malloc-free mismatch checking stuff -and other bits and pieces, and acted as our KDE liaison. +Dirk Mueller contributed the malloc/free mismatch checking +and other bits and pieces, and acts as our KDE liaison. Robert Walsh added file descriptor leakage checking, new library interception machinery, support for client allocation pools, and minor @@ -38,6 +39,8 @@ Donna Robinson created and maintains the very excellent http://www.valgrind.org. +Vince Weaver wrote and maintains BBV. + Frederic Gobry helped with autoconf and automake. Daniel Berlin modified readelf's dwarf2 source line reader, written by Nick Modified: trunk/README =================================================================== --- trunk/README 2009-08-04 06:48:09 UTC (rev 10708) +++ trunk/README 2009-08-04 07:02:54 UTC (rev 10709) @@ -69,8 +69,7 @@ To install from a tar.bz2 distribution: - 4. Run ./configure, with some options if you wish. The standard - options are documented in the INSTALL file. The only interesting + 4. Run ./configure, with some options if you wish. The only interesting one is the usual --prefix=/where/you/want/it/installed. 5. Run "make". Modified: trunk/README_DEVELOPERS =================================================================== --- trunk/README_DEVELOPERS 2009-08-04 06:48:09 UTC (rev 10708) +++ trunk/README_DEVELOPERS 2009-08-04 07:02:54 UTC (rev 10709) @@ -106,25 +106,24 @@ ~~~~~~~~~~~~ To run Valgrind under Valgrind: -(1) Check out 2 trees, "inner" and "outer". "inner" runs the app - directly and is what you will be profiling. "outer" does the - profiling. +(1) Check out 2 trees, "Inner" and "Outer". Inner runs the app + directly. Outer runs Inner. (2) Configure inner with --enable-inner and build/install as usual. -(3) Configure outer normally and build/install as usual. +(3) Configure Outer normally and build/install as usual. (4) Choose a very simple program (date) and try outer/.../bin/valgrind --sim-hints=enable-outer --trace-children=yes \ --tool=cachegrind -v inner/.../bin/valgrind --tool=none -v prog -If you omit the --trace-children=yes, you'll only monitor inner's launcher +If you omit the --trace-children=yes, you'll only monitor Inner's launcher program, not its stage2. The whole thing is fragile, confusing and slow, but it does work well enough -for you to get some useful performance data. The inner Valgrind has most of +for you to get some useful performance data. Inner has most of its output (ie. those lines beginning with "==<pid>==") prefixed with a '>', which helps a lot. @@ -132,8 +131,8 @@ so Memcheck is not as useful as it could be. It also has not been tested much, so don't be surprised if you hit problems. -When using self-hosting with an outer callgrind tool, use '--pop-on-jump' -(on the outer). Otherwise, callgrind has much higher memory requirements. +When using self-hosting with an outer Callgrind tool, use '--pop-on-jump' +(on the outer). Otherwise, Callgrind has much higher memory requirements. Printing out problematic blocks Modified: trunk/README_PACKAGERS =================================================================== --- trunk/README_PACKAGERS 2009-08-04 06:48:09 UTC (rev 10708) +++ trunk/README_PACKAGERS 2009-08-04 07:02:54 UTC (rev 10709) @@ -1,7 +1,4 @@ -These notes were significantly updated on 6 Dec 2007 for the Valgrind -3.3.0 release. - Greetings, packaging person! This information is aimed at people building binary distributions of Valgrind. @@ -77,20 +74,19 @@ from valgrind. --- Don't strip symbols from lib/valgrind/$platform/{cachegrind, - callgrind,drd,helgrind,lackey,massif,memcheck,none} - in the installation tree. Doing so will likely cause problems. - Removing the line number info is probably OK, although that has not - been tested by the Valgrind developers. +-- Don't strip symbols from lib/valgrind/* in the installation tree. + Doing so will likely cause problems. Removing the line number info is + probably OK (at least for some of the files in that directory), although + that has not been tested by the Valgrind developers. -- Please test the final installation works by running it on something huge. I suggest checking that it can start and exit successfully - both Firefox-2.0.0.X and OpenOffice.org 2.3.X. I use these as test - programs, and I know they fairly thoroughly exercise Valgrind. The - command lines to use are: + both Firefox and OpenOffice.org. I use these as test programs, and I + know they fairly thoroughly exercise Valgrind. The command lines to use + are: - valgrind -v --trace-children=yes mozilla + valgrind -v --trace-children=yes firefox valgrind -v --trace-children=yes soffice |
|
From: <sv...@va...> - 2009-08-04 06:48:23
|
Author: njn Date: 2009-08-04 07:48:09 +0100 (Tue, 04 Aug 2009) New Revision: 10708 Log: Add a bit more to Massif's manual chapter. Modified: trunk/massif/docs/ms-manual.xml Modified: trunk/massif/docs/ms-manual.xml =================================================================== --- trunk/massif/docs/ms-manual.xml 2009-08-04 06:10:30 UTC (rev 10707) +++ trunk/massif/docs/ms-manual.xml 2009-08-04 06:48:09 UTC (rev 10708) @@ -501,6 +501,7 @@ </sect2> + <sect2 id="ms-manual.forkingprograms" xreflabel="Forking Programs"> <title>Forking Programs</title> <para>If your program forks, the child will inherit all the profiling data that @@ -512,6 +513,66 @@ file, which will almost certainly make it unreadable by ms_print.</para> </sect2> + +<sect2 id="ms-manual.not-measured" + xreflabel="Memory Allocations Not Measured by Massif"> +<title>Memory Allocations Not Measured by Massif</title> +<para> +It is worth emphasising that Massif measures only heap memory, i.e. memory +allocated with +<function>malloc</function>, +<function>calloc</function>, +<function>realloc</function>, +<function>memalign</function>, +<function>new</function>, +<function>new[]</function>, +and a few other, similar functions. (And it can optionally measure stack +memory, of course.) This means it does <emphasis>not</emphasis> directly +measure memory allocated with lower-level system calls such as +<function>mmap</function>, +<function>mremap</function>, and +<function>brk</function>. +</para> + +<para> +Heap allocation functions such as <function>malloc</function> are built on +top of these system calls. For example, when needed, an allocator will +typically call <function>mmap</function> to allocate a large chunk of +memory, and then hand over pieces of that memory chunk to the client program +in response to calls to <function>malloc</function> et al. Massif directly +measures only these higher-level <function>malloc</function> et al calls, +not the lower-level system calls. +</para> + +<para> +Furthermore, a client program may use these lower-level system calls +directly to allocate memory. Massif does not measure these. Nor does it +measure the size of code, data and BSS segments. Therefore, the numbers +reported by Massif may be significantly smaller than those reported by tools +such as <filename>top</filename> that measure a program's total size in +memory. +</para> + +</sect2> + + +<sect2 id="ms-manual.acting" xreflabel="Action on Massif's Information"> +<title>Acting on Massif's Information</title> +<para>Massif's information is generally fairly easy to act upon. The +obvious place to start looking is the peak snapshot.</para> + +<para>It can also be useful to look at the overall shape of the graph, to +see if memory usage climbs and falls as you expect; spikes in the graph +might be worth investigating.</para> + +<para>The detailed snapshots can get quite large. It is worth viewing them +in a very wide window. It's also a good idea to view them with a text +editor. That makes it easy to scroll up and down while keeping the cursor +in a particular column, which makes following the allocation chains easier. +</para> + +</sect2> + </sect1> @@ -708,6 +769,18 @@ </sect1> +<sect1 id="ms-manual.clientreqs" xreflabel="Client requests"> +<title>Massif Client Requests</title> + +<para>Massif does not have a <filename>massif.h</filename> file, but it does +implement two of the core client requests: +<function>VALGRIND_MALLOCLIKE_BLOCK</function> and +<function>VALGRIND_FREELIKE_BLOCK</function>. These work in the obvious +way.</para> + +</sect1> + + <sect1 id="ms-manual.ms_print-options" xreflabel="ms_print Options"> <title>ms_print Options</title> |
|
From: <sv...@va...> - 2009-08-04 06:10:44
|
Author: njn Date: 2009-08-04 07:10:30 +0100 (Tue, 04 Aug 2009) New Revision: 10707 Log: A couple of minor Massif manual improvements. Modified: trunk/massif/docs/ms-manual.xml Modified: trunk/massif/docs/ms-manual.xml =================================================================== --- trunk/massif/docs/ms-manual.xml 2009-08-04 05:59:46 UTC (rev 10706) +++ trunk/massif/docs/ms-manual.xml 2009-08-04 06:10:30 UTC (rev 10707) @@ -68,7 +68,8 @@ statistics are printed to Valgrind's commentary; all of Massif's profiling data is written to a file. By default, this file is called <filename>massif.out.<pid></filename>, where -<filename><pid></filename> is the process ID.</para> +<filename><pid></filename> is the process ID, although this filename +can be changed with the <option>--massif-out-file</option> option.</para> <para>To see the information gathered by Massif in an easy-to-read form, use the ms_print script. If the output file's name is @@ -222,14 +223,16 @@ Detailed snapshots: [9, 14 (peak), 24] ]]></screen> -<para>Each vertical bar represents a snapshot, i.e. a measurement of the -memory usage at a certain point in time. If the next snapshot is more than -one column away, a horizontal line of characters is drawn from the top of -the snapshot to just before the next snapshot column. The text at the -bottom show that 25 snapshots were taken for this program, which is one per -heap allocation/deallocation, plus a couple of extras. Massif starts by -taking snapshots for every heap allocation/deallocation, but as a program -runs for longer, it takes snapshots less frequently. It also discards older +<para>The size of the graph can be changed with ms_print's +<option>--x</option> and <option>--y</option> options. Each vertical bar +represents a snapshot, i.e. a measurement of the memory usage at a certain +point in time. If the next snapshot is more than one column away, a +horizontal line of characters is drawn from the top of the snapshot to just +before the next snapshot column. The text at the bottom show that 25 +snapshots were taken for this program, which is one per heap +allocation/deallocation, plus a couple of extras. Massif starts by taking +snapshots for every heap allocation/deallocation, but as a program runs for +longer, it takes snapshots less frequently. It also discards older snapshots as the program goes on; when it reaches the maximum number of snapshots (100 by default, although changeable with the <option>--max-snapshots</option> option) half of them are @@ -358,7 +361,10 @@ <listitem><para>The size of the stack(s). By default, stack profiling is off as it slows Massif down greatly. Therefore, the stack column is zero - in the example.</para></listitem> + in the example. Stack profiling can be turned on with the + <option>--stacks=yes</option> option. + + </para></listitem> </itemizedlist> <para>The next snapshot is detailed. As well as the basic counts, it gives |
|
From: <sv...@va...> - 2009-08-04 05:59:54
|
Author: njn
Date: 2009-08-04 06:59:46 +0100 (Tue, 04 Aug 2009)
New Revision: 10706
Log:
Overhaul Massif's manual, and a few minor related things.
Modified:
trunk/cachegrind/docs/cg-manual.xml
trunk/callgrind/docs/cl-manual.xml
trunk/massif/docs/ms-manual.xml
trunk/massif/ms_main.c
trunk/massif/ms_print.in
Modified: trunk/cachegrind/docs/cg-manual.xml
===================================================================
--- trunk/cachegrind/docs/cg-manual.xml 2009-08-04 05:24:46 UTC (rev 10705)
+++ trunk/cachegrind/docs/cg-manual.xml 2009-08-04 05:59:46 UTC (rev 10706)
@@ -441,8 +441,7 @@
<option>%p</option> and <option>%q</option> format specifiers
can be used to embed the process ID and/or the contents of an
environment variable in the name, as is the case for the core
- option <option>--log-file</option>. See <link
- linkend="manual-core.basicopts">here</link> for details.
+ option <option><xref linkend="opt.log-file"/></option>.
</para>
</listitem>
</varlistentry>
Modified: trunk/callgrind/docs/cl-manual.xml
===================================================================
--- trunk/callgrind/docs/cl-manual.xml 2009-08-04 05:24:46 UTC (rev 10705)
+++ trunk/callgrind/docs/cl-manual.xml 2009-08-04 05:59:46 UTC (rev 10706)
@@ -534,8 +534,7 @@
<option>%p</option> and <option>%q</option> format specifiers
can be used to embed the process ID and/or the contents of an
environment variable in the name, as is the case for the core
- option <option>--log-file</option>. See <link
- linkend="manual-core.basicopts">here</link> for details.
+ option <option><xref linkend="opt.log-file"/></option>.
When multiple dumps are made, the file name
is modified further; see below.</para>
</listitem>
Modified: trunk/massif/docs/ms-manual.xml
===================================================================
--- trunk/massif/docs/ms-manual.xml 2009-08-04 05:24:46 UTC (rev 10705)
+++ trunk/massif/docs/ms-manual.xml 2009-08-04 05:59:46 UTC (rev 10706)
@@ -61,7 +61,7 @@
<para>Then, to gather heap profiling information about the program
<computeroutput>prog</computeroutput>, type:</para>
<screen><![CDATA[
-% valgrind --tool=massif prog
+valgrind --tool=massif prog
]]></screen>
<para>The program will execute (slowly). Upon completion, no summary
@@ -74,7 +74,7 @@
the ms_print script. If the output file's name is
<filename>massif.out.12345</filename>, type:</para>
<screen><![CDATA[
-% ms_print massif.out.12345]]></screen>
+ms_print massif.out.12345]]></screen>
<para>ms_print will produce (a) a graph showing the memory consumption over
the program's execution, and (b) detailed information about the responsible
@@ -257,7 +257,7 @@
<para>Some more details about the peak: the peak is determined by looking
at every allocation, i.e. it is <emphasis>not</emphasis> just the peak among
-the regular snapshots. However, recording the true peak is expensive, and
+the regular snapshots. However, recording the true peak can be expensive, and
so by default Massif records a peak whose size is within 1% of the size of
the true peak. See the description of the
<option>--peak-inaccuracy</option> option below for more
@@ -350,12 +350,11 @@
<option>--heap-admin</option> option.</para>
<para>Second, allocators often round up the number of bytes asked for to a
- larger number. By default, if N bytes are asked for, Massif rounds N up
- to the nearest multiple of 8 that is equal to or greater than N. This is
- typical behaviour for allocators, and is required to ensure that elements
- within the block are suitably aligned. The rounding size can be changed
- with the <option>--alignment</option> option, although it
- cannot be less than 8, and must be a power of two.</para></listitem>
+ larger number, usually 8 or 16. This is required to ensure that elements
+ within the block are suitably aligned. If N bytes are asked for, Massif
+ rounds N up to the nearest multiple of the value specified by the
+ <option><xref linkend="opt.alignment"/></option> option.
+ </para></listitem>
<listitem><para>The size of the stack(s). By default, stack profiling is
off as it slows Massif down greatly. Therefore, the stack column is zero
@@ -377,7 +376,7 @@
and C++ <function>new</function>. All heap allocations go through these
functions, and so all 9,000 useful bytes (which is 99.21% of all allocated
bytes) go through them. But how were <function>malloc</function> and new
-called? At this point, every allocation so far has been due to line 21
+called? At this point, every allocation so far has been due to line 20
inside <function>main</function>, hence the second line in the tree. The
<option>-></option> indicates that main (line 20) called
<function>malloc</function>.</para>
@@ -407,9 +406,9 @@
]]></screen>
<para>The first four snapshots are similar to the previous ones. But then
-the global allocation peak is reached, and a detailed snapshot is taken.
-Its allocation tree shows that 20,000B of useful heap memory has been
-allocated, and the lines and arrows indicate that this is from three
+the global allocation peak is reached, and a detailed snapshot (number 14)
+is taken. Its allocation tree shows that 20,000B of useful heap memory has
+been allocated, and the lines and arrows indicate that this is from three
different code locations: line 20, which is responsible for 10,000B
(49.74%); line 5, which is responsible for 8,000B (39.79%); and line 10,
which is responsible for 2,000B (9.95%).</para>
@@ -529,16 +528,16 @@
<varlistentry id="opt.heap-admin" xreflabel="--heap-admin">
<term>
- <option><![CDATA[--heap-admin=<number> [default: 8] ]]></option>
+ <option><![CDATA[--heap-admin=<size> [default: 8] ]]></option>
</term>
<listitem>
<para>If heap profiling is enabled, gives the number of administrative
bytes per block to use. This should be an estimate of the average,
since it may vary. For example, the allocator used by
glibc on Linux requires somewhere between 4 to
- 15 bytes per block, depending on various factors. It also requires
- admin space for freed blocks, although Massif does not account
- for this.</para>
+ 15 bytes per block, depending on various factors. That allocator also
+ requires admin space for freed blocks, but Massif cannot
+ account for this.</para>
</listitem>
</varlistentry>
@@ -550,9 +549,9 @@
<para>Specifies whether stack profiling should be done. This option
slows Massif down greatly, and so is off by default. Note that Massif
assumes that the main stack has size zero at start-up. This is not
- true, but measuring the actual stack size is not easy, and it reflects
- the size of the part of the main stack that a user program actually
- has control over.</para>
+ true, but doing otherwise accurately is difficult. Furthermore,
+ starting at zero better indicates the size of the part of the main
+ stack that a user program actually has control over.</para>
</listitem>
</varlistentry>
@@ -580,11 +579,11 @@
This option can be specified multiple times on the command line, to
name multiple functions.</para>
- <para>Note that overloaded C++ names must be written in full. Single
- quotes may be necessary to prevent the shell from breaking them up.
- For example:
+ <para>Note that C++ names are demangled. Note also that overloaded
+ C++ names must be written in full. Single quotes may be necessary to
+ prevent the shell from breaking them up. For example:
<screen><![CDATA[
---alloc-fn='operator new(unsigned, std::nothrow_t const&)'
+--alloc-fn='operator new(unsigned, std::nothrow_t const&)'
]]></screen>
</para>
</listitem>
@@ -597,7 +596,7 @@
<listitem>
<para>Any direct heap allocation (i.e. a call to
<function>malloc</function>, <function>new</function>, etc, or a call
- to a function name in a <option>--alloc-fn</option>
+ to a function named by an <option>--alloc-fn</option>
option) that occurs in a function specified by this option will be
ignored. This is mostly useful for testing purposes. This option can
be specified multiple times on the command line, to name multiple
@@ -611,8 +610,8 @@
<function>realloc</function>.
</para>
- <para>Note that overloaded C++ names must be written in full, as for
- <option>--alloc-fn</option> above.
+ <para>The rules for writing C++ function names are the same as
+ for <option>--alloc-fn</option> above.
</para>
</listitem>
</varlistentry>
@@ -623,9 +622,9 @@
</term>
<listitem>
<para>The significance threshold for heap allocations, as a
- percentage. Allocation tree entries that account for less than this
- will be aggregated. Note that this should be specified in tandem with
- ms_print's option of the same name.</para>
+ percentage of total memory size. Allocation tree entries that account
+ for less than this will be aggregated. Note that this should be
+ specified in tandem with ms_print's option of the same name.</para>
</listitem>
</varlistentry>
@@ -647,7 +646,7 @@
<varlistentry id="opt.time-unit" xreflabel="--time-unit">
<term>
- <option><![CDATA[--time-unit=i|ms|B [default: i] ]]></option>
+ <option><![CDATA[--time-unit=<i|ms|B> [default: i] ]]></option>
</term>
<listitem>
<para>The time unit used for the profiling. There are three
@@ -692,21 +691,11 @@
<option>%p</option> and <option>%q</option> format specifiers can be
used to embed the process ID and/or the contents of an environment
variable in the name, as is the case for the core option
- <option>--log-file</option>. See <xref
- linkend="manual-core.basicopts"/> for details.
+ <option><xref linkend="opt.log-file"/></option>.
</para>
</listitem>
</varlistentry>
- <varlistentry id="opt.alignment" xreflabel="--alignment">
- <term>
- <option><![CDATA[--alignment=<n> [default: 1.0] ]]></option>
- </term>
- <listitem>
- <para>The minimum alignment (and thus size) of heap blocks.</para>
- </listitem>
- </varlistentry>
-
</variablelist>
<!-- end of xi:include in the manpage -->
@@ -731,7 +720,7 @@
<varlistentry>
<term>
- <option><![CDATA[-v --version ]]></option>
+ <option><![CDATA[--version ]]></option>
</term>
<listitem>
<para>Show the version number.</para>
@@ -750,7 +739,7 @@
<varlistentry>
<term>
- <option><![CDATA[--x=<n> [default: 72]]]></option>
+ <option><![CDATA[--x=<4..1000> [default: 72]]]></option>
</term>
<listitem>
<para>Width of the graph, in columns.</para>
@@ -759,7 +748,7 @@
<varlistentry>
<term>
- <option><![CDATA[--y=<n> [default: 20] ]]></option>
+ <option><![CDATA[--y=<4..1000> [default: 20] ]]></option>
</term>
<listitem>
<para>Height of the graph, in rows.</para>
@@ -775,9 +764,9 @@
<para>Massif's file format is plain text (i.e. not binary) and deliberately
easy to read for both humans and machines. Nonetheless, the exact format
is not described here. This is because the format is currently very
-Massif-specific. We plan to make the format more general, and thus suitable
-for possible use with other tools. Once this has been done, the format will
-be documented here.</para>
+Massif-specific. In the future we hope to make the format more general, and
+thus suitable for possible use with other tools. Once this has been done,
+the format will be documented here.</para>
</sect1>
Modified: trunk/massif/ms_main.c
===================================================================
--- trunk/massif/ms_main.c 2009-08-04 05:24:46 UTC (rev 10705)
+++ trunk/massif/ms_main.c 2009-08-04 05:59:46 UTC (rev 10706)
@@ -49,7 +49,7 @@
// identified? [hmm, could make getting the name of alloc-fns more
// difficult] [could dump full names to file, truncate in ms_print]
// - make --show-below-main=no work
-// - Options like --alloc-fn='operator new(unsigned, std::nothrow_t const&)'
+// - Options like --alloc-fn='operator new(unsigned, std::nothrow_t const&)'
// don't work in a .valgrindrc file or in $VALGRIND_OPTS.
// m_commandline.c:add_args_from_string() needs to respect single quotes.
// - With --stack=yes, want to add a stack trace for detailed snapshots so
@@ -446,7 +446,7 @@
{
VG_(printf)(
" --heap=no|yes profile heap blocks [yes]\n"
-" --heap-admin=<number> average admin bytes per heap block;\n"
+" --heap-admin=<size> average admin bytes per heap block;\n"
" ignored if --heap=no [8]\n"
" --stacks=no|yes profile stack(s) [no]\n"
" --depth=<number> depth of contexts [30]\n"
Modified: trunk/massif/ms_print.in
===================================================================
--- trunk/massif/ms_print.in 2009-08-04 05:24:46 UTC (rev 10705)
+++ trunk/massif/ms_print.in 2009-08-04 05:59:46 UTC (rev 10706)
@@ -66,10 +66,10 @@
options for the user, with defaults in [ ], are:
-h --help show this message
- -v --version show version
+ --version show version
--threshold=<n.n> significance threshold, in percent [$threshold]
- --x=<n> graph width, in columns; min=4, max=1000 [72]
- --y=<n> graph height, in rows; min=4, max=1000 [20]
+ --x=<4..1000> graph width, in columns [72]
+ --y=<4..1000> graph height, in rows [20]
ms_print is Copyright (C) 2007-2007 Nicholas Nethercote.
and licensed under the GNU General Public License, version 2.
@@ -107,7 +107,7 @@
if ($arg =~ /^-/) {
# --version
- if ($arg =~ /^-v$|^--version$/) {
+ if ($arg =~ /^--version$/) {
die("ms_print-$version\n");
# --threshold=X (tolerates a trailing '%')
|
|
From: <sv...@va...> - 2009-08-04 05:24:57
|
Author: njn
Date: 2009-08-04 06:24:46 +0100 (Tue, 04 Aug 2009)
New Revision: 10705
Log:
Various clean-ups, mostly in chapter 3.
Modified:
trunk/docs/xml/manual-core-adv.xml
trunk/memcheck/docs/mc-manual.xml
Modified: trunk/docs/xml/manual-core-adv.xml
===================================================================
--- trunk/docs/xml/manual-core-adv.xml 2009-08-04 02:35:09 UTC (rev 10704)
+++ trunk/docs/xml/manual-core-adv.xml 2009-08-04 05:24:46 UTC (rev 10705)
@@ -25,25 +25,27 @@
<para>Valgrind has a trapdoor mechanism via which the client
program can pass all manner of requests and queries to Valgrind
-and the current tool. Internally, this is used extensively to
-make malloc, free, etc, work, although you don't see that.</para>
+and the current tool. Internally, this is used extensively
+to make various things work, although that's not visible from the
+outside.</para>
<para>For your convenience, a subset of these so-called client
requests is provided to allow you to tell Valgrind facts about
the behaviour of your program, and also to make queries.
-In particular, your program can tell Valgrind about changes in
-memory range permissions that Valgrind would not otherwise know
-about, and so allows clients to get Valgrind to do arbitrary
-custom checks.</para>
+In particular, your program can tell Valgrind about things that it
+otherwise would not know, leading to better results.
+</para>
<para>Clients need to include a header file to make this work.
Which header file depends on which client requests you use. Some
client requests are handled by the core, and are defined in the
header file <filename>valgrind/valgrind.h</filename>. Tool-specific
header files are named after the tool, e.g.
-<filename>valgrind/memcheck.h</filename>. All header files can be found
-in the <literal>include/valgrind</literal> directory of wherever Valgrind
-was installed.</para>
+<filename>valgrind/memcheck.h</filename>. Each tool-specific header file
+includes <filename>valgrind/valgrind.h</filename> so you don't need to
+include it in your client if you include a tool-specific header. All header
+files can be found in the <literal>include/valgrind</literal> directory of
+wherever Valgrind was installed.</para>
<para>The macros in these header files have the magical property
that they generate code in-line which Valgrind can spot.
@@ -58,7 +60,7 @@
However, if you really wish to compile out the client requests, you can
compile with <option>-DNVALGRIND</option> (analogous to
<option>-DNDEBUG</option>'s effect on
-<computeroutput>assert()</computeroutput>).
+<function>assert</function>).
</para>
<para>You are encouraged to copy the <filename>valgrind/*.h</filename> headers
@@ -94,7 +96,7 @@
Valgrind to make new translations of that code, which is
probably the semantics you want. Note that code invalidations
are expensive because finding all the relevant translations
- quickly is very difficult. So try not to call it often.
+ quickly is very difficult, so try not to call it often.
Note that you can be clever about
this: you only need to call it when an area which previously
contained code is overwritten with new code. You can choose
@@ -126,9 +128,9 @@
<term><command><computeroutput>VALGRIND_MALLOCLIKE_BLOCK</computeroutput>:</command></term>
<listitem>
<para>If your program manages its own memory instead of using
- the standard <computeroutput>malloc()</computeroutput> /
- <computeroutput>new</computeroutput> /
- <computeroutput>new[]</computeroutput>, tools that track
+ the standard <function>malloc</function> /
+ <function>new</function> /
+ <function>new[]</function>, tools that track
information about heap blocks will not do nearly as good a
job. For example, Memcheck won't detect nearly as many
errors, and the error messages won't be as informative. To
@@ -144,7 +146,7 @@
<listitem>
<para>This should be used in conjunction with
<computeroutput>VALGRIND_MALLOCLIKE_BLOCK</computeroutput>.
- Again, see <filename>memcheck/memcheck.h</filename> for
+ Again, see <filename>valgrind.h</filename> for
information on how to use it.</para>
</listitem>
</varlistentry>
@@ -193,20 +195,18 @@
<varlistentry>
<term><command><computeroutput>VALGRIND_NON_SIMD_CALL[0123]</computeroutput>:</command></term>
<listitem>
- <para>Executes a function of 0, 1, 2 or 3 args in the client
- program on the <emphasis>real</emphasis> CPU, not the virtual
- CPU that Valgrind normally runs code on. These are used in
- various ways internally to Valgrind. They might be useful to
- client programs.</para>
+ <para>Executes a function in the client program on the
+ <emphasis>real</emphasis> CPU, not the virtual CPU that Valgrind
+ normally runs code on. The function must take an integer (holding a
+ thread ID) as the first argument and then 0, 1, 2 or 3 more arguments
+ (depending on which client request is used). These are used in various
+ ways internally to Valgrind. They might be useful to client
+ programs.</para>
<para><command>Warning:</command> Only use these if you
<emphasis>really</emphasis> know what you are doing. They aren't
- entirely reliable, and can cause Valgrind to crash.
- Generally, your prospects of these working are made higher if the called
- function does not refer to any global variables, and does not refer to any
- libc or other functions (printf et al). Any kind of entanglement with libc
- or dynamic linking is likely to have a bad outcome, for tricky reasons
- which we've grappled with a lot in the past.
+ entirely reliable, and can cause Valgrind to crash. See
+ <filename>valgrind.h</filename> for more details.
</para>
</listitem>
</varlistentry>
@@ -214,22 +214,23 @@
<varlistentry>
<term><command><computeroutput>VALGRIND_PRINTF(format, ...)</computeroutput>:</command></term>
<listitem>
- <para>printf a message to the log file when running under
- Valgrind, prefixed with the PID between a pair of
- <computeroutput>**</computeroutput> markers. Nothing is output if not
- running under Valgrind. Output is not produced until a newline is
- encountered, or subequent Valgrind output is printed; this allows you
- to build up a single line of output over multiple calls.
- Returns the number of characters output, excluding the PID at the
- start.</para>
+ <para>Print a printf-style message to the Valgrind log file. The
+ message is prefixed with the PID between a pair of
+ <computeroutput>**</computeroutput> markers. (Like all client requests,
+ nothing is output if the client program is not running under Valgrind.)
+ Output is not produced until a newline is encountered, or subequent
+ Valgrind output is printed; this allows you to build up a single line of
+ output over multiple calls. Returns the number of characters output,
+ excluding the PID prefix.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><command><computeroutput>VALGRIND_PRINTF_BACKTRACE(format, ...)</computeroutput>:</command></term>
<listitem>
- <para>Like <computeroutput>VALGRIND_PRINTF</computeroutput>, but prints
- a stack backtrace immediately afterwards.</para>
+ <para>Like <computeroutput>VALGRIND_PRINTF</computeroutput> (in
+ particular, the return value is identical), but prints a stack backtrace
+ immediately afterwards.</para>
</listitem>
</varlistentry>
@@ -245,6 +246,9 @@
to a new stack. Use this if you're using a user-level thread package
and are noticing spurious errors from Valgrind about uninitialized
memory reads.</para>
+
+ <para><command>Warning:</command> Unfortunately, this client request is
+ unreliable and best avoided.</para>
</listitem>
</varlistentry>
@@ -254,6 +258,9 @@
<para>Deregisters a previously registered stack. Informs
Valgrind that previously registered memory range with stack id
<computeroutput>id</computeroutput> is no longer a stack.</para>
+
+ <para><command>Warning:</command> Unfortunately, this client request is
+ unreliable and best avoided.</para>
</listitem>
</varlistentry>
@@ -265,16 +272,14 @@
<computeroutput>id</computeroutput> has changed its start and end
values. Use this if your user-level thread package implements
stack growth.</para>
+
+ <para><command>Warning:</command> Unfortunately, this client request is
+ unreliable and best avoided.</para>
</listitem>
</varlistentry>
</variablelist>
-<para>Note that <filename>valgrind.h</filename> is included by
-all the tool-specific header files (such as
-<filename>memcheck.h</filename>), so you don't need to include it
-in your client if you include a tool-specific header.</para>
-
</sect1>
@@ -285,22 +290,21 @@
<title>Function wrapping</title>
<para>
-Valgrind versions 3.2.0 and above can do function wrapping on all
-supported targets. In function wrapping, calls to some specified
-function are intercepted and rerouted to a different, user-supplied
-function. This can do whatever it likes, typically examining the
-arguments, calling onwards to the original, and possibly examining the
-result. Any number of functions may be wrapped.</para>
+Valgrind allows calls to some specified functions to be intercepted and
+rerouted to a different, user-supplied function. This can do whatever it
+likes, typically examining the arguments, calling onwards to the original,
+and possibly examining the result. Any number of functions may be
+wrapped.</para>
<para>
Function wrapping is useful for instrumenting an API in some way. For
-example, wrapping functions in the POSIX pthreads API makes it
-possible to notify Valgrind of thread status changes, and wrapping
-functions in the MPI (message-passing) API allows notifying Valgrind
+example, Helgrind wraps functions in the POSIX pthreads API so it can know
+about thread status changes, and the core is able to wrap
+functions in the MPI (message-passing) API so it can know
of memory status changes associated with message arrival/departure.
Such information is usually passed to Valgrind by using client
-requests in the wrapper functions, although that is not of relevance
-here.</para>
+requests in the wrapper functions, although the exact mechanism may vary.
+</para>
<sect2 id="manual-core-adv.wrapping.example" xreflabel="A Simple Example">
<title>A Simple Example</title>
@@ -313,7 +317,7 @@
<para>A wrapper is a function of identical type, but with a special name
which identifies it as the wrapper for <computeroutput>foo</computeroutput>.
Wrappers need to include
-supporting macros from <computeroutput>valgrind.h</computeroutput>.
+supporting macros from <filename>valgrind.h</filename>.
Here is a simple wrapper which prints the arguments and return value:</para>
<programlisting><![CDATA[
@@ -367,8 +371,8 @@
<para><computeroutput>CALL_FN_W_WW</computeroutput>: eventually we will
want to call the function being
wrapped. Calling it directly does not work, since that just gets us
-back to the wrapper and tends to kill the program in short order by
-stack overflow. Instead, the result lvalue,
+back to the wrapper and leads to an infinite loop. Instead, the result
+lvalue,
<computeroutput>OrigFn</computeroutput> and arguments are
handed to one of a family of macros of the form
<computeroutput>CALL_FN_*</computeroutput>. These
@@ -469,27 +473,27 @@
Valgrind tries to maintain sensible behaviour in such situations.</para>
<para>For example, suppose a process has dlopened (an ELF object with
-soname) <computeroutput>object1.so</computeroutput>, which contains
+soname) <filename>object1.so</filename>, which contains
<computeroutput>function1</computeroutput>. It starts to use
<computeroutput>function1</computeroutput> immediately.</para>
-<para>After a while it dlopens <computeroutput>wrappers.so</computeroutput>,
+<para>After a while it dlopens <filename>wrappers.so</filename>,
which contains a wrapper
for <computeroutput>function1</computeroutput> in (soname)
-<computeroutput>object1.so</computeroutput>. All subsequent calls to
+<filename>object1.so</filename>. All subsequent calls to
<computeroutput>function1</computeroutput> are rerouted to the wrapper.</para>
-<para>If <computeroutput>wrappers.so</computeroutput> is
+<para>If <filename>wrappers.so</filename> is
later dlclose'd, calls to <computeroutput>function1</computeroutput> are
naturally routed back to the original.</para>
-<para>Alternatively, if <computeroutput>object1.so</computeroutput>
-is dlclose'd but wrappers.so remains,
-then the wrapper exported by <computeroutput>wrapper.so</computeroutput>
+<para>Alternatively, if <filename>object1.so</filename>
+is dlclose'd but <filename>wrappers.so</filename> remains,
+then the wrapper exported by <filename>wrappers.so</filename>
becomes inactive, since there
is no way to get to it - there is no original to call any more. However,
Valgrind remembers that the wrapper is still present. If
-<computeroutput>object1.so</computeroutput> is
+<filename>object1.so</filename> is
eventually dlopen'd again, the wrapper will become active again.</para>
<para>In short, valgrind inspects all code loading/unloading events to
@@ -511,7 +515,7 @@
this possible
by showing the complete state of the redirection subsystem after
every
-<computeroutput>mmap</computeroutput>/<computeroutput>munmap</computeroutput>
+<function>mmap</function>/<function>munmap</function>
event affecting code (text).</para>
<para>There are two central concepts:</para>
@@ -525,7 +529,7 @@
<computeroutput>I_WRAP_SONAME_FNNAME_{ZZ,_ZU}</computeroutput>
macros.</para></listitem>
- <listitem><para>An "active redirection" is code-address to
+ <listitem><para>An "active redirection" is a code-address to
code-address binding currently in effect.</para></listitem>
</itemizedlist>
@@ -533,7 +537,7 @@
<para>The state of the wrapping-and-redirection subsystem comprises a set of
specifications and a set of active bindings. The specifications are
acquired/discarded by watching all
-<computeroutput>mmap</computeroutput>/<computeroutput>munmap</computeroutput>
+<function>mmap</function>/<function>munmap</function>
events on code (text)
sections. The active binding set is (conceptually) recomputed from
the specifications, and all known symbol names, following any change
@@ -551,7 +555,7 @@
<para>One final comment. The function-wrapping facility is closely
tied to Valgrind's ability to replace (redirect) specified
functions, for example to redirect calls to
-<computeroutput>malloc</computeroutput> to its
+<function>malloc</function> to its
own implementation. Indeed, a replacement function can be
regarded as a wrapper function which does not call the original.
However, to make the implementation more robust, the two kinds
@@ -581,8 +585,8 @@
calls between, recursion between, and longjumps out of wrappers
should work correctly. There is never any interaction between wrapped
functions and merely replaced functions
-(eg <computeroutput>malloc</computeroutput>), so you can call
-<computeroutput>malloc</computeroutput> etc safely from within wrappers.
+(eg <function>malloc</function>), so you can call
+<function>malloc</function> etc safely from within wrappers.
</para>
<para>The above comments are true for {x86,amd64,ppc32}-linux. On
@@ -619,21 +623,21 @@
The currently available macros are:</para>
<programlisting><![CDATA[
-CALL_FN_v_v -- call an original of type void fn ( void )
-CALL_FN_W_v -- call an original of type long fn ( void )
+CALL_FN_v_v -- call an original of type void fn ( void )
+CALL_FN_W_v -- call an original of type long fn ( void )
-CALL_FN_v_W -- void fn ( long )
-CALL_FN_W_W -- long fn ( long )
+CALL_FN_v_W -- call an original of type void fn ( long )
+CALL_FN_W_W -- call an original of type long fn ( long )
-CALL_FN_v_WW -- void fn ( long, long )
-CALL_FN_W_WW -- long fn ( long, long )
+CALL_FN_v_WW -- call an original of type void fn ( long, long )
+CALL_FN_W_WW -- call an original of type long fn ( long, long )
-CALL_FN_v_WWW -- void fn ( long, long, long )
-CALL_FN_W_WWW -- long fn ( long, long, long )
+CALL_FN_v_WWW -- call an original of type void fn ( long, long, long )
+CALL_FN_W_WWW -- call an original of type long fn ( long, long, long )
-CALL_FN_W_WWWW -- long fn ( long, long, long, long )
-CALL_FN_W_5W -- long fn ( long, long, long, long, long )
-CALL_FN_W_6W -- long fn ( long, long, long, long, long, long )
+CALL_FN_W_WWWW -- call an original of type long fn ( long, long, long, long )
+CALL_FN_W_5W -- call an original of type long fn ( long, long, long, long, long )
+CALL_FN_W_6W -- call an original of type long fn ( long, long, long, long, long, long )
and so on, up to
CALL_FN_W_12W
]]></programlisting>
@@ -641,14 +645,14 @@
<para>The set of supported types can be expanded as needed. It is
regrettable that this limitation exists. Function wrapping has proven
difficult to implement, with a certain apparently unavoidable level of
-ickyness. After several implementation attempts, the present
+ickiness. After several implementation attempts, the present
arrangement appears to be the least-worst tradeoff. At least it works
reliably in the presence of dynamic linking and dynamic code
loading/unloading.</para>
<para>You should not attempt to wrap a function of one type signature with a
wrapper of a different type signature. Such trickery will surely lead
-to crashes or strange behaviour. This is not of course a limitation
+to crashes or strange behaviour. This is not a limitation
of the function wrapping implementation, merely a reflection of the
fact that it gives you sweeping powers to shoot yourself in the foot
if you are not careful. Imagine the instant havoc you could wreak by
@@ -661,10 +665,10 @@
<title>Examples</title>
<para>In the source tree,
-<computeroutput>memcheck/tests/wrap[1-8].c</computeroutput> provide a series of
+<filename>memcheck/tests/wrap[1-8].c</filename> provide a series of
examples, ranging from very simple to quite advanced.</para>
-<para><computeroutput>auxprogs/libmpiwrap.c</computeroutput> is an example
+<para><filename>mpi/libmpiwrap.c</filename> is an example
of wrapping a big, complex API (the MPI-2 interface). This file defines
almost 300 different wrappers.</para>
</sect2>
Modified: trunk/memcheck/docs/mc-manual.xml
===================================================================
--- trunk/memcheck/docs/mc-manual.xml 2009-08-04 02:35:09 UTC (rev 10704)
+++ trunk/memcheck/docs/mc-manual.xml 2009-08-04 05:24:46 UTC (rev 10705)
@@ -1562,7 +1562,7 @@
<para>Unlike most of the rest of Valgrind, the wrapper library is subject to a
BSD-style license, so you can link it into any code base you like.
-See the top of <computeroutput>auxprogs/libmpiwrap.c</computeroutput>
+See the top of <computeroutput>mpi/libmpiwrap.c</computeroutput>
for license details.</para>
@@ -1866,7 +1866,7 @@
checks.</para>
<para>Writing new wrappers should be fairly easy. The source file is
-<computeroutput>auxprogs/libmpiwrap.c</computeroutput>. If possible,
+<computeroutput>mpi/libmpiwrap.c</computeroutput>. If possible,
find an existing wrapper for a function of similar behaviour to the
one you want to wrap, and use it as a starting point. The wrappers
are organised in sections in the same order as the MPI 1.1 spec, to
|
|
From: John R. <jr...@bi...> - 2009-08-04 03:45:09
|
On 08/03/2009 06:31 PM, Ayan Chowdhury wrote: > valgrind: mmap(0x38000000, 1503232) failed in UME with error 22 (Invalid argument). > valgrind: this can be caused by executables with very large text, data or bss segments. First, determine exactly _why_ there is an error 22 (Invalid argument). What does "readelf --segments my_app" show? Turn on verbose and debugging. It will be helpful to see how valgrind's address space manager has apportioned the whole address space. When the error 22 occurs, what does "cat /proc/<pid>/maps" show [do this from another process]? If the error 22 is caused by a conflict over a specific virtual address, then which virtual address is it, and who is contending for it? Run valgrind under strace to see all the mmap syscalls. (Approximately: "strace -o strace.out -e trace=mmap valgrind my_app".) If the error 22 is merely a symptom of "not enough address space to go around", then you may be able to "buy" 33% more space. Re-build valgrind for i686 with 0x38000000 changed to 0x60000000; grep the various Makefiles [and other build control files] of the valgrind tree. Then run your app, under the control of your new custom valgrind, on a x86_64 machine that does support a 32-bit i686 execution environment. In most cases such a 32-bit i686 environment running on an x86_64 offers almost 4GB of address space for user mode, in contrast to the typical 3GB that an actual i686 offers for user mode address space. -- |
|
From: Tom H. <th...@cy...> - 2009-08-04 02:48:59
|
Nightly build on lloyd ( x86_64, Fedora 7 ) Started at 2009-08-04 03:05:03 BST Ended at 2009-08-04 03:48:32 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 520 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 521 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Tue Aug 4 03:27:18 2009 --- new.short Tue Aug 4 03:48:32 2009 *************** *** 8,10 **** ! == 521 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) --- 8,10 ---- ! == 520 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |
|
From: <sv...@va...> - 2009-08-04 02:35:34
|
Author: njn
Date: 2009-08-04 03:35:09 +0100 (Tue, 04 Aug 2009)
New Revision: 10704
Log:
tweak
Modified:
trunk/NEWS
Modified: trunk/NEWS
===================================================================
--- trunk/NEWS 2009-08-04 02:32:55 UTC (rev 10703)
+++ trunk/NEWS 2009-08-04 02:35:09 UTC (rev 10704)
@@ -42,7 +42,7 @@
==3050== Memcheck, a memory error detector.
==3050== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
-==3050== Using Valgrind-3.5.0.SVN and LibVEX; rerun with -h for copyright info
+==3050== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==3050== Command: ls -l
==3050==
@@ -61,6 +61,9 @@
multiple output lines with a single request (by embedding multiple
newlines in the string).
+* XXX: mention --read-var-info. It was mentioned as a developer-visible
+ change in 3.4.0, but it's useful for normal users of some tools as well.
+
* Memcheck's leak checker has been improved.
- The results for --leak-check=summary now match the summary results for
--leak-check=full. Previously they could differ because
|
Author: njn
Date: 2009-08-04 03:32:55 +0100 (Tue, 04 Aug 2009)
New Revision: 10703
Log:
Various option-related tweaks:
- Match the ordering of the non-tool-specific options in the usage message
with the order in the user manual. As a result, we now always print
--alignment and --trace-malloc in the core's usage messages, which saves
malloc-replacing tools from doing it themselves (and brings it in line
with options that only apply to error-collecting tools).
- Improved the presentation of the Vex options with --help-debug.
- Removed documentation of -d in the manual because it's a debugging-only flag.
- Documented --read-var-info in the manual. This fixes bug 201169.
- Renamed --auto-run-dsymutil as --dsymutil and documented it in the usage
message.
- Fixed an XML error in manual-core-adv.xml.
Added:
trunk/none/tests/filter_cmdline1
Modified:
trunk/NEWS
trunk/coregrind/m_debuginfo/readmacho.c
trunk/coregrind/m_main.c
trunk/coregrind/m_options.c
trunk/coregrind/m_replacemalloc/replacemalloc_core.c
trunk/coregrind/pub_core_options.h
trunk/docs/xml/manual-core-adv.xml
trunk/docs/xml/manual-core.xml
trunk/drd/drd_main.c
trunk/exp-ptrcheck/pc_common.c
trunk/helgrind/hg_main.c
trunk/include/pub_tool_replacemalloc.h
trunk/massif/ms_main.c
trunk/memcheck/mc_main.c
trunk/none/tests/Makefile.am
trunk/none/tests/cmdline1.stdout.exp
trunk/none/tests/cmdline1.vgtest
trunk/none/tests/cmdline2.stdout.exp
trunk/none/tests/cmdline2.vgtest
Modified: trunk/NEWS
===================================================================
--- trunk/NEWS 2009-08-04 01:16:57 UTC (rev 10702)
+++ trunk/NEWS 2009-08-04 02:32:55 UTC (rev 10703)
@@ -9,7 +9,8 @@
- AMD64 (a.k.a. x86-64) are supported, but not as well.
- Older PowerPC machines are not supported.
- It requires Mac OS X 10.5 Leopard or later. Porting to 10.4 is not
- planned because it would require work and 10.4 is only becoming less common.
+ planned because it would require work and 10.4 is only becoming less
+ common.
Things that don't work:
- Helgrind and Ptrcheck
@@ -25,6 +26,10 @@
Hijack's fault. See https://bugs.kde.org/show_bug.cgi?id=193917 for
details and a simple work-around.
+ Usage notes:
+ - You will likely find --dsymutil=yes a useful option, as error messages may
+ be imprecise without it.
+
Many thanks to Greg Parker for developing this port over several years.
* XXX: something about improved Wine support?
Modified: trunk/coregrind/m_debuginfo/readmacho.c
===================================================================
--- trunk/coregrind/m_debuginfo/readmacho.c 2009-08-04 01:16:57 UTC (rev 10702)
+++ trunk/coregrind/m_debuginfo/readmacho.c 2009-08-04 02:32:55 UTC (rev 10703)
@@ -917,8 +917,8 @@
}
/* There was no dsym file, or it doesn't match. We'll have to try
- regenerating it, unless auto-run-dsymutil is disabled, in which
- case just complain instead. */
+ regenerating it, unless --dsymutil=no, in which case just complain
+ instead. */
/* If this looks like a lib that we shouldn't run dsymutil on, just
give up. (possible reasons: is system lib, or in /usr etc, or
@@ -928,13 +928,13 @@
if (is_systemish_library_name(di->filename))
goto success;
- if (!VG_(clo_auto_run_dsymutil)) {
+ if (!VG_(clo_dsymutil)) {
if (VG_(clo_verbosity) == 1) {
VG_(message)(Vg_DebugMsg, "%s:\n", di->filename);
}
if (VG_(clo_verbosity) > 0)
VG_(message)(Vg_DebugMsg, "%sdSYM directory %s; consider using "
- "--auto-run-dsymutil=yes\n",
+ "--dsymutil=yes\n",
VG_(clo_verbosity) > 1 ? " " : "",
dsymfilename ? "has wrong UUID" : "is missing");
goto success;
Modified: trunk/coregrind/m_main.c
===================================================================
--- trunk/coregrind/m_main.c 2009-08-04 01:16:57 UTC (rev 10702)
+++ trunk/coregrind/m_main.c 2009-08-04 02:32:55 UTC (rev 10703)
@@ -111,35 +111,23 @@
Char* usage1 =
"usage: valgrind [options] prog-and-args\n"
"\n"
-" common user options for all Valgrind tools, with defaults in [ ]:\n"
+" tool-selection option, with default in [ ]:\n"
" --tool=<name> use the Valgrind tool named <name> [memcheck]\n"
+"\n"
+" basic user options for all Valgrind tools, with defaults in [ ]:\n"
" -h --help show this message\n"
" --help-debug show this message, plus debugging options\n"
" --version show version\n"
" -q --quiet run silently; only print error msgs\n"
" -v --verbose be more verbose, incl counts of errors\n"
" --trace-children=no|yes Valgrind-ise child processes (follow execve)? [no]\n"
-" --child-silent-after-fork=no|yes omit child output between fork & exec? [no]\n"
+" --child-silent-after-fork=no|yes omit child output between fork & exec? [no]\n"
" --track-fds=no|yes track open file descriptors? [no]\n"
" --time-stamp=no|yes add timestamps to log messages? [no]\n"
" --log-fd=<number> log messages to file descriptor [2=stderr]\n"
" --log-file=<file> log messages to <file>\n"
" --log-socket=ipaddr:port log messages to socket ipaddr:port\n"
"\n"
-" uncommon user options for all Valgrind tools:\n"
-" --run-libc-freeres=no|yes free up glibc memory at exit? [yes]\n"
-" --sim-hints=hint1,hint2,... known hints:\n"
-" lax-ioctls, enable-outer [none]\n"
-" --show-emwarns=no|yes show warnings about emulation limits? [no]\n"
-" --smc-check=none|stack|all checks for self-modifying code: none,\n"
-" only for code found in stacks, or all [stack]\n"
-" --kernel-variant=variant1,variant2,... known variants: bproc [none]\n"
-" handle non-standard kernel variants\n"
-" --read-var-info=yes|no read debug info on stack and global variables\n"
-" and use it to print better error messages in\n"
-" tools that make use of it (Memcheck, Helgrind,\n"
-" DRD)\n"
-"\n"
" user options for Valgrind tools that report errors:\n"
" --xml=yes emit error output in XML (some tools only)\n"
" --xml-fd=<number> XML output to file descriptor\n"
@@ -156,15 +144,34 @@
" --db-attach=no|yes start debugger when errors detected? [no]\n"
" --db-command=<command> command to start debugger [%s -nw %%f %%p]\n"
" --input-fd=<number> file descriptor for input [0=stdin]\n"
+" --dsymutil=no|yes run dsymutil on Mac OS X when helpful? [no]\n"
" --max-stackframe=<number> assume stack switch for SP changes larger\n"
" than <number> bytes [2000000]\n"
" --main-stacksize=<number> set size of main thread's stack (in bytes)\n"
" [use current 'ulimit' value]\n"
+"\n"
+" user options for Valgrind tools that replace malloc:\n"
+" --alignment=<number> set minimum alignment of heap allocations [%ld]\n"
+"\n"
+" uncommon user options for all Valgrind tools:\n"
+" --smc-check=none|stack|all checks for self-modifying code: none,\n"
+" only for code found in stacks, or all [stack]\n"
+" --read-var-info=yes|no read debug info on stack and global variables\n"
+" and use it to print better error messages in\n"
+" tools that make use of it (Memcheck, Helgrind,\n"
+" DRD)\n"
+" --run-libc-freeres=no|yes free up glibc memory at exit on Linux? [yes]\n"
+" --sim-hints=hint1,hint2,... known hints:\n"
+" lax-ioctls, enable-outer [none]\n"
+" --kernel-variant=variant1,variant2,... known variants: bproc [none]\n"
+" handle non-standard kernel variants\n"
+" --show-emwarns=no|yes show warnings about emulation limits? [no]\n"
"\n";
Char* usage2 =
"\n"
" debugging options for all Valgrind tools:\n"
+" -d show verbose debugging output\n"
" --sanity-level=<number> level of sanity checking to do [1]\n"
" --trace-flags=<XXXXXXXX> show generated code? (X = 0|1) [00000000]\n"
" --profile-flags=<XXXXXXXX> ditto, but for profiling (X = 0|1) [00000000]\n"
@@ -184,13 +191,13 @@
" --sym-offsets=yes|no show syms in form 'name+offset' ? [no]\n"
" --command-line-only=no|yes only use command line options [no]\n"
"\n"
-" --vex-iropt-verbosity 0 .. 9 [0]\n"
-" --vex-iropt-level 0 .. 2 [2]\n"
-" --vex-iropt-precise-memory-exns [no]\n"
-" --vex-iropt-unroll-thresh 0 .. 400 [120]\n"
-" --vex-guest-max-insns 1 .. 100 [50]\n"
-" --vex-guest-chase-thresh 0 .. 99 [10]\n"
-"\n"
+" Vex options for all Valgrind tools:\n"
+" --vex-iropt-verbosity=<0..9> [0]\n"
+" --vex-iropt-level=<0..2> [2]\n"
+" --vex-iropt-precise-memory-exns=no|yes [no]\n"
+" --vex-iropt-unroll-thresh=<0..400> [120]\n"
+" --vex-guest-max-insns=<1..100> [50]\n"
+" --vex-guest-chase-thresh=<0..99> [10]\n"
" --trace-flags and --profile-flags values (omit the middle space):\n"
" 1000 0000 show conversion into IR\n"
" 0100 0000 show after initial opt\n"
@@ -205,6 +212,9 @@
" debugging options for Valgrind tools that report errors\n"
" --dump-error=<number> show translation for basic block associated\n"
" with <number>'th error context [0=show none]\n"
+"\n"
+" debugging options for Valgrind tools that replace malloc:\n"
+" --trace-malloc=no|yes show client malloc details? [no]\n"
"\n";
Char* usage3 =
@@ -224,8 +234,8 @@
VG_(log_output_sink).fd = 1;
VG_(log_output_sink).is_socket = False;
- /* 'usage1' expects one char* argument */
- VG_(printf)(usage1, gdb_path);
+ /* 'usage1' expects one char* argument and one SizeT argument. */
+ VG_(printf)(usage1, gdb_path, VG_MIN_MALLOC_SZB);
if (VG_(details).name) {
VG_(printf)(" user options for %s:\n", VG_(details).name);
if (VG_(needs).command_line_options)
@@ -474,10 +484,9 @@
else if VG_XACT_CLO(arg, "--smc-check=all", VG_(clo_smc_check),
Vg_SmcAll);
- else if VG_STR_CLO (arg, "--kernel-variant", VG_(clo_kernel_variant)) {}
+ else if VG_STR_CLO (arg, "--kernel-variant", VG_(clo_kernel_variant)) {}
- else if VG_BOOL_CLO(arg, "--auto-run-dsymutil",
- VG_(clo_auto_run_dsymutil)) {}
+ else if VG_BOOL_CLO(arg, "--dsymutil", VG_(clo_dsymutil)) {}
else if VG_BINT_CLO(arg, "--vex-iropt-verbosity",
VG_(clo_vex_control).iropt_verbosity, 0, 10) {}
Modified: trunk/coregrind/m_options.c
===================================================================
--- trunk/coregrind/m_options.c 2009-08-04 01:16:57 UTC (rev 10702)
+++ trunk/coregrind/m_options.c 2009-08-04 02:32:55 UTC (rev 10703)
@@ -90,7 +90,7 @@
Bool VG_(clo_wait_for_gdb) = False;
VgSmc VG_(clo_smc_check) = Vg_SmcStack;
HChar* VG_(clo_kernel_variant) = NULL;
-Bool VG_(clo_auto_run_dsymutil) = False;
+Bool VG_(clo_dsymutil) = False;
/*====================================================================*/
Modified: trunk/coregrind/m_replacemalloc/replacemalloc_core.c
===================================================================
--- trunk/coregrind/m_replacemalloc/replacemalloc_core.c 2009-08-04 01:16:57 UTC (rev 10702)
+++ trunk/coregrind/m_replacemalloc/replacemalloc_core.c 2009-08-04 02:32:55 UTC (rev 10703)
@@ -74,21 +74,6 @@
return True;
}
-void VG_(replacement_malloc_print_usage)(void)
-{
- VG_(printf)(
-" --alignment=<number> set minimum alignment of allocations [%d]\n",
- VG_MIN_MALLOC_SZB
- );
-}
-
-void VG_(replacement_malloc_print_debug_usage)(void)
-{
- VG_(printf)(
-" --trace-malloc=no|yes show client malloc details? [no]\n"
- );
-}
-
/*------------------------------------------------------------*/
/*--- Useful functions ---*/
/*------------------------------------------------------------*/
Modified: trunk/coregrind/pub_core_options.h
===================================================================
--- trunk/coregrind/pub_core_options.h 2009-08-04 01:16:57 UTC (rev 10702)
+++ trunk/coregrind/pub_core_options.h 2009-08-04 02:32:55 UTC (rev 10703)
@@ -168,7 +168,7 @@
/* Darwin-specific: automatically run /usr/bin/dsymutil to update
.dSYM directories as necessary? */
-extern Bool VG_(clo_auto_run_dsymutil);
+extern Bool VG_(clo_dsymutil);
/* --------- Functions --------- */
Modified: trunk/docs/xml/manual-core-adv.xml
===================================================================
--- trunk/docs/xml/manual-core-adv.xml 2009-08-04 01:16:57 UTC (rev 10702)
+++ trunk/docs/xml/manual-core-adv.xml 2009-08-04 02:32:55 UTC (rev 10703)
@@ -228,7 +228,7 @@
<varlistentry>
<term><command><computeroutput>VALGRIND_PRINTF_BACKTRACE(format, ...)</computeroutput>:</command></term>
<listitem>
- <para>Like <computeroutput>VALGRIND_PRINTF<computeroutput>, but prints
+ <para>Like <computeroutput>VALGRIND_PRINTF</computeroutput>, but prints
a stack backtrace immediately afterwards.</para>
</listitem>
</varlistentry>
Modified: trunk/docs/xml/manual-core.xml
===================================================================
--- trunk/docs/xml/manual-core.xml 2009-08-04 01:16:57 UTC (rev 10702)
+++ trunk/docs/xml/manual-core.xml 2009-08-04 02:32:55 UTC (rev 10703)
@@ -641,18 +641,6 @@
</listitem>
</varlistentry>
- <varlistentry id="opt.d" xreflabel="-d">
- <term><option>-d</option></term>
- <listitem>
- <para>Emit information for debugging Valgrind itself. This is
- usually only of interest to the Valgrind developers. Repeating
- the flag produces more detailed output. If you want to send us a
- bug report, a log of the output generated by
- <option>-v -v -d -d</option> will make your report more
- useful.</para>
- </listitem>
- </varlistentry>
-
<varlistentry id="opt.trace-children" xreflabel="--trace-children">
<term>
<option><![CDATA[--trace-children=<yes|no> [default: no] ]]></option>
@@ -1108,9 +1096,9 @@
</listitem>
</varlistentry>
- <varlistentry id="opt.auto-run-dsymutil" xreflabel="--auto-run-dsymutil">
+ <varlistentry id="opt.dsymutil" xreflabel="--dsymutil">
<term>
- <option><![CDATA[--auto-run-dsymutil=no|yes [no] ]]></option>
+ <option><![CDATA[--dsymutil=no|yes [no] ]]></option>
</term>
<listitem>
<para>This flag is only relevant when running Valgrind on
@@ -1128,7 +1116,7 @@
executable or <computeroutput>.dylib</computeroutput>, but with
the extension <computeroutput>.dSYM</computeroutput>.</para>
- <para>With <option>--auto-run-dsymutil=no</option>, Valgrind
+ <para>With <option>--dsymutil=no</option>, Valgrind
will detect cases where the
<computeroutput>.dSYM</computeroutput> directory is either
missing, or is present but does not appear to match the
@@ -1136,11 +1124,11 @@
most likely because it is out of date. In these cases, Valgrind
will print a warning message but take no further action.</para>
- <para>With <option>--auto-run-dsymutil=yes</option>, Valgrind
+ <para>With <option>--dsymutil=yes</option>, Valgrind
will, in such cases, automatically
run <computeroutput>dsymutil</computeroutput> as necessary to
bring the debuginfo up to date. For all practical purposes, if
- you always use <option>--auto-run-dsymutil=yes</option>, then
+ you always use <option>--dsymutil=yes</option>, then
there is never any need to
run <computeroutput>dsymutil</computeroutput> manually or as part
of your applications's build system, since Valgrind will run it
@@ -1164,7 +1152,7 @@
directories.</para>
<para>Be careful when
- using <option>--auto-run-dsymutil=yes</option>, since it will
+ using <option>--dsymutil=yes</option>, since it will
cause pre-existing <computeroutput>.dSYM</computeroutput>
directories to be silently deleted and re-created. Also note the
<computeroutput>dsymutil</computeroutput> is quite slow, sometimes
@@ -1309,6 +1297,82 @@
<variablelist id="uncommon.opts.list">
+ <varlistentry id="opt.smc-check" xreflabel="--smc-check">
+ <term>
+ <option><![CDATA[--smc-check=<none|stack|all> [default: stack] ]]></option>
+ </term>
+ <listitem>
+ <para>This option controls Valgrind's detection of self-modifying
+ code. If no checking is done, if a program executes some code, then
+ overwrites it with new code, and executes the new code, Valgrind will
+ continue to execute the translations it made for the old code. This
+ will likely lead to incorrect behaviour and/or crashes.</para>
+
+ <para>Valgrind has three levels of self-modifying code detection:
+ no detection, detect self-modifying code on the stack (which used by
+ GCC to implement nested functions), or detect self-modifying code
+ everywhere. Note that the default option will catch the vast majority
+ of cases. The main case it will not catch is programs such as JIT
+ compilers that dynamically generate code <emphasis>and</emphasis>
+ subsequently overwrite part or all of it. Running with
+ <varname>all</varname> will slow Valgrind down greatly. Running with
+ <varname>none</varname> will rarely speed things up, since very little
+ code gets put on the stack for most programs. The
+ <function>VALGRIND_DISCARD_TRANSLATIONS</function> client request is
+ an alternative to <option>--smc-check=all</option> that requires more
+ effort but is much faster; see <xref
+ linkend="manual-core-adv.clientreq"/> for more details.</para>
+
+ <para>Some architectures (including ppc32 and ppc64) require
+ programs which create code at runtime to flush the instruction
+ cache in between code generation and first use. Valgrind
+ observes and honours such instructions. Hence, on ppc32/Linux
+ and ppc64/Linux, Valgrind always provides complete, transparent
+ support for self-modifying code. It is only on platforms such as
+ x86/Linux, AMD64/Linux and x86/Darwin that you need to use this
+ flag.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="opt.read-var-info" xreflabel="--read-var-info">
+ <term>
+ <option><![CDATA[--read-var-info=<yes|no> [default: no] ]]></option>
+ </term>
+ <listitem>
+ <para>When enabled, Valgrind will read information about variables from
+ debug info. This slows Valgrind down and makes it use more memory, but
+ for the tools that can take advantage of it (Memcheck, Helgrind, DRD) it
+ can result in more precise error messages. For example, here are some
+ standard errors issued by Memcheck:</para>
+<programlisting><![CDATA[
+==15516== Uninitialised byte(s) found during client check request
+==15516== at 0x400633: croak (varinfo1.c:28)
+==15516== by 0x4006B2: main (varinfo1.c:55)
+==15516== Address 0x60103b is 7 bytes inside data symbol "global_i2"
+==15516==
+==15516== Uninitialised byte(s) found during client check request
+==15516== at 0x400633: croak (varinfo1.c:28)
+==15516== by 0x4006BC: main (varinfo1.c:56)
+==15516== Address 0x7fefffefc is on thread 1's stack]]></programlisting>
+
+ <para>And here are the same errors with
+ <option>--read-var-info=yes</option>:</para>
+
+<programlisting><![CDATA[
+==15522== Uninitialised byte(s) found during client check request
+==15522== at 0x400633: croak (varinfo1.c:28)
+==15522== by 0x4006B2: main (varinfo1.c:55)
+==15522== Location 0x60103b is 0 bytes inside global_i2[7],
+==15522== a global variable declared at varinfo1.c:41
+==15522==
+==15522== Uninitialised byte(s) found during client check request
+==15522== at 0x400633: croak (varinfo1.c:28)
+==15522== by 0x4006BC: main (varinfo1.c:56)
+==15522== Location 0x7fefffefc is 0 bytes inside local var "local"
+==15522== declared at varinfo1.c:46, in frame #1 of thread 1]]></programlisting>
+ </listitem>
+ </varlistentry>
+
<varlistentry id="opt.run-libc-freeres" xreflabel="--run-libc-freeres">
<term>
<option><![CDATA[--run-libc-freeres=<yes|no> [default: yes] ]]></option>
@@ -1403,43 +1467,6 @@
</listitem>
</varlistentry>
- <varlistentry id="opt.smc-check" xreflabel="--smc-check">
- <term>
- <option><![CDATA[--smc-check=<none|stack|all> [default: stack] ]]></option>
- </term>
- <listitem>
- <para>This option controls Valgrind's detection of self-modifying
- code. If no checking is done, if a program executes some code, then
- overwrites it with new code, and executes the new code, Valgrind will
- continue to execute the translations it made for the old code. This
- will likely lead to incorrect behaviour and/or crashes.</para>
-
- <para>Valgrind has three levels of self-modifying code detection:
- no detection, detect self-modifying code on the stack (which used by
- GCC to implement nested functions), or detect self-modifying code
- everywhere. Note that the default option will catch the vast majority
- of cases. The main case it will not catch is programs such as JIT
- compilers that dynamically generate code <emphasis>and</emphasis>
- subsequently overwrite part or all of it. Running with
- <varname>all</varname> will slow Valgrind down greatly. Running with
- <varname>none</varname> will rarely speed things up, since very little
- code gets put on the stack for most programs. The
- <function>VALGRIND_DISCARD_TRANSLATIONS</function> client request is
- an alternative to <option>--smc-check=all</option> that requires more
- effort but is much faster; see <xref
- linkend="manual-core-adv.clientreq"/> for more details.</para>
-
- <para>Some architectures (including ppc32 and ppc64) require
- programs which create code at runtime to flush the instruction
- cache in between code generation and first use. Valgrind
- observes and honours such instructions. Hence, on ppc32/Linux
- and ppc64/Linux, Valgrind always provides complete, transparent
- support for self-modifying code. It is only on platforms such as
- x86/Linux, AMD64/Linux and x86/Darwin that you need to use this
- flag.</para>
- </listitem>
- </varlistentry>
-
</variablelist>
<!-- end of xi:include in the manpage -->
Modified: trunk/drd/drd_main.c
===================================================================
--- trunk/drd/drd_main.c 2009-08-04 01:16:57 UTC (rev 10702)
+++ trunk/drd/drd_main.c 2009-08-04 02:32:55 UTC (rev 10703)
@@ -211,7 +211,6 @@
" --trace-semaphore=yes|no Trace all semaphore activity [no].\n",
DRD_(thread_get_segment_merge_interval)()
);
- VG_(replacement_malloc_print_usage)();
}
static void DRD_(print_debug_usage)(void)
@@ -227,7 +226,6 @@
" --trace-segment=yes|no Trace segment actions [no].\n"
" --trace-suppr=yes|no Trace all address suppression actions [no].\n"
);
- VG_(replacement_malloc_print_debug_usage)();
}
Modified: trunk/exp-ptrcheck/pc_common.c
===================================================================
--- trunk/exp-ptrcheck/pc_common.c 2009-08-04 01:16:57 UTC (rev 10702)
+++ trunk/exp-ptrcheck/pc_common.c 2009-08-04 02:32:55 UTC (rev 10703)
@@ -80,17 +80,14 @@
" --partial-loads-ok=no|yes same as for Memcheck [yes]\n"
" --enable-sg-checks=no|yes enable stack & global array checking? [yes]\n"
);
- VG_(replacement_malloc_print_usage)();
}
void pc_print_debug_usage(void)
{
- /*
VG_(printf)(
- " --lossage-check=no|yes gather stats for quality control [no]\n"
+" (none)\n"
+//" --lossage-check=no|yes gather stats for quality control [no]\n"
);
- */
- VG_(replacement_malloc_print_debug_usage)();
}
Modified: trunk/helgrind/hg_main.c
===================================================================
--- trunk/helgrind/hg_main.c 2009-08-04 01:16:57 UTC (rev 10702)
+++ trunk/helgrind/hg_main.c 2009-08-04 02:32:55 UTC (rev 10703)
@@ -4216,12 +4216,10 @@
" none: only show trace for one thread in a race (fastest)\n"
" --conflict-cache-size=N size of 'full' history cache [1000000]\n"
);
- VG_(replacement_malloc_print_usage)();
}
static void hg_print_debug_usage ( void )
{
- VG_(replacement_malloc_print_debug_usage)();
VG_(printf)(" --cmp-race-err-addrs=no|yes are data addresses in "
"race errors significant? [no]\n");
VG_(printf)(" --hg-sanity-flags=<XXXXXX> sanity check "
Modified: trunk/include/pub_tool_replacemalloc.h
===================================================================
--- trunk/include/pub_tool_replacemalloc.h 2009-08-04 01:16:57 UTC (rev 10702)
+++ trunk/include/pub_tool_replacemalloc.h 2009-08-04 02:32:55 UTC (rev 10703)
@@ -64,8 +64,6 @@
extern UInt VG_(clo_alignment);
extern Bool VG_(replacement_malloc_process_cmd_line_option) ( Char* arg );
-extern void VG_(replacement_malloc_print_usage) ( void );
-extern void VG_(replacement_malloc_print_debug_usage) ( void );
#endif // __PUB_TOOL_REPLACEMALLOC_H
Modified: trunk/massif/ms_main.c
===================================================================
--- trunk/massif/ms_main.c 2009-08-04 01:16:57 UTC (rev 10702)
+++ trunk/massif/ms_main.c 2009-08-04 02:32:55 UTC (rev 10703)
@@ -460,12 +460,13 @@
" --max-snapshots=<N> maximum number of snapshots recorded [100]\n"
" --massif-out-file=<file> output file name [massif.out.%%p]\n"
);
- VG_(replacement_malloc_print_usage)();
}
static void ms_print_debug_usage(void)
{
- VG_(replacement_malloc_print_debug_usage)();
+ VG_(printf)(
+" (none)\n"
+ );
}
Modified: trunk/memcheck/mc_main.c
===================================================================
--- trunk/memcheck/mc_main.c 2009-08-04 01:16:57 UTC (rev 10702)
+++ trunk/memcheck/mc_main.c 2009-08-04 02:32:55 UTC (rev 10703)
@@ -4785,12 +4785,13 @@
" --malloc-fill=<hexnumber> fill malloc'd areas with given value\n"
" --free-fill=<hexnumber> fill free'd areas with given value\n"
);
- VG_(replacement_malloc_print_usage)();
}
static void mc_print_debug_usage(void)
{
- VG_(replacement_malloc_print_debug_usage)();
+ VG_(printf)(
+" (none)\n"
+ );
}
Modified: trunk/none/tests/Makefile.am
===================================================================
--- trunk/none/tests/Makefile.am 2009-08-04 01:16:57 UTC (rev 10702)
+++ trunk/none/tests/Makefile.am 2009-08-04 02:32:55 UTC (rev 10703)
@@ -34,6 +34,7 @@
dist_noinst_SCRIPTS = \
filter_cmdline0 \
+ filter_cmdline1 \
filter_fdleak \
filter_linenos \
filter_none_discards \
Modified: trunk/none/tests/cmdline1.stdout.exp
===================================================================
--- trunk/none/tests/cmdline1.stdout.exp 2009-08-04 01:16:57 UTC (rev 10702)
+++ trunk/none/tests/cmdline1.stdout.exp 2009-08-04 02:32:55 UTC (rev 10703)
@@ -1,34 +1,22 @@
usage: valgrind [options] prog-and-args
- common user options for all Valgrind tools, with defaults in [ ]:
+ tool-selection option, with default in [ ]:
--tool=<name> use the Valgrind tool named <name> [memcheck]
+
+ basic user options for all Valgrind tools, with defaults in [ ]:
-h --help show this message
--help-debug show this message, plus debugging options
--version show version
-q --quiet run silently; only print error msgs
-v --verbose be more verbose, incl counts of errors
--trace-children=no|yes Valgrind-ise child processes (follow execve)? [no]
- --child-silent-after-fork=no|yes omit child output between fork & exec? [no]
+ --child-silent-after-fork=no|yes omit child output between fork & exec? [no]
--track-fds=no|yes track open file descriptors? [no]
--time-stamp=no|yes add timestamps to log messages? [no]
--log-fd=<number> log messages to file descriptor [2=stderr]
--log-file=<file> log messages to <file>
--log-socket=ipaddr:port log messages to socket ipaddr:port
- uncommon user options for all Valgrind tools:
- --run-libc-freeres=no|yes free up glibc memory at exit? [yes]
- --sim-hints=hint1,hint2,... known hints:
- lax-ioctls, enable-outer [none]
- --show-emwarns=no|yes show warnings about emulation limits? [no]
- --smc-check=none|stack|all checks for self-modifying code: none,
- only for code found in stacks, or all [stack]
- --kernel-variant=variant1,variant2,... known variants: bproc [none]
- handle non-standard kernel variants
- --read-var-info=yes|no read debug info on stack and global variables
- and use it to print better error messages in
- tools that make use of it (Memcheck, Helgrind,
- DRD)
-
user options for Valgrind tools that report errors:
--xml=yes emit error output in XML (some tools only)
--xml-fd=<number> XML output to file descriptor
@@ -45,11 +33,29 @@
--db-attach=no|yes start debugger when errors detected? [no]
--db-command=<command> command to start debugger [/usr/bin/gdb -nw %f %p]
--input-fd=<number> file descriptor for input [0=stdin]
+ --dsymutil=no|yes run dsymutil on Mac OS X when helpful? [no]
--max-stackframe=<number> assume stack switch for SP changes larger
than <number> bytes [2000000]
--main-stacksize=<number> set size of main thread's stack (in bytes)
[use current 'ulimit' value]
+ user options for Valgrind tools that replace malloc:
+ --alignment=<number> set minimum alignment of heap allocations [...]
+
+ uncommon user options for all Valgrind tools:
+ --smc-check=none|stack|all checks for self-modifying code: none,
+ only for code found in stacks, or all [stack]
+ --read-var-info=yes|no read debug info on stack and global variables
+ and use it to print better error messages in
+ tools that make use of it (Memcheck, Helgrind,
+ DRD)
+ --run-libc-freeres=no|yes free up glibc memory at exit on Linux? [yes]
+ --sim-hints=hint1,hint2,... known hints:
+ lax-ioctls, enable-outer [none]
+ --kernel-variant=variant1,variant2,... known variants: bproc [none]
+ handle non-standard kernel variants
+ --show-emwarns=no|yes show warnings about emulation limits? [no]
+
user options for Nulgrind:
(none)
Modified: trunk/none/tests/cmdline1.vgtest
===================================================================
--- trunk/none/tests/cmdline1.vgtest 2009-08-04 01:16:57 UTC (rev 10702)
+++ trunk/none/tests/cmdline1.vgtest 2009-08-04 02:32:55 UTC (rev 10703)
@@ -1 +1,2 @@
vgopts: --help --tool=none
+stdout_filter: filter_cmdline1
Modified: trunk/none/tests/cmdline2.stdout.exp
===================================================================
--- trunk/none/tests/cmdline2.stdout.exp 2009-08-04 01:16:57 UTC (rev 10702)
+++ trunk/none/tests/cmdline2.stdout.exp 2009-08-04 02:32:55 UTC (rev 10703)
@@ -1,34 +1,22 @@
usage: valgrind [options] prog-and-args
- common user options for all Valgrind tools, with defaults in [ ]:
+ tool-selection option, with default in [ ]:
--tool=<name> use the Valgrind tool named <name> [memcheck]
+
+ basic user options for all Valgrind tools, with defaults in [ ]:
-h --help show this message
--help-debug show this message, plus debugging options
--version show version
-q --quiet run silently; only print error msgs
-v --verbose be more verbose, incl counts of errors
--trace-children=no|yes Valgrind-ise child processes (follow execve)? [no]
- --child-silent-after-fork=no|yes omit child output between fork & exec? [no]
+ --child-silent-after-fork=no|yes omit child output between fork & exec? [no]
--track-fds=no|yes track open file descriptors? [no]
--time-stamp=no|yes add timestamps to log messages? [no]
--log-fd=<number> log messages to file descriptor [2=stderr]
--log-file=<file> log messages to <file>
--log-socket=ipaddr:port log messages to socket ipaddr:port
- uncommon user options for all Valgrind tools:
- --run-libc-freeres=no|yes free up glibc memory at exit? [yes]
- --sim-hints=hint1,hint2,... known hints:
- lax-ioctls, enable-outer [none]
- --show-emwarns=no|yes show warnings about emulation limits? [no]
- --smc-check=none|stack|all checks for self-modifying code: none,
- only for code found in stacks, or all [stack]
- --kernel-variant=variant1,variant2,... known variants: bproc [none]
- handle non-standard kernel variants
- --read-var-info=yes|no read debug info on stack and global variables
- and use it to print better error messages in
- tools that make use of it (Memcheck, Helgrind,
- DRD)
-
user options for Valgrind tools that report errors:
--xml=yes emit error output in XML (some tools only)
--xml-fd=<number> XML output to file descriptor
@@ -45,15 +33,34 @@
--db-attach=no|yes start debugger when errors detected? [no]
--db-command=<command> command to start debugger [/usr/bin/gdb -nw %f %p]
--input-fd=<number> file descriptor for input [0=stdin]
+ --dsymutil=no|yes run dsymutil on Mac OS X when helpful? [no]
--max-stackframe=<number> assume stack switch for SP changes larger
than <number> bytes [2000000]
--main-stacksize=<number> set size of main thread's stack (in bytes)
[use current 'ulimit' value]
+ user options for Valgrind tools that replace malloc:
+ --alignment=<number> set minimum alignment of heap allocations [...]
+
+ uncommon user options for all Valgrind tools:
+ --smc-check=none|stack|all checks for self-modifying code: none,
+ only for code found in stacks, or all [stack]
+ --read-var-info=yes|no read debug info on stack and global variables
+ and use it to print better error messages in
+ tools that make use of it (Memcheck, Helgrind,
+ DRD)
+ --run-libc-freeres=no|yes free up glibc memory at exit on Linux? [yes]
+ --sim-hints=hint1,hint2,... known hints:
+ lax-ioctls, enable-outer [none]
+ --kernel-variant=variant1,variant2,... known variants: bproc [none]
+ handle non-standard kernel variants
+ --show-emwarns=no|yes show warnings about emulation limits? [no]
+
user options for Nulgrind:
(none)
debugging options for all Valgrind tools:
+ -d show verbose debugging output
--sanity-level=<number> level of sanity checking to do [1]
--trace-flags=<XXXXXXXX> show generated code? (X = 0|1) [00000000]
--profile-flags=<XXXXXXXX> ditto, but for profiling (X = 0|1) [00000000]
@@ -73,13 +80,13 @@
--sym-offsets=yes|no show syms in form 'name+offset' ? [no]
--command-line-only=no|yes only use command line options [no]
- --vex-iropt-verbosity 0 .. 9 [0]
- --vex-iropt-level 0 .. 2 [2]
- --vex-iropt-precise-memory-exns [no]
- --vex-iropt-unroll-thresh 0 .. 400 [120]
- --vex-guest-max-insns 1 .. 100 [50]
- --vex-guest-chase-thresh 0 .. 99 [10]
-
+ Vex options for all Valgrind tools:
+ --vex-iropt-verbosity=<0..9> [0]
+ --vex-iropt-level=<0..2> [2]
+ --vex-iropt-precise-memory-exns=no|yes [no]
+ --vex-iropt-unroll-thresh=<0..400> [120]
+ --vex-guest-max-insns=<1..100> [50]
+ --vex-guest-chase-thresh=<0..99> [10]
--trace-flags and --profile-flags values (omit the middle space):
1000 0000 show conversion into IR
0100 0000 show after initial opt
@@ -95,6 +102,9 @@
--dump-error=<number> show translation for basic block associated
with <number>'th error context [0=show none]
+ debugging options for Valgrind tools that replace malloc:
+ --trace-malloc=no|yes show client malloc details? [no]
+
debugging options for Nulgrind:
(none)
Modified: trunk/none/tests/cmdline2.vgtest
===================================================================
--- trunk/none/tests/cmdline2.vgtest 2009-08-04 01:16:57 UTC (rev 10702)
+++ trunk/none/tests/cmdline2.vgtest 2009-08-04 02:32:55 UTC (rev 10703)
@@ -1 +1,2 @@
vgopts: --help-debug --tool=none
+stdout_filter: filter_cmdline1
Added: trunk/none/tests/filter_cmdline1
===================================================================
--- trunk/none/tests/filter_cmdline1 (rev 0)
+++ trunk/none/tests/filter_cmdline1 2009-08-04 02:32:55 UTC (rev 10703)
@@ -0,0 +1,4 @@
+#! /bin/sh
+
+perl -p -e 's/(set minimum alignment of heap allocations) \[(8|16)\]/$1 [...]/'
+
Property changes on: trunk/none/tests/filter_cmdline1
___________________________________________________________________
Name: svn:executable
+ *
|
|
From: Tom H. <th...@cy...> - 2009-08-04 02:30:58
|
Nightly build on mg ( x86_64, Fedora 9 ) Started at 2009-08-04 03:10:04 BST Ended at 2009-08-04 03:30:38 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 527 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 528 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Tue Aug 4 03:20:25 2009 --- new.short Tue Aug 4 03:30:38 2009 *************** *** 8,10 **** ! == 528 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) --- 8,10 ---- ! == 527 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |
|
From: Ayan C. <ach...@vm...> - 2009-08-04 01:50:23
|
Anyone has any idea on this? I needed it badly :-( _____________________________________________ From: Ayan Chowdhury Sent: Monday, August 03, 2009 1:50 PM To: 'val...@li...' Subject: A urgent help needed Hi, I was trying to get my application up with valgrind. I was using the following valgrind options. "/root/valgrind341/bin/valgrind --trace-children=yes --track-fds=yes --log-file=/var/log/vmware/aam/valgrind.out.%p --leak-check=yes --show-reachable=yes --leak-resolution=high --num-callers=40 But getting the following error when getting the program running. valgrind: mmap(0x38000000, 1503232) failed in UME with error 22 (Invalid argument). valgrind: this can be caused by executables with very large text, data or bss segments. Any idea how to work around the problem. Any help will be appreciated. Thanks, Ayan |
|
From: Nicholas N. <n.n...@gm...> - 2009-08-04 01:19:04
|
On Tue, Aug 4, 2009 at 6:50 AM, Ayan Chowdhury<ach...@vm...> wrote: > Hi, > > I was trying to get my application up with valgrind. I was using the > following valgrind options. > > "/root/valgrind341/bin/valgrind --trace-children=yes --track-fds=yes > --log-file=/var/log/vmware/aam/valgrind.out.%p --leak-check=yes > --show-reachable=yes --leak-resolution=high --num-callers=40 > > But getting the following error when getting the program running. > > > valgrind: mmap(0x38000000, 1503232) failed in UME with error 22 (Invalid > argument). > valgrind: this can be caused by executables with very large text, data or > bss segments. Does your program have a very large text, data or bss segment? Eg. does it contain any very large static arrays? If you give the output of "valgrind -d -v" that would be helpful. Nick |
|
From: <sv...@va...> - 2009-08-04 01:17:11
|
Author: njn
Date: 2009-08-04 02:16:57 +0100 (Tue, 04 Aug 2009)
New Revision: 10702
Log:
This wasn't supposed to be part of r10701.
Modified:
trunk/docs/xml/FAQ.xml
Modified: trunk/docs/xml/FAQ.xml
===================================================================
--- trunk/docs/xml/FAQ.xml 2009-08-04 01:16:01 UTC (rev 10701)
+++ trunk/docs/xml/FAQ.xml 2009-08-04 01:16:57 UTC (rev 10702)
@@ -182,29 +182,6 @@
</answer>
</qandaentry>
-<qandaentry id="faq.bss">
- <question id="q-bss">
- <para>My program fails to start, and this message is printed:</para>
-<screen></screen>
- </question>
- <answer id="a-bss">
- <para>One possibility is that your program has a bug and erroneously
- jumps to a non-code address, in which case you'll get a SIGILL signal.
- Memcheck may issue a warning just before this happens, but it might not
- if the jump happens to land in addressable memory.</para>
-
- <para>Another possibility is that Valgrind does not handle the
- instruction. If you are using an older Valgrind, a newer version might
- handle the instruction. However, all instruction sets have some
- obscure, rarely used instructions. Also, on amd64 there are an almost
- limitless number of combinations of redundant instruction prefixes, many
- of them undocumented but accepted by CPUs. So Valgrind will still have
- decoding failures from time to time. If this happens, please file a bug
- report.</para>
-
- </answer>
-</qandaentry>
-
<qandaentry id="faq.java">
<question id="q-java">
<para>I tried running a Java program (or another program that uses a
|
|
From: <sv...@va...> - 2009-08-04 01:16:13
|
Author: njn
Date: 2009-08-04 02:16:01 +0100 (Tue, 04 Aug 2009)
New Revision: 10701
Log:
Various manual fix-ups:
- Use "heap blocks" rather than "malloc'd blocks" as heap blocks covers
calloc, realloc, new, new[], memalign, etc.
- Used "GDB" and "GCC" throughout rather than "gcc" and "gdb".
- Made various tag uses more consistent.
- Greatly clarified the instructions on --xml=yes and its friends.
- Lots of other little improvements and fixes to out-of-date things and
Linux-centric things, mostly in Section 2.
Modified:
trunk/NEWS
trunk/cachegrind/docs/cg-manual.xml
trunk/docs/xml/FAQ.xml
trunk/docs/xml/manual-core.xml
trunk/docs/xml/manual-intro.xml
trunk/docs/xml/manual-writing-tools.xml
trunk/drd/docs/drd-manual.xml
trunk/helgrind/docs/hg-manual.xml
trunk/massif/docs/ms-manual.xml
trunk/memcheck/docs/mc-manual.xml
Modified: trunk/NEWS
===================================================================
--- trunk/NEWS 2009-08-04 01:08:56 UTC (rev 10700)
+++ trunk/NEWS 2009-08-04 01:16:01 UTC (rev 10701)
@@ -69,6 +69,8 @@
produced, but each leak report will describe fewer leaked blocks.
- The documentation for the leak checker has also been improved.
+* XXX: Atomic instructions are now handled properly...
+
* The format of some (non-XML) stack trace entries has changed a little.
Previously there were six possible forms:
Modified: trunk/cachegrind/docs/cg-manual.xml
===================================================================
--- trunk/cachegrind/docs/cg-manual.xml 2009-08-04 01:08:56 UTC (rev 10700)
+++ trunk/cachegrind/docs/cg-manual.xml 2009-08-04 01:16:01 UTC (rev 10701)
@@ -809,11 +809,10 @@
<para>To do this, you just need to assemble your
<computeroutput>.s</computeroutput> files with assembly-level debug
-information. You can use <computeroutput>gcc
--S</computeroutput> to compile C/C++ programs to assembly code, and then
-<computeroutput>gcc -g</computeroutput> on the assembly code files to
-achieve this. You can then profile and annotate the assembly code source
-files in the same way as C/C++ source files.</para>
+information. You can use compile with the <option>-S</option> to compile C/C++
+programs to assembly code, and then assemble the assembly code files with
+<option>-g</option> to achieve this. You can then profile and annotate the
+assembly code source files in the same way as C/C++ source files.</para>
</sect2>
@@ -1037,7 +1036,7 @@
the counts from each entry.</para>
<para>The reason for this is that although the debug info
- output by gcc indicates the switch from
+ output by GCC indicates the switch from
<filename>bar.c</filename> to <filename>foo.h</filename>, it
doesn't indicate the name of the function in
<filename>foo.h</filename>, so Valgrind keeps using the old
@@ -1065,8 +1064,8 @@
which case you'll get a warning message explaining that
annotations for the file might be incorrect.</para>
- <para>If you are using gcc 3.1 or later, this is most likely
- irrelevant, since gcc switched to using the more modern DWARF2
+ <para>If you are using GCC 3.1 or later, this is most likely
+ irrelevant, since GCC switched to using the more modern DWARF2
format by default at version 3.1. DWARF2 does not have any such
limitations on line numbers.</para>
</listitem>
Modified: trunk/docs/xml/FAQ.xml
===================================================================
--- trunk/docs/xml/FAQ.xml 2009-08-04 01:08:56 UTC (rev 10700)
+++ trunk/docs/xml/FAQ.xml 2009-08-04 01:16:01 UTC (rev 10701)
@@ -179,7 +179,29 @@
of them undocumented but accepted by CPUs. So Valgrind will still have
decoding failures from time to time. If this happens, please file a bug
report.</para>
+ </answer>
+</qandaentry>
+<qandaentry id="faq.bss">
+ <question id="q-bss">
+ <para>My program fails to start, and this message is printed:</para>
+<screen></screen>
+ </question>
+ <answer id="a-bss">
+ <para>One possibility is that your program has a bug and erroneously
+ jumps to a non-code address, in which case you'll get a SIGILL signal.
+ Memcheck may issue a warning just before this happens, but it might not
+ if the jump happens to land in addressable memory.</para>
+
+ <para>Another possibility is that Valgrind does not handle the
+ instruction. If you are using an older Valgrind, a newer version might
+ handle the instruction. However, all instruction sets have some
+ obscure, rarely used instructions. Also, on amd64 there are an almost
+ limitless number of combinations of redundant instruction prefixes, many
+ of them undocumented but accepted by CPUs. So Valgrind will still have
+ decoding failures from time to time. If this happens, please file a bug
+ report.</para>
+
</answer>
</qandaentry>
@@ -242,30 +264,30 @@
memory as still reachable. The behaviour not to free pools at the
exit() could be called a bug of the library though.</para>
- <para>Using gcc, you can force the STL to use malloc and to free
+ <para>Using GCC, you can force the STL to use malloc and to free
memory as soon as possible by globally disabling memory caching.
Beware! Doing so will probably slow down your program, sometimes
drastically.</para>
<itemizedlist>
<listitem>
- <para>With gcc 2.91, 2.95, 3.0 and 3.1, compile all source using
+ <para>With GCC 2.91, 2.95, 3.0 and 3.1, compile all source using
the STL with <literal>-D__USE_MALLOC</literal>. Beware! This was
- removed from gcc starting with version 3.3.</para>
+ removed from GCC starting with version 3.3.</para>
</listitem>
<listitem>
- <para>With gcc 3.2.2 and later, you should export the
+ <para>With GCC 3.2.2 and later, you should export the
environment variable <literal>GLIBCPP_FORCE_NEW</literal> before
running your program.</para>
</listitem>
<listitem>
- <para>With gcc 3.4 and later, that variable has changed name to
+ <para>With GCC 3.4 and later, that variable has changed name to
<literal>GLIBCXX_FORCE_NEW</literal>.</para>
</listitem>
</itemizedlist>
<para>There are other ways to disable memory pooling: using the
<literal>malloc_alloc</literal> template with your objects (not
- portable, but should work for gcc) or even writing your own memory
+ portable, but should work for GCC) or even writing your own memory
allocators. But all this goes beyond the scope of this FAQ. Start
by reading
<ulink
Modified: trunk/docs/xml/manual-core.xml
===================================================================
--- trunk/docs/xml/manual-core.xml 2009-08-04 01:08:56 UTC (rev 10700)
+++ trunk/docs/xml/manual-core.xml 2009-08-04 01:16:01 UTC (rev 10701)
@@ -26,19 +26,21 @@
<para>Valgrind is designed to be as non-intrusive as possible. It works
directly with existing executables. You don't need to recompile, relink,
-or otherwise modify, the program to be checked.</para>
+or otherwise modify the program to be checked.</para>
-<para>Simply put
-<computeroutput>valgrind --tool=tool_name</computeroutput>
-at the start of the command line normally used to run the program. For
-example, if want to run the command
-<computeroutput>ls -l</computeroutput> using the heavyweight
-memory-checking tool Memcheck, issue the command:</para>
+<para>You invoke Valgrind like this:</para>
+<programlisting><![CDATA[
+valgrind [valgrind-options] your-prog [your-prog-options]]]></programlisting>
+<para>The most important option is <option>--tool</option> which dictates
+which Valgrind tool to run. For example, if want to run the command
+<computeroutput>ls -l</computeroutput> using the memory-checking tool
+Memcheck, issue this command:</para>
+
<programlisting><![CDATA[
valgrind --tool=memcheck ls -l]]></programlisting>
-<para>Memcheck is the default, so if you want to use it you can
+<para>However, Memcheck is the default, so if you want to use it you can
omit the <option>--tool</option> flag.</para>
<para>Regardless of which tool is in use, Valgrind takes control of your
@@ -58,27 +60,23 @@
tools. At one end of the scale, Memcheck adds code to check every
memory access and every value computed,
making it run 10-50 times slower than natively.
-At the other end of the spectrum, the ultra-trivial "none" tool
-(also referred to as Nulgrind) adds no instrumentation at all
-and causes in total
-"only" about a 4 times slowdown.</para>
+At the other end of the spectrum, the minimal tool, called Nulgrind,
+adds no instrumentation at all and causes in total "only" about a 4 times
+slowdown.</para>
<para>Valgrind simulates every single instruction your program executes.
Because of this, the active tool checks, or profiles, not only the code
-in your application but also in all supporting dynamically-linked
-(<computeroutput>.so</computeroutput>-format) libraries, including the
-GNU C library, the X client libraries, Qt, if you work with KDE, and so
-on.</para>
+in your application but also in all supporting dynamically-linked libraries,
+including the C library, graphical libraries, and so on.</para>
<para>If you're using an error-detection tool, Valgrind may
-detect errors in libraries, for example the GNU C or X11
+detect errors in system libraries, for example the GNU C or X11
libraries, which you have to use. You might not be interested in these
errors, since you probably have no control over that code. Therefore,
Valgrind allows you to selectively suppress errors, by recording them in
a suppressions file which is read when Valgrind starts up. The build
-mechanism attempts to select suppressions which give reasonable
-behaviour for the C library
-and X11 client library versions detected on your machine.
+mechanism selects default suppressions which give reasonable
+behaviour for the OS and libraries detected on your machine.
To make it easier to write suppressions, you can use the
<option>--gen-suppressions=yes</option> option. This tells Valgrind to
print out a suppression for each reported error, which you can then
@@ -109,7 +107,7 @@
OpenOffice.org with Memcheck is a bit easier when using this flag. You
don't have to do this, but doing so helps Valgrind produce more accurate
and less confusing error reports. Chances are you're set up like this
-already, if you intended to debug your program with GNU gdb, or some
+already, if you intended to debug your program with GNU GDB, or some
other debugger.</para>
<para>If you are planning to use Memcheck: On rare
@@ -128,25 +126,24 @@
it can identify some or all of the problems that Valgrind can miss at the
higher optimisation levels. (Using <option>-Wall</option>
is also a good idea in general.) All other tools (as far as we know) are
-unaffected by optimisation level.</para>
+unaffected by optimisation level, and for profiling tools like Cachegrind it
+is better to compile your program at its normal optimisation level.</para>
<para>Valgrind understands both the older "stabs" debugging format, used
-by gcc versions prior to 3.1, and the newer DWARF2 and DWARF3 formats
-used by gcc
+by GCC versions prior to 3.1, and the newer DWARF2 and DWARF3 formats
+used by GCC
3.1 and later. We continue to develop our debug-info readers,
although the majority of effort will naturally enough go into the newer
DWARF2/3 reader.</para>
-<para>When you're ready to roll, just run your application as you
-would normally, but place
-<computeroutput>valgrind --tool=tool_name</computeroutput> in front of
-your usual command-line invocation. Note that you should run the real
+<para>When you're ready to roll, run Valgrind as described above.
+Note that you should run the real
(machine-code) executable here. If your application is started by, for
-example, a shell or perl script, you'll need to modify it to invoke
+example, a shell or Perl script, you'll need to modify it to invoke
Valgrind on the real executables. Running such scripts directly under
Valgrind will result in you getting error reports pertaining to
-<computeroutput>/bin/sh</computeroutput>,
-<computeroutput>/usr/bin/perl</computeroutput>, or whatever interpreter
+<filename>/bin/sh</filename>,
+<filename>/usr/bin/perl</filename>, or whatever interpreter
you're using. This may not be what you want and can be confusing. You
can force the issue by giving the flag
<option>--trace-children=yes</option>, but confusion is still
@@ -232,12 +229,13 @@
risk. It seems likely that people will write more sophisticated
listeners in the fullness of time.</para>
- <para>valgrind-listener can accept simultaneous connections from up
- to 50 Valgrinded processes. In front of each line of output it
- prints the current number of active connections in round
- brackets.</para>
+ <para><computeroutput>valgrind-listener</computeroutput> can accept
+ simultaneous connections from up to 50 Valgrinded processes. In front
+ of each line of output it prints the current number of active
+ connections in round brackets.</para>
- <para>valgrind-listener accepts two command-line flags:</para>
+ <para><computeroutput>valgrind-listener</computeroutput> accepts two
+ command-line flags:</para>
<itemizedlist>
<listitem>
<para><option>-e</option> or <option>--exit-at-zero</option>:
@@ -293,13 +291,13 @@
<para>This message says that the program did an illegal 4-byte read of
address 0xBFFFF74C, which, as far as Memcheck can tell, is not a valid
-stack address, nor corresponds to any current malloc'd or free'd
-blocks. The read is happening at line 45 of
+stack address, nor corresponds to any current heap blocks or recently freed
+heap blocks. The read is happening at line 45 of
<filename>bogon.cpp</filename>, called from line 66 of the same file,
-etc. For errors associated with an identified malloc'd/free'd block,
-for example reading free'd memory, Valgrind reports not only the
-location where the error happened, but also where the associated block
-was malloc'd/free'd.</para>
+etc. For errors associated with an identified (current or freed) heap block,
+for example reading freed memory, Valgrind reports not only the
+location where the error happened, but also where the associated heap block
+was allocated/freed.</para>
<para>Valgrind remembers all error reports. When an error is detected,
it is compared against old reports, to see if it is a duplicate. If so,
@@ -313,10 +311,9 @@
frequently.</para>
<para>Errors are reported before the associated operation actually
-happens. If you're using a tool (eg. Memcheck) which does
-address checking, and your program attempts to read from address zero,
-the tool will emit a message to this effect, and the program will then
-duly die with a segmentation fault.</para>
+happens. For example, if you're using Memcheck and your program attempts to
+read from address zero, Memcheck will emit a message to this effect, and
+your program will then likely die with a segmentation fault.</para>
<para>In general, you should try and fix errors in the order that they
are reported. Not doing so can be confusing. For example, a program
@@ -348,9 +345,9 @@
<sect1 id="manual-core.suppress" xreflabel="Suppressing errors">
<title>Suppressing errors</title>
-<para>The error-checking tools detect numerous problems in the base
-libraries, such as the GNU C library, and the X11 client libraries,
-which come pre-installed on your GNU/Linux system. You can't easily fix
+<para>The error-checking tools detect numerous problems in the system
+libraries, such as the C library,
+which come pre-installed with your OS. You can't easily fix
these, but you don't want to see these errors (and yes, there are many!)
So Valgrind reads a list of errors to suppress at startup. A default
suppression file is created by the
@@ -561,14 +558,8 @@
The tools also accept tool-specific flags, which are documented
separately for each tool.</para>
-<para>You invoke Valgrind like this:</para>
-
-<programlisting><![CDATA[
-valgrind [valgrind-options] your-prog [your-prog-options]]]></programlisting>
-
<para>Valgrind's default settings succeed in giving reasonable behaviour
-in most cases. We group the available options by rough
-categories.</para>
+in most cases. We group the available options by rough categories.</para>
<sect2 id="manual-core.toolopts" xreflabel="Tool-selection option">
<title>Tool-selection option</title>
@@ -579,10 +570,10 @@
<varlistentry id="tool_name" xreflabel="--tool">
<term>
- <option><![CDATA[--tool=<name> [default: memcheck] ]]></option>
+ <option><![CDATA[--tool=<toolname> [default: memcheck] ]]></option>
</term>
<listitem>
- <para>Run the Valgrind tool called <emphasis>name</emphasis>,
+ <para>Run the Valgrind tool called <varname>toolname</varname>,
e.g. Memcheck, Cachegrind, etc.</para>
</listitem>
</varlistentry>
@@ -662,25 +653,14 @@
</listitem>
</varlistentry>
- <varlistentry id="opt.tool" xreflabel="--tool">
- <term>
- <option><![CDATA[--tool=<toolname> [default: memcheck] ]]></option>
- </term>
- <listitem>
- <para>Run the Valgrind tool called <varname>toolname</varname>,
- e.g. Memcheck, Cachegrind, etc.</para>
- </listitem>
- </varlistentry>
-
<varlistentry id="opt.trace-children" xreflabel="--trace-children">
<term>
<option><![CDATA[--trace-children=<yes|no> [default: no] ]]></option>
</term>
<listitem>
<para>When enabled, Valgrind will trace into sub-processes
- initiated via the <varname>exec</varname> system call. This can be
- confusing and isn't usually what you want, so it is disabled by
- default.
+ initiated via the <varname>exec</varname> system call. This is
+ necessary for multi-process programs.
</para>
<para>Note that Valgrind does trace into the child of a
<varname>fork</varname> (it would be difficult not to, since
@@ -825,63 +805,52 @@
<option><![CDATA[--xml=<yes|no> [default: no] ]]></option>
</term>
<listitem>
- <para>When enabled, output will be in XML format. This is aimed
- at making life easier for tools that consume Valgrind's output
- as input, such as GUI front ends. Currently this option works
- with Memcheck, Helgrind and Ptrcheck. The output format is
- specified in the
- file
+ <para>When enabled, the important parts of the output (e.g. tool error
+ messages) will be in XML format rather than plain text. Furthermore,
+ the XML output will be sent to a different output channel than the
+ plain text output. Therefore, you also must use one of
+ <option>--xml-fd</option>, <option>--xml-file</option> or
+ <option>--xml-socket</option> to specify where the XML is to be sent.
+ </para>
+
+ <para>Less important messages will still be printed in plain text, but
+ because the XML output and plain text output are sent to different
+ output channels (the destination of the plain text output is still
+ controlled by <option>--log-fd</option>, <option>--log-file</option>
+ and <option>--log-socket</option>) this should not cause problems.
+ </para>
+
+ <para>This option is aimed at making life easier for tools that consume
+ Valgrind's output as input, such as GUI front ends. Currently this
+ option works with Memcheck, Helgrind and Ptrcheck. The output format
+ is specified in the file
<computeroutput>docs/internals/xml-output-protocol4.txt</computeroutput>
in the source tree for Valgrind 3.5.0 or later.</para>
+
+ <para>The recommended flags for a GUI to pass, when requesting
+ XML output, are: <option>--xml=yes</option> to enable XML output,
+ <option>--xml-file</option> to send the XML output to a (presumably
+ GUI-selected) file, <option>--log-file</option> to send the plain
+ text output to a second GUI-selected file,
+ <option>--child-silent-after-fork=yes</option>, and
+ <option>-q</option> to restrict the plain text output to critical
+ error messages created by Valgrind itself. For example, failure to
+ read a specified suppressions file counts as a critical error message.
+ In this way, for a successful run the text output file will be empty.
+ But if it isn't empty, then it will contain important information
+ which the GUI user should be made aware
+ of.</para>
</listitem>
</varlistentry>
-
-
-
<varlistentry id="opt.xml-fd" xreflabel="--xml-fd">
<term>
<option><![CDATA[--xml-fd=<number> [default: -1, disabled] ]]></option>
</term>
<listitem>
<para>Specifies that Valgrind should send its XML output to the
- specified file descriptor. By default, this is disabled. To
- use XML output, you need to give <option>--xml=yes</option> to
- tell the tool you want XML output. You also need to use one of
- <option>--xml-fd=</option>, <option>--xml-file=</option>
- or <option>--xml-socket=</option> to specify where the XML is to
- be sent. If you request XML output but do not specify a
- destination for it, Valgrind will refuse to start up.</para>
-
- <para>Note that XML output is sent on a different channel (file
- descriptor) to normal text output. It is entirely legitimate to
- select XML output, use one
- of <option>--xml-fd=</option>, <option>--xml-file=</option>
- or <option>--xml-socket=</option> to specify where it should be
- sent, and at the same time use one of
- <option>--log-fd=</option>, <option>--log-file=</option>
- or <option>--log-socket=</option> to specify where any residual
- text messages should be sent.</para>
-
- <para>The recommended flags for a GUI to pass, when requesting
- XML output, are: <option>--xml=yes</option> to enable XML
- output,
- <option>--xml-file=</option> to send the XML output to a
- (presumably GUI-selected) file, <option>--log-file=</option> to
- send the text output to a second GUI-selected file,
- and <option>-q</option> to restrict the text output to critical
- error messages created by Valgrind itself. For example, failure
- to read a specified suppressions file counts as a critical error
- message. In this way, for a successful run the text output file
- will be empty. But if it isn't empty, then it will contain
- important information which the GUI user should be made aware
- of.
-
- <para>Note that GUIs are strongly recommended to also
- specify <option>--child-silent-after-fork=yes</option>.
- </para>
-
- </para>
+ specified file descriptor. It must be used in conjunction with
+ <option>--xml=yes</option>.</para>
</listitem>
</varlistentry>
@@ -891,11 +860,11 @@
</term>
<listitem>
<para>Specifies that Valgrind should send its XML output
- to the specified file. Any <option>%p</option>
- or <option>%q</option> sequences appearing in the filename are
- expanded in exactly the same way as they are
- for <option>--log-file=</option>. See the description
- of <option>--log-file=</option> for details.
+ to the specified file. It must be used in conjunction with
+ <option>--xml=yes</option>. Any <option>%p</option> or
+ <option>%q</option> sequences appearing in the filename are expanded
+ in exactly the same way as they are for <option>--log-file</option>.
+ See the description of <option>--log-file</option> for details.
</para>
</listitem>
</varlistentry>
@@ -906,10 +875,10 @@
</term>
<listitem>
<para>Specifies that Valgrind should send its XML output the
- specified port at the specified IP address. This option behaves
- identically to <option>--log-socket=</option>, except that it
- specifies the destination for XML output rather than for text
- output. See the description of <option>--log-socket=</option>
+ specified port at the specified IP address. It must be used in
+ conjunction with <option>--xml=yes</option>. The form of the argument
+ is the same as that used by <option>--log-socket</option>.
+ See the description of <option>--log-socket</option>
for further details.</para>
</listitem>
</varlistentry>
@@ -940,8 +909,8 @@
mentioned in suppressions files should be in their mangled form.
Valgrind does not demangle function names when searching for
applicable suppressions, because to do otherwise would make
- suppressions file contents dependent on the state of Valgrind's
- demangling machinery, and would also be slow and pointless.</para>
+ suppression file contents dependent on the state of Valgrind's
+ demangling machinery, and also slow down suppression matching.</para>
</listitem>
</varlistentry>
@@ -950,14 +919,11 @@
<option><![CDATA[--num-callers=<number> [default: 12] ]]></option>
</term>
<listitem>
- <para>By default, Valgrind shows twelve levels of function call
- names to help you identify program locations. You can change that
- number with this option. This can help in determining the
- program's location in deeply-nested call chains. Note that errors
- are commoned up using only the top four function locations (the
- place in the current function, and that of its three immediate
- callers). So this doesn't affect the total number of errors
- reported.</para>
+ <para>Specifies the maximum number of entries shown in stack traces
+ that identify program locations. Note that errors are commoned up
+ using only the top four function locations (the place in the current
+ function, and that of its three immediate callers). So this doesn't
+ affect the total number of errors reported.</para>
<para>The maximum value for this is 50. Note that higher settings
will make Valgrind run a bit more slowly and take a bit more
@@ -1000,18 +966,18 @@
</term>
<listitem>
<para>By default, stack traces for errors do not show any
- functions that appear beneath <function>main()</function>
+ functions that appear beneath <function>main</function> because
most of the time it's uninteresting C library stuff and/or
- gobbledygook. Alternatively, if <function>main()</function> is not
+ gobbledygook. Alternatively, if <function>main</function> is not
present in the stack trace, stack traces will not show any functions
- below <function>main()</function>-like functions such as glibc's
- <function>__libc_start_main()</function>). Furthermore, if
- <function>main()</function>-like functions are present in the trace,
- they are normalised as "(below main)", in order to make the output
- more deterministic.</para>
+ below <function>main</function>-like functions such as glibc's
+ <function>__libc_start_main</function>. Furthermore, if
+ <function>main</function>-like functions are present in the trace,
+ they are normalised as <function>(below main)</function>, in order to
+ make the output more deterministic.</para>
<para>If this option is enabled, all stack trace entries will be
- shown and <function>main()</function>-like functions will not be
+ shown and <function>main</function>-like functions will not be
normalised.</para>
</listitem>
</varlistentry>
@@ -1034,7 +1000,7 @@
<listitem>
<para>When set to <varname>yes</varname>, Valgrind will pause
after every error shown and print the line:
- <literallayout> ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ----</literallayout>
+ <literallayout><computeroutput> ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ----</computeroutput></literallayout>
The prompt's behaviour is the same as for the
<option>--db-attach</option> option (see below).</para>
@@ -1079,7 +1045,7 @@
<listitem>
<para>When enabled, Valgrind will pause after every error shown
and print the line:
- <literallayout> ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ----</literallayout>
+ <literallayout><computeroutput> ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ----</computeroutput></literallayout>
Pressing <varname>Ret</varname>, or <varname>N Ret</varname> or
<varname>n Ret</varname>, causes Valgrind not to start a debugger
@@ -1103,7 +1069,7 @@
<listitem>
<para>Specify the debugger to use with the
<option>--db-attach</option> command. The default debugger is
- gdb. This option is a template that is expanded by Valgrind at
+ GDB. This option is a template that is expanded by Valgrind at
runtime. <literal>%f</literal> is replaced with the executable's
file name and <literal>%p</literal> is replaced by the process ID
of the executable.</para>
@@ -1148,9 +1114,9 @@
</term>
<listitem>
<para>This flag is only relevant when running Valgrind on
- MacOS X.</para>
+ Mac OS X.</para>
- <para>MacOS X uses a deferred debug information (debuginfo)
+ <para>Mac OS X uses a deferred debug information (debuginfo)
linking scheme. When object files containing debuginfo are
linked into a <computeroutput>.dylib</computeroutput> or an
executable, the debuginfo is not copied into the final file.
@@ -1183,13 +1149,14 @@
<para>Valgrind will not attempt to
run <computeroutput>dsymutil</computeroutput> on any
executable or library in
- <computeroutput>/usr</computeroutput>,
- <computeroutput>/bin</computeroutput>,
- <computeroutput>/sbin</computeroutput>,
- <computeroutput>/opt</computeroutput>,
- <computeroutput>/sw</computeroutput>,
- <computeroutput>/System</computeroutput> or
- <computeroutput>/Library</computeroutput>
+ <computeroutput>/usr/</computeroutput>,
+ <computeroutput>/bin/</computeroutput>,
+ <computeroutput>/sbin/</computeroutput>,
+ <computeroutput>/opt/</computeroutput>,
+ <computeroutput>/sw/</computeroutput>,
+ <computeroutput>/System/</computeroutput>,
+ <computeroutput>/Library/</computeroutput> or
+ <computeroutput>/Applications/</computeroutput>
since <computeroutput>dsymutil</computeroutput> will always fail
in such situations. It fails both because the debuginfo for
such pre-installed system components is not available anywhere,
@@ -1199,7 +1166,9 @@
<para>Be careful when
using <option>--auto-run-dsymutil=yes</option>, since it will
cause pre-existing <computeroutput>.dSYM</computeroutput>
- directories to be silently deleted and re-created.</para>
+ directories to be silently deleted and re-created. Also note the
+ <computeroutput>dsymutil</computeroutput> is quite slow, sometimes
+ excessively so.</para>
</listitem>
</varlistentry>
@@ -1299,27 +1268,28 @@
</sect2>
-<sect2 id="manual-core.mallocopts" xreflabel="malloc()-related Options">
-<title><computeroutput>malloc()</computeroutput>-related Options</title>
+<sect2 id="manual-core.mallocopts" xreflabel="malloc-related Options">
+<title><computeroutput>malloc</computeroutput>-related Options</title>
<!-- start of xi:include in the manpage -->
<para id="malloc-related.opts.para">For tools that use their own version of
-<computeroutput>malloc()</computeroutput> (e.g. Memcheck and
+<computeroutput>malloc</computeroutput> (e.g. Memcheck and
Massif), the following options apply.</para>
<variablelist id="malloc-related.opts.list">
<varlistentry id="opt.alignment" xreflabel="--alignment">
<term>
- <option><![CDATA[--alignment=<number> [default: 8] ]]></option>
+ <option><![CDATA[--alignment=<number> [default: 8 or 16, depending on the platform] ]]></option>
</term>
<listitem>
- <para>By default Valgrind's <function>malloc()</function>,
- <function>realloc()</function>, etc, return 8-byte aligned
- addresses. This is standard for most processors. However, some
- programs might assume that <function>malloc()</function> et al
- return 16-byte or more aligned memory. The supplied value must be
- between 8 and 4096 inclusive, and must be a power of two.</para>
+ <para>By default Valgrind's <function>malloc</function>,
+ <function>realloc</function>, etc, return a block whose starting
+ address is 8-byte aligned or 16-byte aligned (the value depends on the
+ platform and matches the platform default). This option allows you to
+ specify a different alignment. The supplied value must be greater
+ than or equal to the default, less than or equal to 4096, and must be
+ a power of two.</para>
</listitem>
</varlistentry>
@@ -1344,6 +1314,8 @@
<option><![CDATA[--run-libc-freeres=<yes|no> [default: yes] ]]></option>
</term>
<listitem>
+ <para>This flag is only relevant when running Valgrind on Linux.</para>
+
<para>The GNU C library (<function>libc.so</function>), which is
used by all programs, may allocate memory for its own uses.
Usually it doesn't bother to free that memory when the program
@@ -1411,10 +1383,10 @@
need it. Currently known variants are:</para>
<itemizedlist>
<listitem>
- <para><option>bproc: </option> Support the sys_broc system
- call on x86. This is for running on BProc, which is a minor
- variant of standard Linux which is sometimes used for building
- clusters.</para>
+ <para><option>bproc: </option> Support the
+ <function>sys_broc</function> system call on x86. This is for
+ running on BProc, which is a minor variant of standard Linux which
+ is sometimes used for building clusters.</para>
</listitem>
</itemizedlist>
</listitem>
@@ -1437,21 +1409,34 @@
</term>
<listitem>
<para>This option controls Valgrind's detection of self-modifying
- code. Valgrind can do no detection, detect self-modifying code on
- the stack, or detect self-modifying code anywhere. Note that the
- default option will catch the vast majority of cases, as far as we
- know. Running with <varname>all</varname> will slow Valgrind down
- greatly. Running with <varname>none</varname> will rarely
- speed things up, since very little code gets put on the stack for
- most programs.</para>
+ code. If no checking is done, if a program executes some code, then
+ overwrites it with new code, and executes the new code, Valgrind will
+ continue to execute the translations it made for the old code. This
+ will likely lead to incorrect behaviour and/or crashes.</para>
+
+ <para>Valgrind has three levels of self-modifying code detection:
+ no detection, detect self-modifying code on the stack (which used by
+ GCC to implement nested functions), or detect self-modifying code
+ everywhere. Note that the default option will catch the vast majority
+ of cases. The main case it will not catch is programs such as JIT
+ compilers that dynamically generate code <emphasis>and</emphasis>
+ subsequently overwrite part or all of it. Running with
+ <varname>all</varname> will slow Valgrind down greatly. Running with
+ <varname>none</varname> will rarely speed things up, since very little
+ code gets put on the stack for most programs. The
+ <function>VALGRIND_DISCARD_TRANSLATIONS</function> client request is
+ an alternative to <option>--smc-check=all</option> that requires more
+ effort but is much faster; see <xref
+ linkend="manual-core-adv.clientreq"/> for more details.</para>
<para>Some architectures (including ppc32 and ppc64) require
programs which create code at runtime to flush the instruction
cache in between code generation and first use. Valgrind
observes and honours such instructions. Hence, on ppc32/Linux
and ppc64/Linux, Valgrind always provides complete, transparent
- support for self-modifying code. It is only on x86/Linux
- and amd64/Linux that you need to use this flag.</para>
+ support for self-modifying code. It is only on platforms such as
+ x86/Linux, AMD64/Linux and x86/Darwin that you need to use this
+ flag.</para>
</listitem>
</varlistentry>
@@ -1499,16 +1484,15 @@
processed earlier; for example, options in
<computeroutput>./.valgrindrc</computeroutput> will take
precedence over those in
-<computeroutput>~/.valgrindrc</computeroutput>. The first two
-are particularly useful for setting the default tool to
-use.
+<computeroutput>~/.valgrindrc</computeroutput>.
</para>
<para>Please note that the <computeroutput>./.valgrindrc</computeroutput>
file is ignored if it is marked as world writeable or not owned
-by the current user. This is because the .valgrindrc can contain options
-that are potentially harmful or can be used by a local attacker to
-execute code under your user account.
+by the current user. This is because the
+<computeroutput>./.valgrindrc</computeroutput> can contain options that are
+potentially harmful or can be used by a local attacker to execute code under
+your user account.
</para>
<para>Any tool-specific options put in
@@ -1537,17 +1521,12 @@
<sect1 id="manual-core.pthreads" xreflabel="Support for Threads">
<title>Support for Threads</title>
-<para>Valgrind supports programs which use POSIX pthreads.
-Getting this to work was technically challenging but it now works
-well enough for significant threaded applications to run.</para>
-
-<para>The main thing to point out is that although Valgrind works
-with the standard Linux threads library (eg. NPTL or LinuxThreads), it
-serialises execution so that only one thread is running at a time. This
-approach avoids the horrible implementation problems of implementing a
+<para>The main thing to point out with respect to multithreaded programs is
+that your program will use the native threading library, but Valgrind
+serialises execution so that only one (kernel) thread is running at a time.
+This approach avoids the horrible implementation problems of implementing a
truly multiprocessor version of Valgrind, but it does mean that threaded
-apps run only on one CPU, even if you have a multiprocessor
-machine.</para>
+apps run only on one CPU, even if you have a multiprocessor machine.</para>
<para>Valgrind schedules your program's threads in a round-robin fashion,
with all threads having equal priority. It switches threads
@@ -1556,22 +1535,13 @@
of thread executions than when run natively. This in itself may
cause your program to behave differently if you have some kind of
concurrency, critical race, locking, or similar, bugs. In that case
-you might consider using Valgrind's Helgrind tool to track them down.</para>
+you might consider using the tools Helgrind and/or DRD to track them
+down.</para>
-<para>Your program will use the native
-<computeroutput>libpthread</computeroutput>, but not all of its facilities
-will work. In particular, synchronisation of processes via shared-memory
-segments will not work. This relies on special atomic instruction sequences
-which Valgrind does not emulate in a way which works between processes.
-Unfortunately there's no way for Valgrind to warn when this is happening,
-and such calls will mostly work. Only when there's a race will
-it fail.
-</para>
-
-<para>Valgrind also supports direct use of the
-<computeroutput>clone()</computeroutput> system call,
-<computeroutput>futex()</computeroutput> and so on.
-<computeroutput>clone()</computeroutput> is supported where either
+<para>On Linux, Valgrind also supports direct use of the
+<computeroutput>clone</computeroutput> system call,
+<computeroutput>futex</computeroutput> and so on.
+<computeroutput>clone</computeroutput> is supported where either
everything is shared (a thread) or nothing is shared (fork-like); partial
sharing will fail. Again, any use of atomic instruction sequences in shared
memory between processes will not work reliably.
@@ -1595,7 +1565,7 @@
<para>If your program dies as a result of a fatal core-dumping signal,
Valgrind will generate its own core file
(<computeroutput>vgcore.NNNNN</computeroutput>) containing your program's
-state. You may use this core file for post-mortem debugging with gdb or
+state. You may use this core file for post-mortem debugging with GDB or
similar. (Note: it will not generate a core if your core dump size limit is
0.) At the time of writing the core dumps do not include all the floating
point register information.</para>
@@ -1627,7 +1597,7 @@
</para>
<para>There are five options (in addition to the usual
-<option>--prefix=</option> which affect how Valgrind is built:
+<option>--prefix</option> which affect how Valgrind is built:
<itemizedlist>
<listitem>
@@ -1649,14 +1619,6 @@
</listitem>
<listitem>
- <para><option>--with-vex=</option></para>
- <para>Specifies the path to the underlying VEX dynamic-translation
- library. By default this is taken to be in the VEX directory off
- the root of the source tree.
- </para>
- </listitem>
-
- <listitem>
<para><option>--enable-only64bit</option></para>
<para><option>--enable-only32bit</option></para>
<para>On 64-bit
@@ -1707,10 +1669,9 @@
<para>If you get an assertion failure
in <filename>m_mallocfree.c</filename>, this may have happened because
-your program wrote off the end of a malloc'd block, or before its
-beginning. Valgrind hopefully will have emitted a proper message to that
-effect before dying in this way. This is a known problem which
-we should fix.</para>
+your program wrote off the end of a heap block, or before its
+beginning, thus corrupting head metadata. Valgrind hopefully will have
+emitted a message to that effect before dying in this way.</para>
<para>Read the <xref linkend="FAQ"/> for more advice about common problems,
crashes, etc.</para>
@@ -1725,18 +1686,19 @@
<para>The following list of limitations seems long. However, most
programs actually work fine.</para>
-<para>Valgrind will run Linux ELF binaries, on a kernel 2.4.X or 2.6.X
-system, on the x86, amd64, ppc32 and ppc64 architectures, subject to the
-following constraints:</para>
+<para>Valgrind will run programs on the supported platforms
+subject to the following constraints:</para>
<itemizedlist>
<listitem>
<para>On x86 and amd64, there is no support for 3DNow! instructions.
If the translator encounters these, Valgrind will generate a SIGILL
when the instruction is executed. Apart from that, on x86 and amd64,
- essentially all instructions are supported, up to and including SSE3.
+ essentially all instructions are supported, up to and including SSSE3.
</para>
+ </listitem>
+ <listitem>
<para>On ppc32 and ppc64, almost all integer, floating point and Altivec
instructions are supported. Specifically: integer and FP insns that are
mandatory for PowerPC, the "General-purpose optional" group (fsqrt, fsqrts,
@@ -1745,13 +1707,6 @@
</listitem>
<listitem>
- <para>Atomic instruction sequences are not properly supported, in the
- sense that their atomicity is not preserved. This will affect any
- use of synchronization via memory shared between processes. They
- will appear to work, but fail sporadically.</para>
- </listitem>
-
- <listitem>
<para>If your program does its own memory management, rather than
using malloc/new/free/delete, it should still work, but Memcheck's
error checking won't be so effective. If you describe your program's
@@ -1796,11 +1751,12 @@
the trampolines GCC uses to implemented nested functions. If you
regenerate code somewhere other than the stack, you will need to use
the <option>--smc-check=all</option> flag, and Valgrind will run more
- slowly than normal.</para>
+ slowly than normal. Or you can add client requests that tell Valgrind
+ when your program has overwritten code.</para>
</listitem>
<listitem>
- <para>As of version 3.0.0, Valgrind has the following limitations
+ <para>Valgrind has the following limitations
in its implementation of x86/AMD64 floating point relative to
IEEE754.</para>
@@ -1860,7 +1816,7 @@
</listitem>
<listitem>
- <para>As of version 3.0.0, Valgrind has the following limitations in
+ <para>Valgrind has the following limitations in
its implementation of x86/AMD64 SSE2 FP arithmetic, relative to
IEEE754.</para>
@@ -1873,7 +1829,7 @@
</listitem>
<listitem>
- <para>As of version 3.2.0, Valgrind has the following limitations
+ <para>Valgrind has the following limitations
in its implementation of PPC32 and PPC64 floating point
arithmetic, relative to IEEE754.</para>
@@ -1951,7 +1907,7 @@
==25832== For a detailed leak analysis, rerun with: --leak-check=yes
]]></programlisting>
-<para>The GCC folks fixed this about a week before gcc-3.0
+<para>The GCC folks fixed this about a week before GCC 3.0
shipped.</para>
</sect1>
@@ -1960,7 +1916,7 @@
<sect1 id="manual-core.warnings" xreflabel="Warning Messages">
<title>Warning Messages You Might See</title>
-<para>Most of these only appear if you run in verbose mode
+<para>Some of these only appear if you run in verbose mode
(enabled by <option>-v</option>):</para>
<itemizedlist>
Modified: trunk/docs/xml/manual-intro.xml
===================================================================
--- trunk/docs/xml/manual-intro.xml 2009-08-04 01:08:56 UTC (rev 10700)
+++ trunk/docs/xml/manual-intro.xml 2009-08-04 01:16:01 UTC (rev 10701)
@@ -27,7 +27,7 @@
<listitem>
<para><command>Cachegrind</command> is a cache and branch-prediction
- profiler. It can help you make your programs run faster.</para>
+ profiler. It helps you make your programs run faster.</para>
</listitem>
<listitem>
@@ -38,7 +38,7 @@
<listitem>
<para><command>Helgrind</command> is a thread error detector.
- It can help you make your multi-threaded programs more correct.
+ It helps you make your multi-threaded programs more correct.
</para>
</listitem>
@@ -49,7 +49,7 @@
</listitem>
<listitem>
- <para><command>Massif</command> is a heap profiler. It can help you
+ <para><command>Massif</command> is a heap profiler. It helps you
make your programs use less memory.</para>
</listitem>
@@ -117,8 +117,8 @@
only need to read the documentation for the core and for the tool(s) you
actually use, although you may find it helpful to be at least a little
bit familiar with what all tools do. If you're new to all this, you probably
-want to run the Memcheck tool. The final chapter explains how to write a
-new tool.</para>
+want to run the Memcheck tool and you might find the <xref
+linkend="quick-start"/> useful.</para>
<para>Be aware that the core understands some command line flags, and
the tools have their own flags which they know about. This means
@@ -126,8 +126,6 @@
accepted -- you have to read the flags documentation both for
<xref linkend="manual-core"/> and for the tool you want to use.</para>
-<para>The manual is quite big and complex. If you want to start using
-Valgrind more quickly, read <xref linkend="quick-start"/>.</para>
</sect1>
Modified: trunk/docs/xml/manual-writing-tools.xml
===================================================================
--- trunk/docs/xml/manual-writing-tools.xml 2009-08-04 01:08:56 UTC (rev 10700)
+++ trunk/docs/xml/manual-writing-tools.xml 2009-08-04 01:16:01 UTC (rev 10701)
@@ -225,7 +225,7 @@
be left untouched (they default to <varname>False</varname>). They
determine whether a tool can do various things such as: record, report
and suppress errors; process command line options; wrap system calls;
-record extra information about malloc'd blocks, etc.</para>
+record extra information about heap blocks, etc.</para>
<para>For example, if a tool wants the core's help in recording and
reporting errors, it must call
@@ -240,13 +240,13 @@
<para>Third, the tool can indicate which events in core it wants to be
notified about, using the functions <function>VG_(track_*)()</function>.
-These include things such as blocks of memory being malloc'd, the stack
+These include things such as heap blocks being allocated, the stack
pointer changing, a mutex being locked, etc. If a tool wants to know
about this, it should provide a pointer to a function, which will be
called when that event happens.</para>
-<para>For example, if the tool want to be notified when a new block of
-memory is malloc'd, it should call
+<para>For example, if the tool want to be notified when a new heap block
+is allocated, it should call
<function>VG_(track_new_mem_heap)()</function> with an appropriate
function pointer, and the assigned function will be called each time
this happens.</para>
Modified: trunk/drd/docs/drd-manual.xml
===================================================================
--- trunk/drd/docs/drd-manual.xml 2009-08-04 01:08:56 UTC (rev 10700)
+++ trunk/drd/docs/drd-manual.xml 2009-08-04 01:16:01 UTC (rev 10701)
@@ -75,7 +75,7 @@
is well suited for computational intensive applications. As an example,
an open source image processing software package is using OpenMP to
maximize performance on systems with multiple CPU
- cores. The <computeroutput>gcc</computeroutput> compiler supports the
+ cores. GCC supports the
OpenMP standard from version 4.2.0 on.
</para>
</listitem>
@@ -88,7 +88,7 @@
is a so-called optimistic approach. There is a prototype of the Intel C
Compiler (<computeroutput>icc</computeroutput>) available that supports
STM. Research about the addition of STM support
- to <computeroutput>gcc</computeroutput> is ongoing.
+ to GCC is ongoing.
</para>
</listitem>
</itemizedlist>
@@ -1205,8 +1205,8 @@
</para>
<para>
-DRD supports OpenMP shared-memory programs generated by gcc. The gcc
-compiler supports OpenMP since version 4.2.0. Gcc's runtime support
+DRD supports OpenMP shared-memory programs generated by GCC. GCC
+supports OpenMP since version 4.2.0. GCC's runtime support
for OpenMP programs is provided by a library called
<literal>libgomp</literal>. The synchronization primitives implemented
in this library use Linux' futex system call directly, unless the
@@ -1214,9 +1214,9 @@
<literal>--disable-linux-futex</literal> flag. DRD only supports
libgomp libraries that have been configured with this flag and in
which symbol information is present. For most Linux distributions this
-means that you will have to recompile gcc. See also the script
+means that you will have to recompile GCC. See also the script
<literal>drd/scripts/download-and-build-gcc</literal> in the
-Valgrind source tree for an example of how to compile gcc. You will
+Valgrind source tree for an example of how to compile GCC. You will
also have to make sure that the newly compiled
<literal>libgomp.so</literal> library is loaded when OpenMP programs
are started. This is possible by adding a line similar to the
@@ -1266,14 +1266,14 @@
]]></programlisting>
<para>
In the above output the function name <function>gj.omp_fn.0</function>
-has been generated by gcc from the function name
+has been generated by GCC from the function name
<function>gj</function>. The allocation context information shows that the
data race has been caused by modifying the variable <literal>k</literal>.
</para>
<para>
-Note: for gcc versions before 4.4.0, no allocation context information is
-shown. With these gcc versions the most usable information in the above output
+Note: for GCC versions before 4.4.0, no allocation context information is
+shown. With these GCC versions the most usable information in the above output
is the source file name and the line number where the data race has been
detected (<literal>omp_matinv.c:203</literal>).
</para>
@@ -1673,8 +1673,8 @@
</listitem>
<listitem>
<para>
- If you compile the DRD source code yourself, you need gcc 3.0 or
- later. Gcc 2.95 is not supported.
+ If you compile the DRD source code yourself, you need GCC 3.0 or
+ later. GCC 2.95 is not supported.
</para>
</listitem>
</itemizedlist>
Modified: trunk/helgrind/docs/hg-manual.xml
===================================================================
--- trunk/helgrind/docs/hg-manual.xml 2009-08-04 01:08:56 UTC (rev 10700)
+++ trunk/helgrind/docs/hg-manual.xml 2009-08-04 01:16:01 UTC (rev 10701)
@@ -748,11 +748,11 @@
the futex syscall, which causes total chaos since in Helgrind
since it cannot "see" those.</para>
<para>Fortunately, this can be solved using a configuration-time
- flag (for gcc). Rebuild gcc from source, and configure using
+ flag (for GCC). Rebuild GCC from source, and configure using
<varname>--disable-linux-futex</varname>.
This makes libgomp.so use the standard
POSIX threading primitives instead. Note that this was tested
- using gcc-4.2.3 and has not been re-tested using more recent gcc
+ using GCC 4.2.3 and has not been re-tested using more recent GCC
versions. We would appreciate hearing about any successes or
failures with more recent versions.</para>
</listitem>
@@ -1096,7 +1096,7 @@
when provided with unbounded storage for conflicting access info.
This should be investigated.</para>
</listitem>
- <listitem><para>Document races caused by gcc's thread-unsafe code
+ <listitem><para>Document races caused by GCC's thread-unsafe code
generation for speculative stores. In the interim see
<computeroutput>http://gcc.gnu.org/ml/gcc/2007-10/msg00266.html
</computeroutput>
Modified: trunk/massif/docs/ms-manual.xml
===================================================================
--- trunk/massif/docs/ms-manual.xml 2009-08-04 01:08:56 UTC (rev 10700)
+++ trunk/massif/docs/ms-manual.xml 2009-08-04 01:16:01 UTC (rev 10701)
@@ -535,7 +535,7 @@
<para>If heap profiling is enabled, gives the number of administrative
bytes per block to use. This should be an estimate of the average,
since it may vary. For example, the allocator used by
- <computeroutput>glibc</computeroutput> requires somewhere between 4 to
+ glibc on Linux requires somewhere between 4 to
15 bytes per block, depending on various factors. It also requires
admin space for freed blocks, although Massif does not account
for this.</para>
Modified: trunk/memcheck/docs/mc-manual.xml
===================================================================
--- trunk/memcheck/docs/mc-manual.xml 2009-08-04 01:08:56 UTC (rev 10700)
+++ trunk/memcheck/docs/mc-manual.xml 2009-08-04 01:16:01 UTC (rev 10701)
@@ -129,9 +129,6 @@
nonsensical. Memcheck checks for and
rejects this combination at startup.
</para>
- <para>Origin tracking is a new feature, introduced in Valgrind
- version 3.4.0.
- </para>
</listitem>
</varlistentry>
@@ -180,7 +177,7 @@
<option>--num-callers=40</option> or some such large number.
</para>
- <para>Note that the <option>--leak-resolution=</option> setting
+ <para>Note that the <option>--leak-resolution</option> setting
does not affect Memcheck's ability to find
leaks. It only changes how the results are presented.</para>
</listitem>
@@ -217,17 +214,17 @@
</term>
<listitem>
<para>When enabled, assume that reads and writes some small
- distance below the stack pointer are due to bugs in gcc 2.96, and
+ distance below the stack pointer are due to bugs in GCC 2.96, and
does not report them. The "small distance" is 256 bytes by
- default. Note that gcc 2.96 is the default compiler on some ancient
+ default. Note that GCC 2.96 is the default compiler on some ancient
Linux distributions (RedHat 7.X) and so you may need to use this
flag. Do not use it if you do not have to, as it can cause real
errors to be overlooked. A better alternative is to use a more
- recent gcc/g++ in which this bug is fixed.</para>
+ recent GCC in which this bug is fixed.</para>
<para>You may also need to use this flag when working with
- gcc/g++ 3.X or 4.X on 32-bit PowerPC Linux. This is because
- gcc/g++ generates code which occasionally accesses below the
+ GCC 3.X or 4.X on 32-bit PowerPC Linux. This is because
+ GCC generates code which occasionally accesses below the
stack pointer, particularly for floating-point to/from integer
conversions. This is in violation of the 32-bit PowerPC ELF
specification, which makes no provision for locations below the
@@ -336,16 +333,16 @@
<para>Memcheck tries to establish what the illegal address might relate
to, since that's often useful. So, if it points into a block of memory
which has already been freed, you'll be informed of this, and also where
-the block was free'd at. Likewise, if it should turn out to be just off
-the end of a malloc'd block, a common result of off-by-one-errors in
+the block was freed. Likewise, if it should turn out to be just off
+the end of a heap block, a common result of off-by-one-errors in
array subscripting, you'll be informed of this fact, and also where the
-block was malloc'd.</para>
+block was allocated.</para>
<para>In this example, Memcheck can't identify the address. Actually
the address is on the stack, but, for some reason, this is not a valid
stack address -- it is below the stack pointer and that isn't allowed.
-In this particular case it's probably caused by gcc generating invalid
-code, a known bug in some ancient versions of gcc.</para>
+In this particular case it's probably caused by GCC generating invalid
+code, a known bug in some ancient versions of GCC.</para>
<para>Note that Memcheck only tells you that your program is about to
access memory at an illegal address. It can't stop the access from
@@ -402,11 +399,10 @@
as in the example above.</para>
</listitem>
<listitem>
- <para>The contents of malloc'd blocks, before you write something
- there. In C++, the new operator is a wrapper round
- <function>malloc</function>, so if you create an object with new,
- its fields will be uninitialised until you (or the constructor)
- fill them in.</para>
+ <para>The contents of heap blocks (allocated with
+ <function>malloc</function>, <function>new</function>, or a similar
+ function) before you (or a constructor) write something there.
+ </para>
</listitem>
</itemizedlist>
@@ -438,7 +434,7 @@
<function>free</function>/<computeroutput>delete</computeroutput> is
legitimate or not. Here, this test program has freed the same block
twice. As with the illegal read/write errors, Memcheck attempts to
-make sense of the address free'd. If, as here, the address is one
+make sense of the address freed. If, as here, the address is one
which has previously been freed, you wil be told that -- making
duplicate frees of the same block easy to spot.</para>
@@ -563,7 +559,7 @@
]]></programlisting>
<para>... because the program has (a) tried to write uninitialised junk
-from the malloc'd block to the standard output, and (b) passed an
+from the heap block to the standard output, and (b) passed an
uninitialised value to <function>exit</function>. Note that the first
error refers to the memory pointed to by
<computeroutput>buf</computeroutput> (not
@@ -1015,12 +1011,12 @@
<varname>struct S</varname>'s on some architectures.</para>
<para>So <varname>s1</varname> occupies 8 bytes, yet only 5 of them will
-be initialised. For the assignment <varname>s2 = s1</varname>, gcc
+be initialised. For the assignment <...
[truncated message content] |
|
From: <sv...@va...> - 2009-08-04 01:09:10
|
Author: njn Date: 2009-08-04 02:08:56 +0100 (Tue, 04 Aug 2009) New Revision: 10700 Log: This should have been removed in r10699. Removed: trunk/none/tests/filter_long_command Modified: trunk/none/tests/Makefile.am Modified: trunk/none/tests/Makefile.am =================================================================== --- trunk/none/tests/Makefile.am 2009-08-04 00:27:56 UTC (rev 10699) +++ trunk/none/tests/Makefile.am 2009-08-04 01:08:56 UTC (rev 10700) @@ -36,7 +36,6 @@ filter_cmdline0 \ filter_fdleak \ filter_linenos \ - filter_long_command \ filter_none_discards \ filter_stderr \ filter_timestamp Deleted: trunk/none/tests/filter_long_command =================================================================== --- trunk/none/tests/filter_long_command 2009-08-04 00:27:56 UTC (rev 10699) +++ trunk/none/tests/filter_long_command 2009-08-04 01:08:56 UTC (rev 10700) @@ -1,9 +0,0 @@ -#! /bin/sh - -dir=`dirname $0` - -# We change the "Command:" so it doesn't get stripped out by the standard -# filters. -sed "s/Command:/COMMAND:/" | - -./filter_stderr |
|
From: Nicholas N. <n.n...@gm...> - 2009-08-04 00:44:07
|
On Tue, Aug 4, 2009 at 8:56 AM, Nicholas Nethercote<n.n...@gm...> wrote: > > So how > about we move all debugging info (eg. redirs, debug info) into -d, and > only have useful user stuff (eg. suppressions used, full error list at > the end) in -v? --show-emwarns could be folded into -d or -d -d as well. N |
|
From: <sv...@va...> - 2009-08-04 00:28:11
|
Author: njn
Date: 2009-08-04 01:27:56 +0100 (Tue, 04 Aug 2009)
New Revision: 10699
Log:
Don't wrap the "Command:" line, as doing so makes cutting-and-pasting the
command difficult. Also, when wrapping I was failing to factor in the
escape chars needed for chars like ' '; now I don't need to. And this
means the 'long-command' test is no longer necessary. In other words,
favour utility and simplicity over aesthetics.
Also, the "Command:" line wasn't being wrapped in <line></line> in XML
output. It now is.
Removed:
trunk/none/tests/long-command.stderr.exp
trunk/none/tests/long-command.vgtest
Modified:
trunk/coregrind/m_main.c
trunk/exp-ptrcheck/tests/hsg.stderr.exp
trunk/helgrind/tests/tc06_two_races_xml.stderr.exp
trunk/memcheck/tests/long_namespace_xml.stderr.exp
trunk/memcheck/tests/xml1.stderr.exp
trunk/none/tests/Makefile.am
Modified: trunk/coregrind/m_main.c
===================================================================
--- trunk/coregrind/m_main.c 2009-08-03 14:39:54 UTC (rev 10698)
+++ trunk/coregrind/m_main.c 2009-08-04 00:27:56 UTC (rev 10699)
@@ -982,7 +982,6 @@
const HChar* toolname )
{
Int i;
- SizeT n;
HChar* xpre = VG_(clo_xml) ? " <line>" : "";
HChar* xpost = VG_(clo_xml) ? "</line>" : "";
UInt (*umsg_or_xml)( const HChar*, ... )
@@ -1024,8 +1023,7 @@
);
}
- umsg_or_xml("%s%s%s\n",
- xpre, VG_(details).copyright_author, xpost);
+ umsg_or_xml("%s%s%s\n", xpre, VG_(details).copyright_author, xpost);
/* Core details */
umsg_or_xml(
@@ -1033,35 +1031,19 @@
xpre, VERSION, xpost
);
- /* Print the command line, wrapping near 80-chars wide. An example of a
- command line with many args, some of them very long:
-
-==9717== Command: date 11 23 4a \
-==9717== aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa \
-==9717== aaa 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 \
-==9717== 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 \
-==9717== fffffffffffffffffffffffffffff 1 2 3 \
-==9717== bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
- */
- umsg_or_xml("Command: ");
+ // Print the command line. At one point we wrapped at 80 chars and
+ // printed a '\' as a line joiner, but that makes it hard to cut and
+ // paste the command line (because of the "==pid==" prefixes), so we now
+ // favour utility and simplicity over aesthetics.
+ umsg_or_xml("%sCommand: ", xpre);
if (VG_(args_the_exename))
umsg_or_xml_arg(VG_(args_the_exename), umsg_or_xml);
- n = 0;
for (i = 0; i < VG_(sizeXA)( VG_(args_for_client) ); i++) {
HChar* s = *(HChar**)VG_(indexXA)( VG_(args_for_client), i );
- SizeT slen = VG_(strlen)(s);
- n += slen + 1; // +1 for the space char between each argument
- // With a PID of up to 5 digits, 58 puts the line-ending '\' in
- // column 79 at the most, always leaving column 80 empty.
- if (n > 58) {
- VG_(umsg)(" \\");
- VG_(umsg)("\n ");
- n = slen;
- }
umsg_or_xml(" ");
umsg_or_xml_arg(s, umsg_or_xml);
}
- umsg_or_xml("\n");
+ umsg_or_xml("%s\n", xpost);
if (VG_(clo_xml))
VG_(printf_xml)("</preamble>\n");
@@ -1144,10 +1126,10 @@
} else {
# define BUF_LEN 256
Char version_buf[BUF_LEN];
- Int nn = VG_(read) ( sr_Res(fd), version_buf, BUF_LEN );
- vg_assert(nn <= BUF_LEN);
- if (nn > 0) {
- version_buf[nn-1] = '\0';
+ Int n = VG_(read) ( sr_Res(fd), version_buf, BUF_LEN );
+ vg_assert(n <= BUF_LEN);
+ if (n > 0) {
+ version_buf[n-1] = '\0';
VG_(message)(Vg_DebugMsg, " %s\n", version_buf);
} else {
VG_(message)(Vg_DebugMsg, " (empty?)\n");
Modified: trunk/exp-ptrcheck/tests/hsg.stderr.exp
===================================================================
--- trunk/exp-ptrcheck/tests/hsg.stderr.exp 2009-08-03 14:39:54 UTC (rev 10698)
+++ trunk/exp-ptrcheck/tests/hsg.stderr.exp 2009-08-04 00:27:56 UTC (rev 10699)
@@ -10,6 +10,7 @@
<line>...</line>
<line>...</line>
<line>...</line>
+ <line>...</line>
</preamble>
<pid>...</pid>
Modified: trunk/helgrind/tests/tc06_two_races_xml.stderr.exp
===================================================================
--- trunk/helgrind/tests/tc06_two_races_xml.stderr.exp 2009-08-03 14:39:54 UTC (rev 10698)
+++ trunk/helgrind/tests/tc06_two_races_xml.stderr.exp 2009-08-04 00:27:56 UTC (rev 10699)
@@ -9,6 +9,7 @@
<line>...</line>
<line>...</line>
<line>...</line>
+ <line>...</line>
</preamble>
<pid>...</pid>
Modified: trunk/memcheck/tests/long_namespace_xml.stderr.exp
===================================================================
--- trunk/memcheck/tests/long_namespace_xml.stderr.exp 2009-08-03 14:39:54 UTC (rev 10698)
+++ trunk/memcheck/tests/long_namespace_xml.stderr.exp 2009-08-04 00:27:56 UTC (rev 10699)
@@ -9,6 +9,7 @@
<line>...</line>
<line>...</line>
<line>...</line>
+ <line>...</line>
</preamble>
<pid>...</pid>
Modified: trunk/memcheck/tests/xml1.stderr.exp
===================================================================
--- trunk/memcheck/tests/xml1.stderr.exp 2009-08-03 14:39:54 UTC (rev 10698)
+++ trunk/memcheck/tests/xml1.stderr.exp 2009-08-04 00:27:56 UTC (rev 10699)
@@ -9,6 +9,7 @@
<line>...</line>
<line>...</line>
<line>...</line>
+ <line>...</line>
</preamble>
<pid>...</pid>
Modified: trunk/none/tests/Makefile.am
===================================================================
--- trunk/none/tests/Makefile.am 2009-08-03 14:39:54 UTC (rev 10698)
+++ trunk/none/tests/Makefile.am 2009-08-04 00:27:56 UTC (rev 10699)
@@ -81,7 +81,6 @@
fork.stderr.exp fork.stdout.exp fork.vgtest \
fucomip.stderr.exp fucomip.vgtest \
gxx304.stderr.exp gxx304.vgtest \
- long-command.stderr.exp long-command.vgtest \
manythreads.stdout.exp manythreads.stderr.exp manythreads.vgtest \
map_unaligned.stderr.exp map_unaligned.vgtest \
map_unmap.stderr.exp map_unmap.stdout.exp map_unmap.vgtest \
Deleted: trunk/none/tests/long-command.stderr.exp
===================================================================
--- trunk/none/tests/long-command.stderr.exp 2009-08-03 14:39:54 UTC (rev 10698)
+++ trunk/none/tests/long-command.stderr.exp 2009-08-04 00:27:56 UTC (rev 10699)
@@ -1,10 +0,0 @@
-COMMAND: ./../../tests/true 11 23 4a \
- aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa \
- aaa 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 \
- 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 \
- fffffffffffffffffffffffffffff 1 2 3 \
- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1 2 3 4 1 \
- 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 \
- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-
-
Deleted: trunk/none/tests/long-command.vgtest
===================================================================
--- trunk/none/tests/long-command.vgtest 2009-08-03 14:39:54 UTC (rev 10698)
+++ trunk/none/tests/long-command.vgtest 2009-08-04 00:27:56 UTC (rev 10699)
@@ -1,2 +0,0 @@
-prog: ../../tests/true 11 23 4a aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaa 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 fffffffffffffffffffffffffffff 1 2 3 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-stderr_filter: filter_long_command
|
|
From: Julian S. <js...@ac...> - 2009-08-04 00:00:06
|
On Tuesday 04 August 2009, Nicholas Nethercote wrote: > Hi, > > I suggest changing --auto-run-dsymutil to --dsymutil just to save > everyone some typing. Any objections? I kinda liked the descriptiveness of the long version, but not that bothered .. fine by me. J |