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
(10) |
2
(3) |
3
(25) |
4
(8) |
|
5
(13) |
6
(8) |
7
(9) |
8
(10) |
9
(8) |
10
(13) |
11
(12) |
|
12
|
13
(7) |
14
(8) |
15
(11) |
16
(13) |
17
(13) |
18
(11) |
|
19
(13) |
20
(7) |
21
(1) |
22
(1) |
23
(1) |
24
(8) |
25
(15) |
|
26
(16) |
27
(20) |
28
(17) |
29
(10) |
30
(2) |
|
|
|
From: Christian B. <bor...@de...> - 2011-06-17 20:36:43
|
Nightly build on sless390 ( SUSE Linux Enterprise Server 11 SP1 gcc 4.3.4 on z196 (s390x) ) Started at 2011-06-17 22:10:01 CEST Ended at 2011-06-17 22:36:33 CEST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 477 tests, 6 stderr failures, 0 stdout failures, 3 stderrB failures, 0 stdoutB failures, 0 post failures == gdbserver_tests/mcbreak (stderrB) gdbserver_tests/mcclean_after_fork (stderrB) gdbserver_tests/mssnapshot (stderrB) none/tests/faultstatus (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc23_bogus_condwait (stderr) drd/tests/tc04_free_lock (stderr) drd/tests/tc09_bad_unlock (stderr) drd/tests/tc23_bogus_condwait (stderr) |
|
From: Christian B. <bor...@de...> - 2011-06-17 20:35:50
|
Nightly build on fedora390 ( Fedora 13/14/15 mix with gcc 3.5.3 on z196 (s390x) ) Started at 2011-06-17 22:10:01 CEST Ended at 2011-06-17 22:35:01 CEST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 477 tests, 6 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc23_bogus_condwait (stderr) drd/tests/tc04_free_lock (stderr) drd/tests/tc09_bad_unlock (stderr) drd/tests/tc23_bogus_condwait (stderr) |
|
From: <sv...@va...> - 2011-06-17 08:36:15
|
Author: sewardj
Date: 2011-06-17 09:31:22 +0100 (Fri, 17 Jun 2011)
New Revision: 11821
Log:
Move the GDBserver documentation from the "Valgrind core" chapter
to the "Valgrind core: advanced topics" chapter.
Modified:
trunk/callgrind/docs/cl-manual.xml
trunk/docs/xml/manual-core-adv.xml
trunk/docs/xml/manual-core.xml
trunk/massif/docs/ms-manual.xml
trunk/memcheck/docs/mc-manual.xml
Modified: trunk/callgrind/docs/cl-manual.xml
===================================================================
--- trunk/callgrind/docs/cl-manual.xml 2011-06-17 08:14:00 UTC (rev 11820)
+++ trunk/callgrind/docs/cl-manual.xml 2011-06-17 08:31:22 UTC (rev 11821)
@@ -1078,7 +1078,7 @@
<sect1 id="cl-manual.monitor-commands" xreflabel="Callgrind Monitor Commands">
<title>Callgrind Monitor Commands</title>
<para>The Callgrind tool provides monitor commands handled by the Valgrind
-gdbserver (see <xref linkend="manual-core.gdbserver-commandhandling"/>).
+gdbserver (see <xref linkend="manual-core-adv.gdbserver-commandhandling"/>).
</para>
<itemizedlist>
Modified: trunk/docs/xml/manual-core-adv.xml
===================================================================
--- trunk/docs/xml/manual-core-adv.xml 2011-06-17 08:14:00 UTC (rev 11820)
+++ trunk/docs/xml/manual-core-adv.xml 2011-06-17 08:31:22 UTC (rev 11821)
@@ -273,6 +273,929 @@
+
+
+<sect1 id="manual-core-adv.gdbserver"
+ xreflabel="Debugging your program using Valgrind's gdbserver and GDB">
+<title>Debugging your program using Valgrind gdbserver and GDB</title>
+
+<para>A program running under Valgrind is not executed directly by the
+CPU. Instead it runs on a synthetic CPU provided by Valgrind. This is
+why a debugger cannot debug your program when it runs on Valgrind.
+</para>
+<para>
+This section describes how GDB can interact with the
+Valgrind gdbserver to provide a fully debuggable program under
+Valgrind. Used in this way, GDB also provides an interactive usage of
+Valgrind core or tool functionalities, including incremental leak search
+under Memcheck and on-demand Massif snapshot production.
+</para>
+
+<sect2 id="manual-core-adv.gdbserver-simple"
+ xreflabel="gdbserver simple example">
+<title>Quick Start: debugging in 3 steps</title>
+
+<para>If you want to debug a program with GDB when using the Memcheck
+tool, start Valgrind the following way:
+<screen><![CDATA[
+valgrind --vgdb=yes --vgdb-error=0 prog
+]]></screen></para>
+
+<para>In another window, start a GDB the following way:
+<screen><![CDATA[
+gdb prog
+]]></screen></para>
+
+<para>Then give the following command to GDB:
+<screen><![CDATA[
+(gdb) target remote | vgdb
+]]></screen></para>
+
+<para>You can now debug your program e.g. by inserting a breakpoint
+and then using the GDB <computeroutput>continue</computeroutput>
+command.</para>
+
+<para>This quick start information is enough for basic usage of the
+Valgrind gdbserver. The sections below describe more advanced
+functionality provided by the combination of Valgrind and GDB. Note
+that the command line flag <option>--vgdb=yes</option> can be omitted,
+as this is the default value.
+</para>
+
+</sect2>
+
+<sect2 id="manual-core-adv.gdbserver-concept"
+ xreflabel="gdbserver">
+<title>Valgrind gdbserver overall organisation</title>
+<para>The GNU GDB debugger is typically used to debug a process
+running on the same machine. In this mode, GDB uses system calls to
+control and query the program being debugged. This works well, but
+only allows GDB to debug a program running on the same computer.
+</para>
+
+<para>GDB can also debug processes running on a different computer.
+To achieve this, GDB defines a protocol (that is, a set of query and
+reply packets) that facilitates fetching the value of memory or
+registers, setting breakpoints, etc. A gdbserver is an implementation
+of this "GDB remote debugging" protocol. To debug a process running
+on a remote computer, a gdbserver (sometimes called a GDB stub)
+must run at the remote computer side.
+</para>
+
+<para>The Valgrind core provides a built-in gdbserver implementation,
+which is activated using <option>--vgdb=yes</option>
+or <option>--vgdb=full</option>. This gdbserver allows the process
+running on Valgrind's synthetic CPU to be debugged remotely.
+GDB sends protocol query packets (such as "get register contents") to
+the Valgrind embedded gdbserver. The gdbserver executes the queries
+(for example, it will get the register values of the synthetic CPU)
+and gives the results back to GDB.
+</para>
+
+<para>GDB can use various kinds of channels (TCP/IP, serial line, etc)
+to communicate with the gdbserver. In the case of Valgrind's
+gdbserver, communication is done via a pipe and a small helper program
+called <xref linkend="manual-core-adv.vgdb"/>, which acts as an
+intermediary. If no GDB is in use, vgdb can also be
+used to send monitor commands to the Valgrind gdbserver from a shell
+command line.
+</para>
+
+</sect2>
+
+<sect2 id="manual-core-adv.gdbserver-gdb"
+ xreflabel="Connecting GDB to a Valgrind gdbserver">
+<title>Connecting GDB to a Valgrind gdbserver</title>
+<para>To debug a program "<filename>prog</filename>" running under
+Valgrind, you must ensure that the Valgrind gdbserver is activated by
+specifying either <option>--vgdb=yes</option>
+or <option>--vgdb=full</option>). A secondary command line option,
+<option>--vgdb-error=number</option>, can be used to tell the gdbserver
+only to become active once the specified number of errors have been
+reported. A value of zero will therefore cause
+the gdbserver to become active at startup, which allows you to
+insert breakpoints before starting the run. For example:
+<screen><![CDATA[
+valgrind --tool=memcheck --vgdb=yes --vgdb-error=0 ./prog
+]]></screen></para>
+
+<para>The Valgrind gdbserver is invoked at startup
+and indicates it is waiting for a connection from a GDB:</para>
+
+<programlisting><![CDATA[
+==2418== Memcheck, a memory error detector
+==2418== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
+==2418== Using Valgrind-3.7.0.SVN and LibVEX; rerun with -h for copyright info
+==2418== Command: ./prog
+==2418==
+==2418== (action at startup) vgdb me ...
+]]></programlisting>
+
+
+<para>GDB (in another shell) can then be connected to the Valgrind gdbserver.
+For this, GDB must be started on the program <filename>prog</filename>:
+<screen><![CDATA[
+gdb ./prog
+]]></screen></para>
+
+
+<para>You then indicate to GDB that you want to debug a remote target:
+<screen><![CDATA[
+(gdb) target remote | vgdb
+]]></screen>
+GDB then starts a vgdb relay application to communicate with the
+Valgrind embedded gdbserver:</para>
+
+<programlisting><![CDATA[
+(gdb) target remote | vgdb
+Remote debugging using | vgdb
+relaying data between gdb and process 2418
+Reading symbols from /lib/ld-linux.so.2...done.
+Reading symbols from /usr/lib/debug/lib/ld-2.11.2.so.debug...done.
+Loaded symbols for /lib/ld-linux.so.2
+[Switching to Thread 2418]
+0x001f2850 in _start () from /lib/ld-linux.so.2
+(gdb)
+]]></programlisting>
+
+<para>Note that vgdb is provided as part of the Valgrind
+distribution. You do not need to install it separately.</para>
+
+<para>If vgdb detects that there are multiple Valgrind gdbservers that
+can be connected to, it will list all such servers and their PIDs, and
+then exit. You can then reissue the GDB "target" command, but
+specifying the PID the process you want to debug:
+</para>
+
+<programlisting><![CDATA[
+(gdb) target remote | vgdb
+Remote debugging using | vgdb
+no --pid= arg given and multiple valgrind pids found:
+use --pid=2479 for valgrind --tool=memcheck --vgdb=yes --vgdb-error=0 ./prog
+use --pid=2481 for valgrind --tool=memcheck --vgdb=yes --vgdb-error=0 ./prog
+use --pid=2483 for valgrind --vgdb=yes --vgdb-error=0 ./another_prog
+Remote communication error: Resource temporarily unavailable.
+(gdb) target remote | vgdb --pid=2479
+Remote debugging using | vgdb --pid=2479
+relaying data between gdb and process 2479
+Reading symbols from /lib/ld-linux.so.2...done.
+Reading symbols from /usr/lib/debug/lib/ld-2.11.2.so.debug...done.
+Loaded symbols for /lib/ld-linux.so.2
+[Switching to Thread 2479]
+0x001f2850 in _start () from /lib/ld-linux.so.2
+(gdb)
+]]></programlisting>
+
+<para>Once GDB is connected to the Valgrind gdbserver, it can be used
+in the same way as if you were debugging the program natively:</para>
+ <itemizedlist>
+ <listitem>
+ <para>Breakpoints can be inserted or deleted.</para>
+ </listitem>
+ <listitem>
+ <para>Variables and register values can be examined or modified.
+ </para>
+ </listitem>
+ <listitem>
+ <para>Signal handling can be configured (printing, ignoring).
+ </para>
+ </listitem>
+ <listitem>
+ <para>Execution can be controlled (continue, step, next, stepi, etc).
+ </para>
+ </listitem>
+ <listitem>
+ <para>Program execution can be interrupted using Control-C.</para>
+ </listitem>
+ </itemizedlist>
+
+<para>And so on. Refer to the GDB user manual for a complete
+description of GDB's functionality.
+</para>
+
+</sect2>
+
+<sect2 id="manual-core-adv.gdbserver-commandhandling"
+ xreflabel="Monitor command handling by the Valgrind gdbserver">
+<title>Monitor command handling by the Valgrind gdbserver</title>
+
+<para> The Valgrind gdbserver provides additional Valgrind-specific
+functionality via "monitor commands". Such monitor commands can
+be sent from the GDB command line or from the shell command line. See
+<xref linkend="manual-core-adv.valgrind-monitor-commands"/> for the list
+of the Valgrind core monitor commands.
+</para>
+
+<para>Each tool can also provide tool-specific monitor commands.
+An example of a tool specific monitor command is the Memcheck monitor
+command <computeroutput>mc.leak_check any full
+reachable</computeroutput>. This requests a full reporting of the
+allocated memory blocks. To have this leak check executed, use the gdb
+command:
+<screen><![CDATA[
+(gdb) monitor mc.leak_check any full reachable
+]]></screen>
+</para>
+
+<para>GDB will send the <computeroutput>mc.leak_check</computeroutput>
+command to the Valgrind gdbserver. The Valgrind gdbserver will
+execute the monitor command itself, if it recognises it to be a Valgrind core
+monitor command. If it is not recognised as such, it is assumed to
+be tool-specific and is handed to the tool for execution. For example:
+</para>
+<programlisting><![CDATA[
+(gdb) monitor mc.leak_check any full reachable
+==2418== 100 bytes in 1 blocks are still reachable in loss record 1 of 1
+==2418== at 0x4006E9E: malloc (vg_replace_malloc.c:236)
+==2418== by 0x804884F: main (prog.c:88)
+==2418==
+==2418== LEAK SUMMARY:
+==2418== definitely lost: 0 bytes in 0 blocks
+==2418== indirectly lost: 0 bytes in 0 blocks
+==2418== possibly lost: 0 bytes in 0 blocks
+==2418== still reachable: 100 bytes in 1 blocks
+==2418== suppressed: 0 bytes in 0 blocks
+==2418==
+(gdb)
+]]></programlisting>
+
+<para>As with other GDB commands, the Valgrind gdbserver will accept
+abbreviated monitor command names and arguments, as long as the given
+abbreviation is unambiguous. For example, the above
+<computeroutput>mc.leak_check</computeroutput>
+command can also be typed as:
+<screen><![CDATA[
+(gdb) mo mc.l a f r
+]]></screen>
+
+The letters <computeroutput>mo</computeroutput> are recognised by GDB as being
+an abbreviation for <computeroutput>monitor</computeroutput>. So GDB sends the
+string <computeroutput>mc.l a f r</computeroutput> to the Valgrind
+gdbserver. The letters provided in this string are unambiguous for the
+Valgrind gdbserver. This therefore gives the same output as the
+unabbreviated command and arguments. If the provided abbreviation is
+ambiguous, the Valgrind gdbserver will report the list of commands (or
+argument values) that can match:
+<programlisting><![CDATA[
+(gdb) mo mc. a r f
+mc. can match mc.get_vbits mc.leak_check mc.make_memory mc.check_memory
+(gdb)
+]]></programlisting>
+</para>
+
+<para>Instead of sending a monitor command from GDB, you can also send
+these from a shell command line. For example, the following command
+lines, when given in a shell, will cause the same leak search to be executed
+by the process 3145:
+<screen><![CDATA[
+vgdb --pid=3145 mc.leak_check any full reachable
+vgdb --pid=3145 mc.l a f r
+]]></screen></para>
+
+<para>Note that the Valgrind gdbserver automatically continues the
+execution of the program after a standalone invocation of
+vgdb. Monitor commands sent from GDB do not cause the program to
+continue: the program execution is controlled explicitly using GDB
+commands such as "continue" or "next".</para>
+
+</sect2>
+
+<sect2 id="manual-core-adv.gdbserver-threads"
+ xreflabel="Valgrind gdbserver thread information">
+<title>Valgrind gdbserver thread information</title>
+
+<para>Valgrind's gdbserver enriches the output of the
+GDB <computeroutput>info threads</computeroutput> command
+with Valgrind-specific information.
+The operating system's thread number is followed
+by Valgrind's internal index for that thread ("tid") and by
+the Valgrind scheduler thread state:</para>
+
+<programlisting><![CDATA[
+(gdb) info threads
+ 4 Thread 6239 (tid 4 VgTs_Yielding) 0x001f2832 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
+* 3 Thread 6238 (tid 3 VgTs_Runnable) make_error (s=0x8048b76 "called from London") at prog.c:20
+ 2 Thread 6237 (tid 2 VgTs_WaitSys) 0x001f2832 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
+ 1 Thread 6234 (tid 1 VgTs_Yielding) main (argc=1, argv=0xbedcc274) at prog.c:105
+(gdb)
+]]></programlisting>
+
+</sect2>
+
+<sect2 id="manual-core-adv.gdbserver-shadowregisters"
+ xreflabel="Examining and modifying Valgrind shadow registers">
+<title>Examining and modifying Valgrind shadow registers</title>
+
+<para> When the option <option>--vgdb-shadow-registers=yes</option> is
+given, the Valgrind gdbserver will let GDB examine and/or modify
+Valgrind's shadow registers. GDB version 7.1 or later is needed for this
+to work.</para>
+
+<para>For each CPU register, the Valgrind core maintains two
+shadow registers. These shadow registers can be accessed from
+GDB by giving a postfix <computeroutput>s1</computeroutput>
+or <computeroutput>s2</computeroutput> for respectively the first
+and second shadow registers. For example, the x86 register
+<computeroutput>eax</computeroutput> and its two shadow
+registers can be examined using the following commands:</para>
+
+<programlisting><![CDATA[
+(gdb) p $eax
+$1 = 0
+(gdb) p $eaxs1
+$2 = 0
+(gdb) p $eaxs2
+$3 = 0
+(gdb)
+]]></programlisting>
+
+</sect2>
+
+
+<sect2 id="manual-core-adv.gdbserver-limitations"
+ xreflabel="Limitations of the Valgrind gdbserver">
+<title>Limitations of the Valgrind gdbserver</title>
+
+<para>Debugging with the Valgrind gdbserver is very similar to native
+debugging. Valgrind's gdbserver implementation is quite
+complete, and so provides most of the GDB debugging functionality. There
+are however some limitations and peculiarities:</para>
+ <itemizedlist>
+ <listitem>
+ <para>Precision of "stop-at" commands.</para>
+ <para>
+ GDB commands such as "step", "next", "stepi", breakpoints
+ and watchpoints, will stop the execution of the process. With
+ the option <option>--vgdb=yes</option>, the process might not
+ stop at the exact requested instruction. Instead, it might
+ continue execution of the current basic block and stop at one
+ of the following basic blocks. This is linked to the fact that
+ Valgrind gdbserver has to instrument a block to allow stopping
+ at the exact instruction requested. Currently,
+ re-instrumentation the block currently being executed is not
+ supported. So, if the action requested by GDB (e.g. single
+ stepping or inserting a breakpoint) implies re-instrumentation
+ of the current block, the GDB action may not be executed
+ precisely.
+ </para>
+ <para>
+ This limitation applies when the basic block
+ currently being executed has not yet been instrumented for debugging.
+ This typically happens when the gdbserver is activated due to the
+ tool reporting an error or to a watchpoint. If the gdbserver
+ block has been activated following a breakpoint, or if a
+ breakpoint has been inserted in the block before its execution,
+ then the block has already been instrumented for debugging.
+ </para>
+ <para>
+ If you use the option <option>--vgdb=full</option>, then GDB
+ "stop-at" commands will be obeyed precisely. The
+ downside is that this requires each instruction to be
+ instrumented with an additional call to a gdbserver helper
+ function, which gives considerable overhead compared to
+ <option>--vgdb=no</option>. Option <option>--vgdb=yes</option>
+ has neglectible overhead compared
+ to <option>--vgdb=no</option>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>Hardware watchpoint support by the Valgrind
+ gdbserver.</para>
+
+ <para> The Valgrind gdbserver can simulate hardware watchpoints
+ if the selected tool provides support for it. Currently,
+ only Memcheck provides hardware watchpoint simulation. The
+ hardware watchpoint simulation provided by Memcheck is much
+ faster that GDB software watchpoints, which are implemented by
+ GDB checking the value of the watched zone(s) after each
+ instruction. Hardware watchpoint simulation also provides read
+ watchpoints. The hardware watchpoint simulation by Memcheck has
+ some limitations compared to real hardware
+ watchpoints. However, the number and length of simulated
+ watchpoints are not limited.
+ </para>
+ <para>Typically, the number of (real) hardware watchpoints is
+ limited. For example, the x86 architecture supports a maximum of
+ 4 hardware watchpoints, each watchpoint watching 1, 2, 4 or 8
+ bytes. The Valgrind gdbserver does not have any limitation on the
+ number of simulated hardware watchpoints. It also has no
+ limitation on the length of the memory zone being
+ watched. However, GDB currently does not understand that
+ Valgrind gdbserver watchpoints have no length limit. A GDB patch
+ providing a command "set remote hardware-watchpoint-length-limit"
+ has been developped. Integration of this patch into GDB would
+ allow full use of the flexibility of the Valgrind gdbserver's
+ simulated hardware watchpoints.
+ </para>
+ <para> Memcheck implements hardware watchpoint simulation by
+ marking the watched address ranges as being unaddressable. When
+ a hardware watchpoint is removed, the range is marked as
+ addressable and defined. Hardware watchpoint simulation of
+ addressable-but-undefined memory zones works properly, but has
+ the undesirable side effect of marking the zone as defined when
+ the watchpoint is removed.
+ </para>
+ <para>Write watchpoints might not be reported at the
+ exact instruction that writes the monitored area,
+ unless option <option>--vgdb=full</option> is given. Read watchpoints
+ will always be reported at the exact instruction reading the
+ watched memory.
+ </para>
+ <para> It is better to avoid using hardware watchpoint of not
+ addressable (yet) memory: in such a case, gdb will fallback to
+ extremely slow software watchpoints. Also, if you do not quit gdb
+ between two debugging sessions, the hardware watchpoints of the
+ previous sessions will be re-inserted as software watchpoints if
+ the watched memory zone is not addressable at program startup.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>Stepping inside shared libraries on ARM.</para>
+ <para>For unknown reasons, stepping inside shared
+ libraries on ARM may fail. A workaround is to use the
+ <computeroutput>ldd</computeroutput> command
+ to find the list of shared libraries and their loading address
+ and inform GDB of the loading address using the GDB command
+ "add-symbol-file". Example:
+ <programlisting><![CDATA[
+(gdb) shell ldd ./prog
+ libc.so.6 => /lib/libc.so.6 (0x4002c000)
+ /lib/ld-linux.so.3 (0x40000000)
+(gdb) add-symbol-file /lib/libc.so.6 0x4002c000
+add symbol table from file "/lib/libc.so.6" at
+ .text_addr = 0x4002c000
+(y or n) y
+Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
+(gdb)
+]]></programlisting>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>GDB version needed for ARM and PPC32/64.</para>
+ <para>You must use a GDB version which is able to read XML
+ target description sent by a gdbserver. This is the standard setup
+ if GDB was configured and built "expat"
+ library. If your gdb was not configured with XML support, it
+ will report an error message when using the "target"
+ command. Debugging will not work because GDB will then not be
+ able to fetch the registers from the Valgrind gdbserver.
+ For ARM programs using the Thumb instruction set, you must use
+ a GDB version of 7.1 or later, as earlier versions have problems
+ with next/step/breakpoints in Thumb code.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>Stack unwinding on PPC32/PPC64. </para>
+ <para>On PPC32/PPC64, stack unwinding for leaf functions
+ (functions that do not call any other functions) works properly
+ only when you give the option
+ <option>--vex-iropt-precise-memory-exns=yes</option>.
+ You must also pass this option in order to get a precise stack when
+ a signal is trapped by GDB.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>Breakpoints encountered multiple times.</para>
+ <para>Some instructions (e.g. x86 "rep movsb")
+ are translated by Valgrind using a loop. If a breakpoint is placed
+ on such an instruction, the breakpoint will be encountered
+ multiple times -- once for each step of the "implicit" loop
+ implementing the instruction.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>Execution of Inferior function calls by the Valgrind
+ gdbserver.</para>
+
+ <para>GDB allows the user to "call" functions inside the process
+ being debugged. Such calls are named "inferior calls" in the GDB
+ terminology. A typical use of an inferior call is to execute
+ a function that prints a human-readable version of a complex data
+ structure. To make an inferior call, use the GDB "print" command
+ followed by the function to call and its arguments. As an
+ example, the following gdb command causes an inferior call to the
+ libc "printf" function to be executed by the process
+ being debugged:
+ </para>
+ <programlisting><![CDATA[
+(gdb) p printf("process being debugged has pid %d\n", getpid())
+$5 = 36
+(gdb)
+]]></programlisting>
+
+ <para>The Valgrind gdbserver supports inferior function calls.
+ Whilst an inferior call is running, the Valgrind tool will report
+ errors as usual. If you do not want to have such errors stop the
+ execution of the inferior call, you can
+ use <computeroutput>vg.set vgdb-error</computeroutput> to set a
+ big value before the call, then manually reset it to its original
+ value when the call is complete.</para>
+
+ <para>To execute inferior calls, GDB changes registers such as
+ the program counter, and then continues the execution of the
+ program. In a multithreaded program, all threads are continued,
+ not just the thread instructed to make the inferior call. If
+ another thread reports an error or encounters a breakpoint, the
+ evaluation of the inferior call is abandoned.</para>
+
+ <para>Note that inferior function calls are a powerful GDB
+ feature, but should be used with caution. For example, if
+ the program being debugged is stopped inside the function "printf",
+ forcing a recursive call to printf via an inferior call will
+ very probably create problems. The Valgrind tool might also add
+ another level of complexity to inferior calls, e.g. by reporting
+ tool errors during the Inferior call or due to the
+ instrumentation done.
+ </para>
+
+ </listitem>
+
+ <listitem>
+ <para>Connecting to or interrupting a Valgrind process blocked in
+ a system call.</para>
+
+ <para>Connecting to or interrupting a Valgrind process blocked in
+ a system call requires the "ptrace" system call to be usable.
+ This may be disabled in your kernel for security reasons.</para>
+
+ <para>When running your program, Valgrind's scheduler
+ periodically checks whether there is any work to be handled by
+ the gdbserver. Unfortunately this check is only done if at least
+ one thread of the process is runnable. If all the threads of the
+ process are blocked in a system call, then the checks do not
+ happen, and the Valgrind scheduler will not invoke the gdbserver.
+ In such a case, the vgdb relay application will "force" the
+ gdbserver to be invoked, without the intervention of the Valgrind
+ scheduler.
+ </para>
+
+ <para>Such forced invocation of the Valgrind gdbserver is
+ implemented by vgdb using ptrace system calls. On a properly
+ implemented kernel, the ptrace calls done by vgdb will not
+ influence the behaviour of the program running under Valgrind.
+ If however they do, giving the
+ option <option>--max-invoke-ms=0</option> to the vgdb relay
+ application will disable the usage of ptrace calls. The
+ consequence of disabling ptrace usage in vgdb is that a Valgrind
+ process blocked in a system call cannot be woken up or
+ interrupted from GDB until it executes enough basic blocks to let
+ the Valgrind scheduler's normal checking take effect.
+ </para>
+
+ <para>When ptrace is disabled in vgdb, you can increase the
+ responsiveness of the Valgrind gdbserver to commands or
+ interrupts by giving a lower value to the
+ option <option>--vgdb-poll</option>. If your application is
+ blocked in system calls most of the time, using a very low value
+ for <option>--vgdb-poll</option> will cause a the gdbserver to be
+ invoked sooner. The gdbserver polling done by Valgrind's
+ scheduler is very efficient, so the increased polling frequency
+ should not cause significant performance degradation.
+ </para>
+
+ <para>When ptrace is disabled in vgdb, a query packet sent by GDB
+ may take significant time to be handled by the Valgrind
+ gdbserver. In such cases, GDB might encounter a protocol
+ timeout. To avoid this,
+ you can increase the value of the timeout by using the GDB
+ command "set remotetimeout".
+ </para>
+
+ <para>Ubuntu versions 10.10 and later may restrict the scope of
+ ptrace to the children of the process calling ptrace. As the
+ Valgrind process is not a child of vgdb, such restricted scoping
+ causes the ptrace calls to fail. To avoid that, when Valgrind
+ gdbserver receives the first packet from a vgdb, it calls
+ <computeroutput>prctl(PR_SET_PTRACER, vgdb_pid, 0, 0,
+ 0)</computeroutput> to ensure vgdb can reliably use ptrace.
+ Once <computeroutput>vgdb_pid</computeroutput> has been marked as
+ a ptracer, vgdb can then properly force the invocation of
+ Valgrind gdbserver when needed. To ensure the vgdb is set as a
+ ptracer before the Valgrind process gets blocked in a system
+ call, connect your GDB to the Valgrind gdbserver at startup by
+ passing <option>--vgdb-error=0</option> to Valgrind.</para>
+
+ <para>Note that
+ this "set ptracer" technique does not solve the problem in the
+ case where a standalone vgdb process wants to connect to the
+ gdbserver, since the first command to be sent by a standalone
+ vgdb must wake up the Valgrind process before Valgrind gdbserver
+ will mark vgdb as a ptracer.
+ </para>
+
+ <para>Unblocking a processes blocked in a system calls is not
+ currently implemented on Mac OS X. So you cannot connect to or
+ interrupt a process blocked in a system call on Mac OS X.
+ </para>
+
+ </listitem>
+
+ <listitem>
+ <para>Changing register values.</para>
+ <para>The Valgrind gdbserver will only modify the values of the a
+ thread's registers when the thread is in status Runnable or
+ Yielding. In other states (typically, WaitSys), attempts to
+ change register values will fail. Amongst other things, this
+ means that inferior calls are not executed for a thread which is
+ in a system call, since the Valgrind gdbserver does not implement
+ system call restart.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>Unsupported GDB functionality.</para>
+ <para>GDB provides a lot of debugging functionality and not all
+ of it is supported. Specifically, the following are not
+ supported: reversible debugging and tracepoints.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>Unknown limitations or problems.</para>
+ <para>The combination of GDB, Valgrind and the Valgrind gdbserver
+ probably has unknown other limitations and problems. If you
+ encounter strange or unexpected behaviour, feel free to report a
+ bug. But first please verify that the limitation or problem is
+ not inherent to GDB or the GDB remote protocol. You may be able
+ to do so by checking the behaviour when using standard gdbserver
+ part of the GDB package.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+</sect2>
+
+<sect2 id="manual-core-adv.vgdb"
+ xreflabel="vgdb">
+<title>vgdb command line options</title>
+<para> Usage: <computeroutput>vgdb [OPTION]... [[-c] COMMAND]...</computeroutput></para>
+
+<para> vgdb ("Valgrind to GDB") is a small program that is used as an
+intermediary between GDB and Valgrind. Normally you should not use it
+directly. It has two usage modes:
+</para>
+<orderedlist>
+ <listitem id="manual-core-adv.vgdb-standalone" xreflabel="vgdb standalone">
+ <para>As a standalone utility, it is used from a shell command
+ line to send monitor commands to a process running under
+ Valgrind. For this usage, the vgdb OPTION(s) must be followed by
+ the monitor command to send. To send more than one command,
+ separate them with the <option>-c</option> option.
+ </para>
+ </listitem>
+
+ <listitem id="manual-core-adv.vgdb-relay" xreflabel="vgdb relay">
+ <para>In combination with GDB "target remote |" command, it is
+ used as the relay application between GDB and the Valgrind
+ gdbserver. For this usage, only OPTION(s) can be given, but no
+ COMMAND can be given.
+ </para>
+ </listitem>
+
+</orderedlist>
+
+<para><computeroutput>vgdb</computeroutput> accepts the following
+options:</para>
+<itemizedlist>
+ <listitem>
+ <para><option>--pid=<number></option>: specifies the PID of
+ the process to which vgdb must connect to. This option is useful
+ in case more than one Valgrind gdbserver can be connected to. If
+ the <option>--pid</option> argument is not given and multiple
+ Valgrind gdbserver processes are running, vgdb will report the
+ list of such processes and then exit.</para>
+ </listitem>
+
+ <listitem>
+ <para><option>--vgdb-prefix</option> must be given to both
+ Valgrind and vgdb if you want to change the default prefix for the
+ FIFOs (named pipes) used for communication between the Valgrind
+ gdbserver and vgdb. </para>
+ </listitem>
+
+ <listitem>
+ <para><option>--max-invoke-ms=<number></option> gives the
+ number of milliseconds after which vgdb will force the invocation
+ of gdbserver embedded in valgrind. The default value is 100
+ milliseconds. A value of 0 disables forced invocation.
+ </para>
+
+ <para>If you specify a large value, you might need to increase the
+ GDB "remotetimeout" value from its default value of 2 seconds.
+ You should ensure that the timeout (in seconds) is
+ bigger than the <option>--max-invoke-ms</option> value. For
+ example, for <option>--max-invoke-ms=5000</option>, the following
+ GDB command is suitable:
+ <screen><![CDATA[
+ (gdb) set remotetimeout 6
+ ]]></screen>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><option>--wait=<number></option> instructs vgdb to
+ search for available Valgrind gdbservers for the specified number
+ of seconds. This makes it possible start a vgdb process
+ before starting the Valgrind gdbserver with which you intend the
+ vgdb to communicate. This option is useful when used in
+ conjunction with a <option>--vgdb-prefix</option> that is
+ unique to the process you want to wait for.
+ Also, if you use the <option>--wait</option> argument in the GDB
+ "target remote" command, you must set the GDB remotetimeout to a
+ value bigger than the --wait argument value. See option
+ <option>--max-invoke-ms</option> (just above)
+ for an example of setting the remotetimeout value.</para>
+ </listitem>
+
+ <listitem>
+ <para><option>-c</option> To give more than one command, separate
+ the commands by an option <option>-c</option>. Example:
+ <screen><![CDATA[
+vgdb vg.set log_output -c mc.leak_check any
+]]></screen></para>
+ </listitem>
+
+ <listitem>
+ <para><option>-d</option> instructs vgdb to produce debugging
+ output. Give multiple <option>-d</option> args to increase the
+ verbosity.</para>
+ </listitem>
+
+ <listitem>
+ <para><option>-D</option> instructs vgdb to show the state of the
+ shared memory used by the Valgrind gdbserver. vgdb will exit after
+ having shown the Valgrind gdbserver shared memory state.</para>
+ </listitem>
+
+ <listitem>
+ <para><option>-l</option> instructs vgdb to report the list of
+ the Valgrind gdbserver processes running and then exit.</para>
+ </listitem>
+</itemizedlist>
+
+</sect2>
+
+
+<sect2 id="manual-core-adv.valgrind-monitor-commands"
+ xreflabel="Valgrind monitor commands">
+<title>Valgrind monitor commands</title>
+
+<para>The Valgrind monitor commands are available regardless of the
+Valgrind tool selected. They can be sent either from a shell command
+line, by using a standalone vgdb, or from GDB, by using GDB's
+"monitor" command.</para>
+
+<itemizedlist>
+ <listitem>
+ <para><varname>help [debug]</varname> instructs Valgrind's gdbserver
+ to give the list of all monitor commands of the Valgrind core and
+ of the tool. The optional "debug" argument tells to also give help
+ for the monitor commands aimed at Valgrind internals debugging.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><varname>vg.info all_errors</varname> shows all errors found
+ so far.</para>
+ </listitem>
+ <listitem>
+ <para><varname>vg.info last_error</varname> shows the last error
+ found.</para>
+ </listitem>
+
+ <listitem>
+ <para><varname>vg.info n_errs_found</varname> shows the number of
+ errors found so far and the current value of the
+ <option>--vgdb-error</option>
+ argument.</para>
+ </listitem>
+
+ <listitem>
+ <para><varname>vg.set {gdb_output | log_output |
+ mixed_output}</varname> allows redirection of the Valgrind output
+ (e.g. the errors detected by the tool). The default setting is
+ <computeroutput>mixed_output</computeroutput>.</para>
+
+ <para>With <computeroutput>mixed_output</computeroutput>, the
+ Valgrind output goes to the Valgrind log (typically stderr) while
+ the output of the interactive GDB monitor commands (e.g.
+ <computeroutput>vg.info last_error</computeroutput>)
+ is displayed by GDB.</para>
+
+ <para>With <computeroutput>gdb_output</computeroutput>, both the
+ Valgrind output and the interactive gdb monitor commands output are
+ displayed by gdb.</para>
+
+ <para>With <computeroutput>log_output</computeroutput>, both the
+ Valgrind output and the interactive gdb monitor commands output go
+ to the Valgrind log.</para>
+ </listitem>
+
+ <listitem>
+ <para><varname>vg.wait [ms (default 0)]</varname> instructs
+ Valgrind gdbserver to sleep "ms" milli-seconds and then
+ continue. When sent from a standalone vgdb, if this is the last
+ command, the Valgrind process will continue the execution of the
+ guest process. The typical usage of this is to use vgdb to send a
+ "no-op" command to a Valgrind gdbserver so as to continue the
+ execution of the guess process.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><varname>vg.kill</varname> requests the gdbserver to kill
+ the process. This can be used from a standalone vgdb to properly
+ kill a Valgrind process which is currently expecting a vgdb
+ connection.</para>
+ </listitem>
+
+ <listitem>
+ <para><varname>vg.set vgdb-error <errornr></varname>
+ dynamically changes the value of the
+ <option>--vgdb-error</option> argument. A
+ typical usage of this is to start with
+ <option>--vgdb-error=0</option> on the
+ command line, then set a few breakpoints, set the vgdb-error value
+ to a huge value and continue execution.</para>
+ </listitem>
+
+</itemizedlist>
+
+<para>The following Valgrind monitor commands are useful for
+investigating the behaviour of Valgrind or its gdbserver in case of
+problems or bugs.</para>
+
+<itemizedlist>
+
+ <listitem>
+ <para><varname>vg.info gdbserver_status</varname> shows the
+ gdbserver status. In case of problems (e.g. of communications),
+ this showns the values of some relevant Valgrind gdbserver internal
+ variables. Note that the variables related to breakpoints and
+ watchpoints (e.g. the number of breakpoint addresses and the number of
+ watchpoints) will be zero, as GDB by default removes all
+ watchpoints and breakpoints when execution stops, and re-inserts
+ them when resuming the execution of the debugged process. You can
+ change this gdb behaviour by using the GDB command
+ <computeroutput>set breakpoint always-inserted on</computeroutput>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><varname>vg.info memory</varname> shows the statistics of
+ Valgrind's internal heap management. If
+ option <option>--profile-heap=yes</option> was given, detailed
+ statistics will be output.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><varname>vg.set debuglog <intvalue></varname> sets the
+ Valgrind debug log level to <intvalue>. This allows to
+ dynamically change the log level of Valgrind e.g. when a problem
+ is detected.</para>
+ </listitem>
+
+ <listitem>
+ <para><varname>vg.translate <address>
+ [<traceflags>]</varname> shows the translation of the block
+ containing <computeroutput>address</computeroutput> with the given
+ trace flags. The <computeroutput>traceflags</computeroutput> value
+ bit pattern with similar meaning to Valgrind's
+ <option>--trace-flags</option> option. It can be given
+ in hexadecimal (e.g. 0x20) or decimal (e.g. 32) or in binary 1s
+ and 0s bit (e.g. 0b00100000). The default value of the traceflags
+ is 0b00100000, corresponding to "show after instrumentation".
+ The output of this command always goes to the Valgrind
+ log.</para>
+ <para>The additional bit flag 0b100000000 (bit 8)
+ has no equivalent in the <option>--trace-flags</option> option.
+ It enables tracing of the gdbserver specific instrumentation. Note
+ that this bit 8 can only enable the addition of gdbserver
+ instrumentation in the trace. Setting it to 0 will not
+ disable the tracing of the gdbserver instrumentation if it is
+ active for some other reason, for example because there is a breakpoint at
+ this address or because gdbserver is in single stepping
+ mode.</para>
+ </listitem>
+
+</itemizedlist>
+
+</sect2>
+
+</sect1>
+
+
+
+
+
<sect1 id="manual-core-adv.wrapping" xreflabel="Function Wrapping">
<title>Function wrapping</title>
Modified: trunk/docs/xml/manual-core.xml
===================================================================
--- trunk/docs/xml/manual-core.xml 2011-06-17 08:14:00 UTC (rev 11820)
+++ trunk/docs/xml/manual-core.xml 2011-06-17 08:31:22 UTC (rev 11821)
@@ -730,15 +730,15 @@
or <option>--vgdb=full</option> is specified. This
allows an external GNU GDB debugger
to control and debug your program when it runs on Valgrind. See
- <xref linkend="manual-core.gdbserver"/> for a detailed
+ <xref linkend="manual-core-adv.gdbserver"/> for a detailed
description.
</para>
<para> If the embedded gdbserver is enabled but no gdb is
- currently being used, the <xref linkend="manual-core.vgdb"/>
+ currently being used, the <xref linkend="manual-core-adv.vgdb"/>
command line utility can send "monitor commands" to Valgrind
from a shell. The Valgrind core provides a set of
- <xref linkend="manual-core.valgrind-monitor-commands"/>. A tool
+ <xref linkend="manual-core-adv.valgrind-monitor-commands"/>. A tool
can optionally provide tool specific monitor commands, which are
documented in the tool specific chapter.
</para>
@@ -1822,923 +1822,7 @@
</sect1>
-<sect1 id="manual-core.gdbserver"
- xreflabel="Debugging your program using Valgrind's gdbserver and GDB">
-<title>Debugging your program using Valgrind gdbserver and GDB</title>
-<para>A program running under Valgrind is not executed directly by the
-CPU. Instead it runs on a synthetic CPU provided by Valgrind. This is
-why a debugger cannot debug your program when it runs on Valgrind.
-</para>
-<para>
-This section describes how GDB can interact with the
-Valgrind gdbserver to provide a fully debuggable program under
-Valgrind. Used in this way, GDB also provides an interactive usage of
-Valgrind core or tool functionalities, including incremental leak search
-under Memcheck and on-demand Massif snapshot production.
-</para>
-
-<sect2 id="manual-core.gdbserver-simple"
- xreflabel="gdbserver simple example">
-<title>Quick Start: debugging in 3 steps</title>
-
-<para>If you want to debug a program with GDB when using the Memcheck
-tool, start Valgrind the following way:
-<screen><![CDATA[
-valgrind --vgdb=yes --vgdb-error=0 prog
-]]></screen></para>
-
-<para>In another window, start a GDB the following way:
-<screen><![CDATA[
-gdb prog
-]]></screen></para>
-
-<para>Then give the following command to GDB:
-<screen><![CDATA[
-(gdb) target remote | vgdb
-]]></screen></para>
-
-<para>You can now debug your program e.g. by inserting a breakpoint
-and then using the GDB <computeroutput>continue</computeroutput>
-command.</para>
-
-<para>This quick start information is enough for basic usage of the
-Valgrind gdbserver. The sections below describe more advanced
-functionality provided by the combination of Valgrind and GDB. Note
-that the command line flag <option>--vgdb=yes</option> can be omitted,
-as this is the default value.
-</para>
-
-</sect2>
-
-<sect2 id="manual-core.gdbserver-concept"
- xreflabel="gdbserver">
-<title>Valgrind gdbserver overall organisation</title>
-<para>The GNU GDB debugger is typically used to debug a process
-running on the same machine. In this mode, GDB uses system calls to
-control and query the program being debugged. This works well, but
-only allows GDB to debug a program running on the same computer.
-</para>
-
-<para>GDB can also debug processes running on a different computer.
-To achieve this, GDB defines a protocol (that is, a set of query and
-reply packets) that facilitates fetching the value of memory or
-registers, setting breakpoints, etc. A gdbserver is an implementation
-of this "GDB remote debugging" protocol. To debug a process running
-on a remote computer, a gdbserver (sometimes called a GDB stub)
-must run at the remote computer side.
-</para>
-
-<para>The Valgrind core provides a built-in gdbserver implementation,
-which is activated using <option>--vgdb=yes</option>
-or <option>--vgdb=full</option>. This gdbserver allows the process
-running on Valgrind's synthetic CPU to be debugged remotely.
-GDB sends protocol query packets (such as "get register contents") to
-the Valgrind embedded gdbserver. The gdbserver executes the queries
-(for example, it will get the register values of the synthetic CPU)
-and gives the results back to GDB.
-</para>
-
-<para>GDB can use various kinds of channels (TCP/IP, serial line, etc)
-to communicate with the gdbserver. In the case of Valgrind's
-gdbserver, communication is done via a pipe and a small helper program
-called <xref linkend="manual-core.vgdb"/>, which acts as an
-intermediary. If no GDB is in use, vgdb can also be
-used to send monitor commands to the Valgrind gdbserver from a shell
-command line.
-</para>
-
-</sect2>
-
-<sect2 id="manual-core.gdbserver-gdb"
- xreflabel="Connecting GDB to a Valgrind gdbserver">
-<title>Connecting GDB to a Valgrind gdbserver</title>
-<para>To debug a program "<filename>prog</filename>" running under
-Valgrind, you must ensure that the Valgrind gdbserver is activated by
-specifying either <option>--vgdb=yes</option>
-or <option>--vgdb=full</option>). A secondary command line option,
-<option>--vgdb-error=number</option>, can be used to tell the gdbserver
-only to become active once the specified number of errors have been
-reported. A value of zero will therefore cause
-the gdbserver to become active at startup, which allows you to
-insert breakpoints before starting the run. For example:
-<screen><![CDATA[
-valgrind --tool=memcheck --vgdb=yes --vgdb-error=0 ./prog
-]]></screen></para>
-
-<para>The Valgrind gdbserver is invoked at startup
-and indicates it is waiting for a connection from a GDB:</para>
-
-<programlisting><![CDATA[
-==2418== Memcheck, a memory error detector
-==2418== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
-==2418== Using Valgrind-3.7.0.SVN and LibVEX; rerun with -h for copyright info
-==2418== Command: ./prog
-==2418==
-==2418== (action at startup) vgdb me ...
-]]></programlisting>
-
-
-<para>GDB (in another shell) can then be connected to the Valgrind gdbserver.
-For this, GDB must be started on the program <filename>prog</filename>:
-<screen><![CDATA[
-gdb ./prog
-]]></screen></para>
-
-
-<para>You then indicate to GDB that you want to debug a remote target:
-<screen><![CDATA[
-(gdb) target remote | vgdb
-]]></screen>
-GDB then starts a vgdb relay application to communicate with the
-Valgrind embedded gdbserver:</para>
-
-<programlisting><![CDATA[
-(gdb) target remote | vgdb
-Remote debugging using | vgdb
-relaying data between gdb and process 2418
-Reading symbols from /lib/ld-linux.so.2...done.
-Reading symbols from /usr/lib/debug/lib/ld-2.11.2.so.debug...done.
-Loaded symbols for /lib/ld-linux.so.2
-[Switching to Thread 2418]
-0x001f2850 in _start () from /lib/ld-linux.so.2
-(gdb)
-]]></programlisting>
-
-<para>Note that vgdb is provided as part of the Valgrind
-distribution. You do not need to install it separately.</para>
-
-<para>If vgdb detects that there are multiple Valgrind gdbservers that
-can be connected to, it will list all such servers and their PIDs, and
-then exit. You can then reissue the GDB "target" command, but
-specifying the PID the process you want to debug:
-</para>
-
-<programlisting><![CDATA[
-(gdb) target remote | vgdb
-Remote debugging using | vgdb
-no --pid= arg given and multiple valgrind pids found:
-use --pid=2479 for valgrind --tool=memcheck --vgdb=yes --vgdb-error=0 ./prog
-use --pid=2481 for valgrind --tool=memcheck --vgdb=yes --vgdb-error=0 ./prog
-use --pid=2483 for valgrind --vgdb=yes --vgdb-error=0 ./another_prog
-Remote communication error: Resource temporarily unavailable.
-(gdb) target remote | vgdb --pid=2479
-Remote debugging using | vgdb --pid=2479
-relaying data between gdb and process 2479
-Reading symbols from /lib/ld-linux.so.2...done.
-Reading symbols from /usr/lib/debug/lib/ld-2.11.2.so.debug...done.
-Loaded symbols for /lib/ld-linux.so.2
-[Switching to Thread 2479]
-0x001f2850 in _start () from /lib/ld-linux.so.2
-(gdb)
-]]></programlisting>
-
-<para>Once GDB is connected to the Valgrind gdbserver, it can be used
-in the same way as if you were debugging the program natively:</para>
- <itemizedlist>
- <listitem>
- <para>Breakpoints can be inserted or deleted.</para>
- </listitem>
- <listitem>
- <para>Variables and register values can be examined or modified.
- </para>
- </listitem>
- <listitem>
- <para>Signal handling can be configured (printing, ignoring).
- </para>
- </listitem>
- <listitem>
- <para>Execution can be controlled (continue, step, next, stepi, etc).
- </para>
- </listitem>
- <listitem>
- <para>Program execution can be interrupted using Control-C.</para>
- </listitem>
- </itemizedlist>
-
-<para>And so on. Refer to the GDB user manual for a complete
-description of GDB's functionality.
-</para>
-
-</sect2>
-
-<sect2 id="manual-core.gdbserver-commandhandling"
- xreflabel="Monitor command handling by the Valgrind gdbserver">
-<title>Monitor command handling by the Valgrind gdbserver</title>
-
-<para> The Valgrind gdbserver provides additional Valgrind-specific
-functionality via "monitor commands". Such monitor commands can
-be sent from the GDB command line or from the shell command line. See
-<xref linkend="manual-core.valgrind-monitor-commands"/> for the list
-of the Valgrind core monitor commands.
-</para>
-
-<para>Each tool can also provide tool-specific monitor commands.
-An example of a tool specific monitor command is the Memcheck monitor
-command <computeroutput>mc.leak_check any full
-reachable</computeroutput>. This requests a full reporting of the
-allocated memory blocks. To have this leak check executed, use the gdb
-command:
-<screen><![CDATA[
-(gdb) monitor mc.leak_check any full reachable
-]]></screen>
-</para>
-
-<para>GDB will send the <computeroutput>mc.leak_check</computeroutput>
-command to the Valgrind gdbserver. The Valgrind gdbserver will
-execute the monitor command itself, if it recognises it to be a Valgrind core
-monitor command. If it is not recognised as such, it is assumed to
-be tool-specific and is handed to the tool for execution. For example:
-</para>
-<programlisting><![CDATA[
-(gdb) monitor mc.leak_check any full reachable
-==2418== 100 bytes in 1 blocks are still reachable in loss record 1 of 1
-==2418== at 0x4006E9E: malloc (vg_replace_malloc.c:236)
-==2418== by 0x804884F: main (prog.c:88)
-==2418==
-==2418== LEAK SUMMARY:
-==2418== definitely lost: 0 bytes in 0 blocks
-==2418== indirectly lost: 0 bytes in 0 blocks
-==2418== possibly lost: 0 bytes in 0 blocks
-==2418== still reachable: 100 bytes in 1 blocks
-==2418== suppressed: 0 bytes in 0 blocks
-==2418==
-(gdb)
-]]></programlisting>
-
-<para>As with other GDB commands, the Valgrind gdbserver will accept
-abbreviated monitor command names and arguments, as long as the given
-abbreviation is unambiguous. For example, the above
-<computeroutput>mc.leak_check</computeroutput>
-command can also be typed as:
-<screen><![CDATA[
-(gdb) mo mc.l a f r
-]]></screen>
-
-The letters <computeroutput>mo</computeroutput> are recognised by GDB as being
-an abbreviation for <computeroutput>monitor</computeroutput>. So GDB sends the
-string <computeroutput>mc.l a f r</computeroutput> to the Valgrind
-gdbserver. The letters provided in this string are unambiguous for the
-Valgrind gdbserver. This therefore gives the same output as the
-unabbreviated command and arguments. If the provided abbreviation is
-ambiguous, the Valgrind gdbserver will report the list of commands (or
-argument values) that can match:
-<programlisting><![CDATA[
-(gdb) mo mc. a r f
-mc. can match mc.get_vbits mc.leak_check mc.make_memory mc.check_memory
-(gdb)
-]]></programlisting>
-</para>
-
-<para>Instead of sending a monitor command from GDB, you can also send
-these from a shell command line. For example, the following command
-lines, when given in a shell, will cause the same leak search to be executed
-by the process 3145:
-<screen><![CDATA[
-vgdb --pid=3145 mc.leak_check any full reachable
-vgdb --pid=3145 mc.l a f r
-]]></screen></para>
-
-<para>Note that the Valgrind gdbserver automatically continues the
-execution of the program after a standalone invocation of
-vgdb. Monitor commands sent from GDB do not cause the program to
-continue: the program execution is controlled explicitly using GDB
-commands such as "continue" or "next".</para>
-
-</sect2>
-
-<sect2 id="manual-core.gdbserver-threads"
- xreflabel="Valgrind gdbserver thread information">
-<title>Valgrind gdbserver thread information</title>
-
-<para>Valgrind's gdbserver enriches the output of the
-GDB <computeroutput>info threads</computeroutput> command
-with Valgrind-specific information.
-The operating system's thread number is followed
-by Valgrind's internal index for that thread ("tid") and by
-the Valgrind scheduler thread state:</para>
-
-<programlisting><![CDATA[
-(gdb) info threads
- 4 Thread 6239 (tid 4 VgTs_Yielding) 0x001f2832 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
-* 3 Thread 6238 (tid 3 VgTs_Runnable) make_error (s=0x8048b76 "called from London") at prog.c:20
- 2 Thread 6237 (tid 2 VgTs_WaitSys) 0x001f2832 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
- 1 Thread 6234 (tid 1 VgTs_Yielding) main (argc=1, argv=0xbedcc274) at prog.c:105
-(gdb)
-]]></programlisting>
-
-</sect2>
-
-<sect2 id="manual-core.gdbserver-shadowregisters"
- xreflabel="Examining and modifying Valgrind shadow registers">
-<title>Examining and modifying Valgrind shadow registers</title>
-
-<para> When the option <option>--vgdb-shadow-registers=yes</option> is
-given, the Valgrind gdbserver will let GDB examine and/or modify
-Valgrind's shadow registers. GDB version 7.1 or later is needed for this
-to work.</para>
-
-<para>For each CPU register, the Valgrind core maintains two
-shadow registers. These shadow registers can be accessed from
-GDB by giving a postfix <computeroutput>s1</computeroutput>
-or <computeroutput>s2</computeroutput> for respectively the first
-and second shadow registers. For example, the x86 register
-<computeroutput>eax</computeroutput> and its two shadow
-registers can be examined using the following commands:</para>
-
-<programlisting><![CDATA[
-(gdb) p $eax
-$1 = 0
-(gdb) p $eaxs1
-$2 = 0
-(gdb) p $eaxs2
-$3 = 0
-(gdb)
-]]></programlisting>
-
-</sect2>
-
-
-<sect2 id="manual-core.gdbserver-limitations"
- xreflabel="Limitations of the Valgrind gdbserver">
-<title>Limitations of the Valgrind gdbserver</title>
-
-<para>Debugging with the Valgrind gdbserver is very similar to native
-debugging. Valgrind's gdbserver implementation is quite
-complete, and so provides most of the GDB debugging functionality. There
-are however some limitations and peculiarities:</para>
- <itemizedlist>
- <listitem>
- <para>Precision of "stop-at" commands.</para>
- <para>
- GDB commands such as "step", "next", "stepi", breakpoints
- and watchpoints, will stop the execution of the process. With
- the option <option>--vgdb=yes</option>, the process might not
- stop at the exact requested instruction. Instead, it might
- continue execution of the current basic block and stop at one
- of the following basic blocks. This is linked to the fact that
- Valgrind gdbserver has to instrument a block to allow stopping
- at the exact instruction requested. Currently,
- re-instrumentation the block currently being executed is not
- supported. So, if the action requested by GDB (e.g. single
- stepping or inserting a breakpoint) implies re-instrumentation
- of the current block, the GDB action may not be executed
- precisely.
- </para>
- <para>
- This limitation applies when the basic block
- currently being executed has not yet been instrumented for debugging.
- This typically happens when the gdbserver is activated due to the
- tool reporting an error or to a watchpoint. If the gdbserver
- block has been activated following a breakpoint, or if a
- breakpoint has been inserted in the block before its execution,
- then the block has already been instrumented for debugging.
- </para>
- <para>
- If you use the option <option>--vgdb=full</option>, then GDB
- "stop-at" commands will be obeyed precisely. The
- downside is that this requires each instruction to be
- instrumented with an additional call to a gdbserver helper
- function, which gives considerable overhead compared to
- <option>--vgdb=no</option>. Option <option>--vgdb=yes</option>
- has neglectible overhead compared
- to <option>--vgdb=no</option>.
- </para>
- </listitem>
-
- <listitem>
- <para>Hardware watchpoint support by the Valgrind
- gdbserver.</para>
-
- <para> The Valgrind gdbserver can simulate hardware watchpoints
- if the selected tool provides support for it. Currently,
- only Memcheck provides hardware watchpoint simulation. The
- hardware watchpoint simulation provided by Memcheck is much
- faster that GDB software watchpoints, which are implemented by
- GDB checking the value of the watched zone(s) after each
- instruction. Hardware watchpoint simulation also provides read
- watchpoints. The hardware watchpoint simulation by Memcheck has
- some limitations compared to real hardware
- watchpoints. However, the number and length of simulated
- watchpoints are not limited.
- </para>
- <para>Typically, the number of (real) hardware watchpoints is
- limited. For example, the x86 architecture supports a maximum of
- 4 hardware watchpoints, each watchpoint watching 1, 2, 4 or 8
- bytes. The Valgrind gdbserver does not have any limitation on the
- number of simulated hardware watchpoints. It also has no
- limitation on the length of the memory zone being
- watched. However, GDB currently does not understand that
- Valgrind gdbserver watchpoints have no length limit. A GDB patch
- providing a command "set remote hardware-watchpoint-length-limit"
- has been developped. Integration of this patch into GDB would
- allow full use of the flexibility of the Valgrind gdbserver's
- simulated hardware watchpoints.
- </para>
- <para> Memcheck implements hardware watchpoint simulation by
- marking the watched address ranges as being unaddressable. When
- a hardware watchpoint is removed, the range is marked as
- addressable and defined. Hardware watchpoint simulation of
- addressable-but-undefined memory zones works properly, but has
- the undesirable side effect of marking the zone as defined when
- the watchpoint is removed.
- </para>
- <para>Write watchpoints might not be reported at the
- exact instruction that writes the monitored area,
- unless option <option>--vgdb=full</option> is given. Read watchpoints
- will always be reported at the exact instruction reading the
- watched memory.
- </para>
- <para> It is better to avoid using hardware watchpoint of not
- addressable (yet) memory: in such a case, gdb will fallback to
- extremely slow software watchpoints. Also, if you do not quit gdb
- between two debugging sessions, the hardware watchpoints of the
- previous sessions will be re-inserted as software watchpoints if
- the watched memory zone is not addressable at program startup.
- </para>
- </listitem>
-
- <listitem>
- <para>Stepping inside shared libraries on ARM.</para>
- <para>For unknown reasons, stepping inside shared
- libraries on ARM may fail. A workaround is to use the
- <computeroutput>ldd</computeroutput> command
- to find the list of shared libraries and their loading address
- and inform GDB of the loading address using the GDB command
- "add-symbol-file". Example:
- <programlisting><![CDATA[
-(gdb) shell ldd ...
[truncated message content] |
|
From: <sv...@va...> - 2011-06-17 08:18:52
|
Author: sewardj
Date: 2011-06-17 09:14:00 +0100 (Fri, 17 Jun 2011)
New Revision: 11820
Log:
Edits for the GDBserver documentation.
Modified:
trunk/docs/xml/manual-core.xml
Modified: trunk/docs/xml/manual-core.xml
===================================================================
--- trunk/docs/xml/manual-core.xml 2011-06-16 11:37:21 UTC (rev 11819)
+++ trunk/docs/xml/manual-core.xml 2011-06-17 08:14:00 UTC (rev 11820)
@@ -725,10 +725,11 @@
<option><![CDATA[--vgdb=<no|yes|full> [default: yes] ]]></option>
</term>
<listitem>
- <para>Valgrind will enable its embedded gdbserver if value yes
- or full is given. This allows an
- external <computeroutput>gdb</computeroutput> debuggger to debug
- your program running under Valgrind. See
+ <para>Valgrind will provide "gdbserver" functionality when
+ <option>--vgdb=yes</option>
+ or <option>--vgdb=full</option> is specified. This
+ allows an external GNU GDB debugger
+ to control and debug your program when it runs on Valgrind. See
<xref linkend="manual-core.gdbserver"/> for a detailed
description.
</para>
@@ -742,7 +743,8 @@
documented in the tool specific chapter.
</para>
- <para>The value 'full' has a significant overhead
+ <para><option>--vgdb=full</option> incurs
+ significant performance overheads.
</para>
</listitem>
</varlistentry>
@@ -753,12 +755,15 @@
</term>
<listitem>
<para> Use this option when the Valgrind gdbserver is enabled with
- <option>--vgdb</option> yes or full value. Tools that report
- errors will invoke the embedded gdbserver for each error above
- number. The value 0 will cause gdbserver to be invoked before
- executing your program. This is typically used to insert gdb
- breakpoints before execution, and will also work with tools that
- do not report errors, such as Massif.
+ <option>--vgdb=yes</option> or <option>--vgdb=full</option>.
+ Tools that report errors will wait
+ for "<computeroutput>number</computeroutput>" errors to be
+ reported before freezing the program and waiting for you to
+ connect with GDB. It follows that a value of zero will cause
+ the gdbserver to be started before your program is executed.
+ This is typically used to insert GDB breakpoints before
+ execution, and also works with tools that do not report
+ errors, such as Massif.
</para>
</listitem>
</varlistentry>
@@ -1818,107 +1823,111 @@
<sect1 id="manual-core.gdbserver"
- xreflabel="Debugging your program using Valgrind gdbserver and gdb">
-<title>Debugging your program using Valgrind gdbserver and gdb</title>
+ xreflabel="Debugging your program using Valgrind's gdbserver and GDB">
+<title>Debugging your program using Valgrind gdbserver and GDB</title>
<para>A program running under Valgrind is not executed directly by the
-CPU. It rather runs on a synthetic CPU provided by Valgrind. This is
-why a debugger cannot debug your program under Valgrind the usual way.
+CPU. Instead it runs on a synthetic CPU provided by Valgrind. This is
+why a debugger cannot debug your program when it runs on Valgrind.
</para>
<para>
-This section describes the special way gdb can interact with the
+This section describes how GDB can interact with the
Valgrind gdbserver to provide a fully debuggable program under
-Valgrind. Used in this way, gdb also provides an interactive usage of
-Valgrind core or tool functionalities (such as incremental leak search
-under Memcheck, on-demand Massif snapshot production, ...).
+Valgrind. Used in this way, GDB also provides an interactive usage of
+Valgrind core or tool functionalities, including incremental leak search
+under Memcheck and on-demand Massif snapshot production.
</para>
<sect2 id="manual-core.gdbserver-simple"
xreflabel="gdbserver simple example">
-<title>Quick Start : debugging in 3 steps</title>
+<title>Quick Start: debugging in 3 steps</title>
-<para>If you want to debug a program with gdb when using Memcheck
+<para>If you want to debug a program with GDB when using the Memcheck
tool, start Valgrind the following way:
<screen><![CDATA[
valgrind --vgdb=yes --vgdb-error=0 prog
]]></screen></para>
-<para>In another window, start a gdb the following way:
+<para>In another window, start a GDB the following way:
<screen><![CDATA[
gdb prog
]]></screen></para>
-<para>Then give the following command to gdb:
+<para>Then give the following command to GDB:
<screen><![CDATA[
(gdb) target remote | vgdb
]]></screen></para>
<para>You can now debug your program e.g. by inserting a breakpoint
-and then using the gdb 'continue' command.</para>
+and then using the GDB <computeroutput>continue</computeroutput>
+command.</para>
-<para> The above quick start is enough for a basic usage of the
-Valgrind gdbserver. Read the sections below to learn about the
-advanced functionalities provided by the combination of Valgrind and
-gdb. Note that the option --vgdb=yes can be omitted, as this is the
-default value.
+<para>This quick start information is enough for basic usage of the
+Valgrind gdbserver. The sections below describe more advanced
+functionality provided by the combination of Valgrind and GDB. Note
+that the command line flag <option>--vgdb=yes</option> can be omitted,
+as this is the default value.
</para>
</sect2>
<sect2 id="manual-core.gdbserver-concept"
xreflabel="gdbserver">
-<title>Valgrind gdbserver concept</title>
-<para>The gdb debugger is typically used to debug a process running on
-the same machine : gdb uses system calls to do actions such as read
-the values of the process variables or registers. This technique only
-allows gdb to debug a program running on the same computer.
+<title>Valgrind gdbserver overall organisation</title>
+<para>The GNU GDB debugger is typically used to debug a process
+running on the same machine. In this mode, GDB uses system calls to
+control and query the program being debugged. This works well, but
+only allows GDB to debug a program running on the same computer.
</para>
-<para>Gdb can also debug processes running on a different computer.
-For this, gdb defines a protocol (i.e. a set of query and reply
-packets) that allows to e.g. fetch the value of memory or registers,
-to set breakpoints, etc. A gdbserver is an implementation of this
-'gdb remote debugging' protocol. To debug a process running on a
-remote computer, a gdbserver (sometimes also called a gdb stub) must
-run at the remote computer side.
+<para>GDB can also debug processes running on a different computer.
+To achieve this, GDB defines a protocol (that is, a set of query and
+reply packets) that facilitates fetching the value of memory or
+registers, setting breakpoints, etc. A gdbserver is an implementation
+of this "GDB remote debugging" protocol. To debug a process running
+on a remote computer, a gdbserver (sometimes called a GDB stub)
+must run at the remote computer side.
</para>
-<para>The Valgrind core integrates an embedded gdbserver
-implementation, which is activated using <option>--vgdb=yes</option>
-or <option>--vgdb=full</option>. This gdbserver allows the process
-running on the Valgrind synthetic CPU to be debugged 'remotely' by gdb
-: gdb sends protocol query packets (such as 'get registers values') to
-the Valgrind embedded gdbserver. The embedded gdbserver executes the
-queries (for example, it will get the registers values of the
-synthetic CPU) and give the result back to gdb.
+<para>The Valgrind core provides a built-in gdbserver implementation,
+which is activated using <option>--vgdb=yes</option>
+or <option>--vgdb=full</option>. This gdbserver allows the process
+running on Valgrind's synthetic CPU to be debugged remotely.
+GDB sends protocol query packets (such as "get register contents") to
+the Valgrind embedded gdbserver. The gdbserver executes the queries
+(for example, it will get the register values of the synthetic CPU)
+and gives the results back to GDB.
</para>
-<para> Gdb can use various ways (tcp/ip, serial line, ...) to send and
-receive the remote protocol packets to a gdbserver. In the case of the
-Valgrind gdbserver, gdb communicates using a pipe and the
-<xref linkend="manual-core.vgdb"/> command as a relay application. If
-no gdb is currently being used, vgdb can also be used to send monitor
-commands to the Valgrind gdbserver from the shell command line.
+<para>GDB can use various kinds of channels (TCP/IP, serial line, etc)
+to communicate with the gdbserver. In the case of Valgrind's
+gdbserver, communication is done via a pipe and a small helper program
+called <xref linkend="manual-core.vgdb"/>, which acts as an
+intermediary. If no GDB is in use, vgdb can also be
+used to send monitor commands to the Valgrind gdbserver from a shell
+command line.
</para>
</sect2>
<sect2 id="manual-core.gdbserver-gdb"
- xreflabel="Connecting gdb to a Valgrind gdbserver">
-<title>Connecting gdb to a Valgrind gdbserver</title>
-<para>To debug a program <filename>prog</filename> running under
-Valgrind, ensures that the Valgrind gdbserver is activated
-(i.e. --vgdb=yes or --vgdb=full). The option
-<![CDATA[--vgdb-error=<number> ]]> can be used to ask an invocation of
-the gdbserver for each error above number. A zero value will cause an
-invocation of the Valgrind gdbserver at startup, allowing to insert
-breakpoints before starting the execution. Example:
+ xreflabel="Connecting GDB to a Valgrind gdbserver">
+<title>Connecting GDB to a Valgrind gdbserver</title>
+<para>To debug a program "<filename>prog</filename>" running under
+Valgrind, you must ensure that the Valgrind gdbserver is activated by
+specifying either <option>--vgdb=yes</option>
+or <option>--vgdb=full</option>). A secondary command line option,
+<option>--vgdb-error=number</option>, can be used to tell the gdbserver
+only to become active once the specified number of errors have been
+reported. A value of zero will therefore cause
+the gdbserver to become active at startup, which allows you to
+insert breakpoints before starting the run. For example:
<screen><![CDATA[
valgrind --tool=memcheck --vgdb=yes --vgdb-error=0 ./prog
]]></screen></para>
-<para>With the above command, the Valgrind gdbserver is invoked at startup
-and indicates it is waiting for a connection from a gdb:</para>
+<para>The Valgrind gdbserver is invoked at startup
+and indicates it is waiting for a connection from a GDB:</para>
<programlisting><![CDATA[
==2418== Memcheck, a memory error detector
@@ -1930,18 +1939,18 @@
]]></programlisting>
-<para>A gdb in another window can then be connected to the Valgrind gdbserver.
-For this, gdb must be started on the program <filename>prog</filename>:
+<para>GDB (in another shell) can then be connected to the Valgrind gdbserver.
+For this, GDB must be started on the program <filename>prog</filename>:
<screen><![CDATA[
gdb ./prog
]]></screen></para>
-<para>You then indicate to gdb that a remote target debugging is to be done:
+<para>You then indicate to GDB that you want to debug a remote target:
<screen><![CDATA[
(gdb) target remote | vgdb
]]></screen>
-gdb then starts a vgdb relay application to communicate with the
+GDB then starts a vgdb relay application to communicate with the
Valgrind embedded gdbserver:</para>
<programlisting><![CDATA[
@@ -1956,10 +1965,13 @@
(gdb)
]]></programlisting>
-<para> In case vgdb detects that multiple Valgrind gdbserver can be connected
-to, it will exit after reporting the list of the debuggable Valgrind
-processes and their PIDs. You can then relaunch the gdb 'target' command, but
-specifying the process id of the process you want to debug:
+<para>Note that vgdb is provided as part of the Valgrind
+distribution. You do not need to install it separately.</para>
+
+<para>If vgdb detects that there are multiple Valgrind gdbservers that
+can be connected to, it will list all such servers and their PIDs, and
+then exit. You can then reissue the GDB "target" command, but
+specifying the PID the process you want to debug:
</para>
<programlisting><![CDATA[
@@ -1981,33 +1993,31 @@
(gdb)
]]></programlisting>
-<para>Once gdb is connected to the Valgrind gdbserver, gdb can be used
-similarly to a native debugging session:</para>
+<para>Once GDB is connected to the Valgrind gdbserver, it can be used
+in the same way as if you were debugging the program natively:</para>
<itemizedlist>
<listitem>
- <para> Breakpoints can be inserted or deleted. </para>
+ <para>Breakpoints can be inserted or deleted.</para>
</listitem>
<listitem>
- <para> Variables and registers values can be examined or modified.
+ <para>Variables and register values can be examined or modified.
</para>
</listitem>
<listitem>
- <para> Signal handling can be configured (printing, ignoring, ...).
+ <para>Signal handling can be configured (printing, ignoring).
</para>
</listitem>
<listitem>
- <para> Execution can be controlled (continue, step, next, stepi, ...).
+ <para>Execution can be controlled (continue, step, next, stepi, etc).
</para>
</listitem>
<listitem>
- <para> Program execution can be interrupted using Control-C. </para>
+ <para>Program execution can be interrupted using Control-C.</para>
</listitem>
- <listitem>
- <para> ... </para>
- </listitem>
</itemizedlist>
-<para> Refer to the gdb user manual for a complete list of gdb functionalities.
+<para>And so on. Refer to the GDB user manual for a complete
+description of GDB's functionality.
</para>
</sect2>
@@ -2016,28 +2026,29 @@
xreflabel="Monitor command handling by the Valgrind gdbserver">
<title>Monitor command handling by the Valgrind gdbserver</title>
-<para> The Valgrind gdbserver provides a set of additional specific
-functionalities through "monitor commands". Such monitor commands can
-be sent from the gdb command line or from the shell command line. See
+<para> The Valgrind gdbserver provides additional Valgrind-specific
+functionality via "monitor commands". Such monitor commands can
+be sent from the GDB command line or from the shell command line. See
<xref linkend="manual-core.valgrind-monitor-commands"/> for the list
of the Valgrind core monitor commands.
</para>
-<para> Each tool can also provide tool specific monitor commands. An
-example of a tool specific monitor command is the Memcheck monitor
+<para>Each tool can also provide tool-specific monitor commands.
+An example of a tool specific monitor command is the Memcheck monitor
command <computeroutput>mc.leak_check any full
reachable</computeroutput>. This requests a full reporting of the
-allocated memory blocks. To have this leak check executed, use the gdb
+allocated memory blocks. To have this leak check executed, use the gdb
command:
<screen><![CDATA[
(gdb) monitor mc.leak_check any full reachable
]]></screen>
</para>
-<para> gdb will send the mc.leak_check command to the Valgrind gdbserver. The
-Valgrind gdbserver will either execute the monitor command itself (if
-it recognises a Valgrind core monitor command) or let the tool execute the
-tool specific monitor commands:
+<para>GDB will send the <computeroutput>mc.leak_check</computeroutput>
+command to the Valgrind gdbserver. The Valgrind gdbserver will
+execute the monitor command itself, if it recognises it to be a Valgrind core
+monitor command. If it is not recognised as such, it is assumed to
+be tool-specific and is handed to the tool for execution. For example:
</para>
<programlisting><![CDATA[
(gdb) monitor mc.leak_check any full reachable
@@ -2055,20 +2066,21 @@
(gdb)
]]></programlisting>
-<para> Like for the gdb commands, the Valgrind gdbserver will accept
+<para>As with other GDB commands, the Valgrind gdbserver will accept
abbreviated monitor command names and arguments, as long as the given
-abbreviation is non ambiguous. For example, the above mc.leak_check
+abbreviation is unambiguous. For example, the above
+<computeroutput>mc.leak_check</computeroutput>
command can also be typed as:
<screen><![CDATA[
(gdb) mo mc.l a f r
]]></screen>
-The letters <computeroutput>mo</computeroutput> are recognised by gdb as being
-<computeroutput>monitor</computeroutput>. So, gdb sends the
+The letters <computeroutput>mo</computeroutput> are recognised by GDB as being
+an abbreviation for <computeroutput>monitor</computeroutput>. So GDB sends the
string <computeroutput>mc.l a f r</computeroutput> to the Valgrind
-gdbserver. The letters provided in this string are unambiguous for the
-Valgrind gdbserver. So, this will give the same output as the non
-abbreviated command and arguments. If the provided abbreviation is
+gdbserver. The letters provided in this string are unambiguous for the
+Valgrind gdbserver. This therefore gives the same output as the
+unabbreviated command and arguments. If the provided abbreviation is
ambiguous, the Valgrind gdbserver will report the list of commands (or
argument values) that can match:
<programlisting><![CDATA[
@@ -2078,10 +2090,10 @@
]]></programlisting>
</para>
-<para> Instead of sending a monitor command from gdb, you can also
-send these from a shell command line. For example, the below command lines
-given in a shell will cause the same leak search to be executed by the
-process 3145:
+<para>Instead of sending a monitor command from GDB, you can also send
+these from a shell command line. For example, the following command
+lines, when given in a shell, will cause the same leak search to be executed
+by the process 3145:
<screen><![CDATA[
vgdb --pid=3145 mc.leak_check any full reachable
vgdb --pid=3145 mc.l a f r
@@ -2089,20 +2101,22 @@
<para>Note that the Valgrind gdbserver automatically continues the
execution of the program after a standalone invocation of
-vgdb. Monitor commands sent from gdb do not cause the program to
-continue: the program execution is controlled explicitely using gdb
-commands such as 'continue' or 'next'.</para>
+vgdb. Monitor commands sent from GDB do not cause the program to
+continue: the program execution is controlled explicitly using GDB
+commands such as "continue" or "next".</para>
</sect2>
<sect2 id="manual-core.gdbserver-threads"
- xreflabel="Valgrind gdbserver thread info">
-<title>Valgrind gdbserver thread info</title>
+ xreflabel="Valgrind gdbserver thread information">
+<title>Valgrind gdbserver thread information</title>
-<para> The Valgrind gdbserver enriches the output of the
-gdb <computeroutput>info threads</computeroutput> with Valgrind
-specific information. The operating system thread number is followed
-by the Valgrind 'tid' and the Valgrind scheduler thread state:</para>
+<para>Valgrind's gdbserver enriches the output of the
+GDB <computeroutput>info threads</computeroutput> command
+with Valgrind-specific information.
+The operating system's thread number is followed
+by Valgrind's internal index for that thread ("tid") and by
+the Valgrind scheduler thread state:</para>
<programlisting><![CDATA[
(gdb) info threads
@@ -2119,15 +2133,16 @@
xreflabel="Examining and modifying Valgrind shadow registers">
<title>Examining and modifying Valgrind shadow registers</title>
-<para> When the option <![CDATA[--vgdb-shadow-registers=yes ]]> is
-given, the Valgrind gdbserver will let gdb examine and/or modify the
-Valgrind shadow registers. A gdb version >= 7.1 is needed for this
+<para> When the option <option>--vgdb-shadow-registers=yes</option> is
+given, the Valgrind gdbserver will let GDB examine and/or modify
+Valgrind's shadow registers. GDB version 7.1 or later is needed for this
to work.</para>
-<para> For each CPU register, the Valgrind core maintains two
+<para>For each CPU register, the Valgrind core maintains two
shadow registers. These shadow registers can be accessed from
-gdb by giving a postfix s1 or s2 for respectively the first
-and second shadow registers. As an example, the x86 register
+GDB by giving a postfix <computeroutput>s1</computeroutput>
+or <computeroutput>s2</computeroutput> for respectively the first
+and second shadow registers. For example, the x86 register
<computeroutput>eax</computeroutput> and its two shadow
registers can be examined using the following commands:</para>
@@ -2149,39 +2164,45 @@
<title>Limitations of the Valgrind gdbserver</title>
<para>Debugging with the Valgrind gdbserver is very similar to native
-debugging. The implementation of the Valgrind gdbserver is quite
-complete, and so provides most of the gdb debugging facilities. There
-are however some limitations or particularities described in details
-in this section:</para>
+debugging. Valgrind's gdbserver implementation is quite
+complete, and so provides most of the GDB debugging functionality. There
+are however some limitations and peculiarities:</para>
<itemizedlist>
<listitem>
- <para> Precision of 'stopped at instruction'.</para>
- <para>Gdb commands such as 'step', 'next', 'stepi', breakpoints,
- watchpoints, ... will stop the execution of the process. With
- the option --vgdb=yes, the process might not stop at the exact
- instruction needed. Instead, it might continue execution of the
- current block and stop at one of the following blocks. This is
- linked to the fact that Valgrind gdbserver has to instrument a
- block to allow stopping at the exact instruction requested.
- Currently, re-instrumenting the current block being executed is
- not supported. So, if the action requested by gdb (e.g. single
- stepping or inserting a breakpoint) implies to re-instrument the
- current block, the gdb action might not be executed precisely.
+ <para>Precision of "stop-at" commands.</para>
+ <para>
+ GDB commands such as "step", "next", "stepi", breakpoints
+ and watchpoints, will stop the execution of the process. With
+ the option <option>--vgdb=yes</option>, the process might not
+ stop at the exact requested instruction. Instead, it might
+ continue execution of the current basic block and stop at one
+ of the following basic blocks. This is linked to the fact that
+ Valgrind gdbserver has to instrument a block to allow stopping
+ at the exact instruction requested. Currently,
+ re-instrumentation the block currently being executed is not
+ supported. So, if the action requested by GDB (e.g. single
+ stepping or inserting a breakpoint) implies re-instrumentation
+ of the current block, the GDB action may not be executed
+ precisely.
</para>
- <para> This limitation will be triggered when the current block
- being executed has not (yet) been instrumented for debugging.
- This typically happens when the gdbserver is activated due to the
- tool reporting an error or to a watchpoint. If the gdbserver
- block has been activated following a breakpoint (or if a
- breakpoint has been inserted in the block before its execution),
- then the block has already been instrumented for debugging.
+ <para>
+ This limitation applies when the basic block
+ currently being executed has not yet been instrumented for debugging.
+ This typically happens when the gdbserver is activated due to the
+ tool reporting an error or to a watchpoint. If the gdbserver
+ block has been activated following a breakpoint, or if a
+ breakpoint has been inserted in the block before its execution,
+ then the block has already been instrumented for debugging.
</para>
- <para> If you use the option --vgdb=full, then gdb 'stop actions'
- will always be obeyed precisely, but this implies that each
- instruction will be instrumented with an additional call to a
- gdbserver helper function, which implies some overhead compared
- to --vgdb=no. Option --vgdb=yes has neglectible overhead compared
- to --vgdb=no.
+ <para>
+ If you use the option <option>--vgdb=full</option>, then GDB
+ "stop-at" commands will be obeyed precisely. The
+ downside is that this requires each instruction to be
+ instrumented with an additional call to a gdbserver helper
+ function, which gives considerable overhead compared to
+ <option>--vgdb=no</option>. Option <option>--vgdb=yes</option>
+ has neglectible overhead compared
+ to <option>--vgdb=no</option>.
</para>
</listitem>
@@ -2190,42 +2211,44 @@
gdbserver.</para>
<para> The Valgrind gdbserver can simulate hardware watchpoints
- (but only if the tool provides the support for this). Currently,
- only Memcheck provides hardware watchpoint simulation. The
+ if the selected tool provides support for it. Currently,
+ only Memcheck provides hardware watchpoint simulation. The
hardware watchpoint simulation provided by Memcheck is much
- faster that gdb software watchpoints (which are implemented by
- gdb checking the value of the watched zone(s) after each
- instruction). Hardware watchpoint simulation also provides read
+ faster that GDB software watchpoints, which are implemented by
+ GDB checking the value of the watched zone(s) after each
+ instruction. Hardware watchpoint simulation also provides read
watchpoints. The hardware watchpoint simulation by Memcheck has
- some limitations compared to the real hardware
+ some limitations compared to real hardware
watchpoints. However, the number and length of simulated
watchpoints are not limited.
</para>
- <para> Typically, the number of (real) hardware watchpoint is
+ <para>Typically, the number of (real) hardware watchpoints is
limited. For example, the x86 architecture supports a maximum of
4 hardware watchpoints, each watchpoint watching 1, 2, 4 or 8
- bytes. The Valgrind gdbserver does not have a limitation on the
+ bytes. The Valgrind gdbserver does not have any limitation on the
number of simulated hardware watchpoints. It also has no
limitation on the length of the memory zone being
- watched. However, gdb currently does not (yet) understand that
- Valgrind gdbserver watchpoints have no length limit. A gdb patch
- providing a command 'set remote hardware-watchpoint-length-limit'
- has been developped. The integration of this patch in gdb would
- allow to fully use the flexibility of the Valgrind gdbserver
- simulated hardware watchpoints (is there a gdb developper reading
- this ?).
+ watched. However, GDB currently does not understand that
+ Valgrind gdbserver watchpoints have no length limit. A GDB patch
+ providing a command "set remote hardware-watchpoint-length-limit"
+ has been developped. Integration of this patch into GDB would
+ allow full use of the flexibility of the Valgrind gdbserver's
+ simulated hardware watchpoints.
</para>
<para> Memcheck implements hardware watchpoint simulation by
- marking the watched zone(s) as being unaddressable. In case a
- hardware watchpoint is removed, the zone is marked as addressable
- and defined. Hardware watchpoint simulation of addressable
- undefined memory zones will properly work, but will have as a
- side effect to mark the zone as defined when the watchpoint is
- removed.</para>
- <para> Write watchpoints might not be reported at the instruction
- which is modifying the value unless option --vgdb=full is
- given. Read watchpoints will always be reported at the exact
- instruction reading the watched memory.</para>
+ marking the watched address ranges as being unaddressable. When
+ a hardware watchpoint is removed, the range is marked as
+ addressable and defined. Hardware watchpoint simulation of
+ addressable-but-undefined memory zones works properly, but has
+ the undesirable side effect of marking the zone as defined when
+ the watchpoint is removed.
+ </para>
+ <para>Write watchpoints might not be reported at the
+ exact instruction that writes the monitored area,
+ unless option <option>--vgdb=full</option> is given. Read watchpoints
+ will always be reported at the exact instruction reading the
+ watched memory.
+ </para>
<para> It is better to avoid using hardware watchpoint of not
addressable (yet) memory: in such a case, gdb will fallback to
extremely slow software watchpoints. Also, if you do not quit gdb
@@ -2236,14 +2259,15 @@
</listitem>
<listitem>
- <para> Stepping inside shared libraries on ARM.</para>
- <para> For a not (yet?) clear reason, stepping inside a shared
- library on ARM might fail. The bypass is to use the ldd command
+ <para>Stepping inside shared libraries on ARM.</para>
+ <para>For unknown reasons, stepping inside shared
+ libraries on ARM may fail. A workaround is to use the
+ <computeroutput>ldd</computeroutput> command
to find the list of shared libraries and their loading address
- and inform gdb of the loading address using the gdb command
- 'add-symbol-file'. Example (for a ./p executable):
+ and inform GDB of the loading address using the GDB command
+ "add-symbol-file". Example:
<programlisting><![CDATA[
-(gdb) shell ldd ./p
+(gdb) shell ldd ./prog
libc.so.6 => /lib/libc.so.6 (0x4002c000)
/lib/ld-linux.so.3 (0x40000000)
(gdb) add-symbol-file /lib/libc.so.6 0x4002c000
@@ -2257,52 +2281,53 @@
</listitem>
<listitem>
- <para> gdb version needed for ARM and PPC32/64.</para>
- <para> You must use a gdb version which is able to read XML
- target description sent by gdbserver (this is the standard setup
- if the gdb was configured on a computer with the expat
- library). If your gdb was not configured with XML support, it
- will report an error message when using the target
- command. Debugging will not work because gdb will then not be
+ <para>GDB version needed for ARM and PPC32/64.</para>
+ <para>You must use a GDB version which is able to read XML
+ target description sent by a gdbserver. This is the standard setup
+ if GDB was configured and built "expat"
+ library. If your gdb was not configured with XML support, it
+ will report an error message when using the "target"
+ command. Debugging will not work because GDB will then not be
able to fetch the registers from the Valgrind gdbserver.
- For ARM programs using the thumb instruction set, you must use
- a gdb version >= 7.1 as previous versions have problems
- with next/step/breakpoints/... in thumb code.
+ For ARM programs using the Thumb instruction set, you must use
+ a GDB version of 7.1 or later, as earlier versions have problems
+ with next/step/breakpoints in Thumb code.
</para>
</listitem>
<listitem>
- <para> Stack unwinding on PPC32/PPC64. </para>
- <para> On PPC32/PPC64, stack unwinding for leaf functions
- (i.e. functions not calling other functions) does work properly
- only with <option>--vex-iropt-precise-memory-exns=yes</option>.
- You must also pass this option to have a precise stack when
- a signal is trapped by gdb.
+ <para>Stack unwinding on PPC32/PPC64. </para>
+ <para>On PPC32/PPC64, stack unwinding for leaf functions
+ (functions that do not call any other functions) works properly
+ only when you give the option
+ <option>--vex-iropt-precise-memory-exns=yes</option>.
+ You must also pass this option in order to get a precise stack when
+ a signal is trapped by GDB.
</para>
</listitem>
<listitem>
- <para> Breakpoint encountered multiple times. </para>
- <para> Some instructions (e.g. the x86 "rep movsb")
- are translated by Valgrind using a loop. If a breakpoint is placed
+ <para>Breakpoints encountered multiple times.</para>
+ <para>Some instructions (e.g. x86 "rep movsb")
+ are translated by Valgrind using a loop. If a breakpoint is placed
on such an instruction, the breakpoint will be encountered
- multiple times (i.e. once for each step of the "implicit" loop
- implementing the instruction).
+ multiple times -- once for each step of the "implicit" loop
+ implementing the instruction.
</para>
</listitem>
<listitem>
- <para> Execution of Inferior function calls by the Valgrind
- gdbserver. </para>
+ <para>Execution of Inferior function calls by the Valgrind
+ gdbserver.</para>
- <para> gdb allows the user to "call" functions inside the process
- being debugged. Such calls are named 'Inferior calls' in the gdb
- terminology. A typical usage of an 'Inferior call' is to execute
- a function that outputs a readable image of a complex data
- structure. To make an Inferior call, use the gdb 'print' command
- followed by the function to call and its arguments. As an
- example, the following gdb command causes an Inferior call to the
- libc printf function to be executed by (and inside) the process
+ <para>GDB allows the user to "call" functions inside the process
+ being debugged. Such calls are named "inferior calls" in the GDB
+ terminology. A typical use of an inferior call is to execute
+ a function that prints a human-readable version of a complex data
+ structure. To make an inferior call, use the GDB "print" command
+ followed by the function to call and its arguments. As an
+ example, the following gdb command causes an inferior call to the
+ libc "printf" function to be executed by the process
being debugged:
</para>
<programlisting><![CDATA[
@@ -2311,26 +2336,27 @@
(gdb)
]]></programlisting>
- <para>The Valgrind gdbserver accepts Inferior function
- calls. During Inferior calls, the Valgrind tool will report
- errors as usual. If you do not want to have such errors stopping
- the execution of the Inferior call, you can use 'vg.set
- vgdb-error' to set a big value before the call, and reset the
- value after the Inferior call.</para>
+ <para>The Valgrind gdbserver supports inferior function calls.
+ Whilst an inferior call is running, the Valgrind tool will report
+ errors as usual. If you do not want to have such errors stop the
+ execution of the inferior call, you can
+ use <computeroutput>vg.set vgdb-error</computeroutput> to set a
+ big value before the call, then manually reset it to its original
+ value when the call is complete.</para>
- <para>To execute Inferior calls, gdb changes registers such as
+ <para>To execute inferior calls, GDB changes registers such as
the program counter, and then continues the execution of the
- program. In a multi-thread program, all threads are continued,
- not only the thread instructed to make an Inferior call. If
- another thread reports an error or encounters a break, the
- evaluation of the Inferior call is abandonned.</para>
+ program. In a multithreaded program, all threads are continued,
+ not just the thread instructed to make the inferior call. If
+ another thread reports an error or encounters a breakpoint, the
+ evaluation of the inferior call is abandoned.</para>
- <para> Note that Inferior function calls is a powerful gdb
- functionality but it has to be used with caution. For example, if
- the program being debugged is stopped inside the function printf,
- 'forcing' a recursive call to printf via an Inferior call will
- very probably create problems. The Valgrind tool might also add
- another level of complexity to Inferior calls, e.g. by reporting
+ <para>Note that inferior function calls are a powerful GDB
+ feature, but should be used with caution. For example, if
+ the program being debugged is stopped inside the function "printf",
+ forcing a recursive call to printf via an inferior call will
+ very probably create problems. The Valgrind tool might also add
+ another level of complexity to inferior calls, e.g. by reporting
tool errors during the Inferior call or due to the
instrumentation done.
</para>
@@ -2341,105 +2367,111 @@
<para>Connecting to or interrupting a Valgrind process blocked in
a system call.</para>
- <para> Connecting to or interrupting a Valgrind process blocked
- in a system call is depending on ptrace system call, which might
- be disabled on your kernel. </para>
+ <para>Connecting to or interrupting a Valgrind process blocked in
+ a system call requires the "ptrace" system call to be usable.
+ This may be disabled in your kernel for security reasons.</para>
- <para> At regular interval, after having executed some basic
- blocks, the Valgrind scheduler checks if some input is to be
- handled by the Valgrind gdbserver. However, this check is only
- done if at least one thread of the process is executing (enough)
- basic blocks. If all the threads of the process are blocked in a
- system call, then no basic blocks are being executed, and the
- Valgrind scheduler will not invoke the Valgrind gdbserver. In
- such a case, the vgdb relay application will 'force' the Valgrind
+ <para>When running your program, Valgrind's scheduler
+ periodically checks whether there is any work to be handled by
+ the gdbserver. Unfortunately this check is only done if at least
+ one thread of the process is runnable. If all the threads of the
+ process are blocked in a system call, then the checks do not
+ happen, and the Valgrind scheduler will not invoke the gdbserver.
+ In such a case, the vgdb relay application will "force" the
gdbserver to be invoked, without the intervention of the Valgrind
scheduler.
</para>
- <para> Such forced invocation of the Valgrind gdbserver is
- implemented by vgdb using ptrace system calls. On a properly
+ <para>Such forced invocation of the Valgrind gdbserver is
+ implemented by vgdb using ptrace system calls. On a properly
implemented kernel, the ptrace calls done by vgdb will not
- influence the behaviour of the program running under Valgrind. In
- case of unexpected impact, giving the option --max-invoke-ms=0 to
- the vgdb relay application will disable the usage of ptrace
- system call. The consequence of disabling ptrace system call in
- vgdb is that a Valgrind process blocked in a system call cannot
- be waken up or interrupted from gdb till it executes (enough)
- basic blocks to let the scheduler poll invoke the gdbserver..
+ influence the behaviour of the program running under Valgrind.
+ If however they do, giving the
+ option <option>--max-invoke-ms=0</option> to the vgdb relay
+ application will disable the usage of ptrace calls. The
+ consequence of disabling ptrace usage in vgdb is that a Valgrind
+ process blocked in a system call cannot be woken up or
+ interrupted from GDB until it executes enough basic blocks to let
+ the Valgrind scheduler's normal checking take effect.
</para>
- <para>When ptrace is disabled in vgdb, you might increase the
+
+ <para>When ptrace is disabled in vgdb, you can increase the
responsiveness of the Valgrind gdbserver to commands or
- interrupts by giving a lower value to the option --vgdb-poll: if
- your application is most of the time blocked in a system call,
- using a very low value for vgdb-poll will cause a faster
- invocation of gdbserver. As the gdbserver poll done by the
- scheduler is very efficient, the more frequent check by the
- scheduler should not cause significant performance degradation.
+ interrupts by giving a lower value to the
+ option <option>--vgdb-poll</option>. If your application is
+ blocked in system calls most of the time, using a very low value
+ for <option>--vgdb-poll</option> will cause a the gdbserver to be
+ invoked sooner. The gdbserver polling done by Valgrind's
+ scheduler is very efficient, so the increased polling frequency
+ should not cause significant performance degradation.
</para>
- <para>When ptrace is disabled in vgdb, a query packet sent by gdb
- might take a significant time to be handled by the Valgrind
- gdbserver. In such a case, gdb might encounter a protocol
- timeout. To avoid having gdb encountering such a timeout error,
- you can increase the value of this timeout by using the gdb
- command 'set remotetimeout'.
+
+ <para>When ptrace is disabled in vgdb, a query packet sent by GDB
+ may take significant time to be handled by the Valgrind
+ gdbserver. In such cases, GDB might encounter a protocol
+ timeout. To avoid this,
+ you can increase the value of the timeout by using the GDB
+ command "set remotetimeout".
</para>
- <para> Ubuntu version >= 10.10 can also restrict the scope of
- ptrace to the children of the process calling ptrace. As the
- Valgrind process is not a child of vgdb, such restricted scope
- causes ptrace system call to fail. To avoid that, when Valgrind
+ <para>Ubuntu versions 10.10 and later may restrict the scope of
+ ptrace to the children of the process calling ptrace. As the
+ Valgrind process is not a child of vgdb, such restricted scoping
+ causes the ptrace calls to fail. To avoid that, when Valgrind
gdbserver receives the first packet from a vgdb, it calls
- prctl(PR_SET_PTRACER, vgdb_pid, 0, 0, 0) to ensure vgdb can use
- ptrace. Once vgdb_pid has been set as ptracer, vgdb can then
- properly force the invocation of Valgrind gdbserver when
- needed. To ensure the vgdb is set as ptracer before the Valgrind
- process could be blocked in a system call, connect your gdb to
- the Valgrind gdbserver at startup (i.e. use --vgdb-error=0).
- Note that this 'set ptracer' is not solving the problem for the
- connection of a standalone vgdb: the first command to be sent by
- a standalone vgdb must wake up the Valgrind process before
- Valgrind gdbserver will set vgdb as ptracer.
+ <computeroutput>prctl(PR_SET_PTRACER, vgdb_pid, 0, 0,
+ 0)</computeroutput> to ensure vgdb can reliably use ptrace.
+ Once <computeroutput>vgdb_pid</computeroutput> has been marked as
+ a ptracer, vgdb can then properly force the invocation of
+ Valgrind gdbserver when needed. To ensure the vgdb is set as a
+ ptracer before the Valgrind process gets blocked in a system
+ call, connect your GDB to the Valgrind gdbserver at startup by
+ passing <option>--vgdb-error=0</option> to Valgrind.</para>
+
+ <para>Note that
+ this "set ptracer" technique does not solve the problem in the
+ case where a standalone vgdb process wants to connect to the
+ gdbserver, since the first command to be sent by a standalone
+ vgdb must wake up the Valgrind process before Valgrind gdbserver
+ will mark vgdb as a ptracer.
</para>
- <para> Unblocking a process blocked in a system call is
- not implemented on Darwin. So, waiting for vgdb on Darwin to
- be enhanced, you cannot connect/interrupt a process blocked
- in a system call on Darwin.
+ <para>Unblocking a processes blocked in a system calls is not
+ currently implemented on Mac OS X. So you cannot connect to or
+ interrupt a process blocked in a system call on Mac OS X.
</para>
</listitem>
<listitem>
- <para> Changing registers of a thread.</para>
- <para> The Valgrind gdbserver only accepts to modify the values
- of the registers of a thread when the thread is in status
- Runnable or Yielding. In other states (typically, WaitSys), changing
- registers values will not be accepted. This among others ensures
- that Inferior calls are not executed for a thread which is in a
- system call : the Valgrind gdbserver does not implement system
- call restart.
+ <para>Changing register values.</para>
+ <para>The Valgrind gdbserver will only modify the values of the a
+ thread's registers when the thread is in status Runnable or
+ Yielding. In other states (typically, WaitSys), attempts to
+ change register values will fail. Amongst other things, this
+ means that inferior calls are not executed for a thread which is
+ in a system call, since the Valgrind gdbserver does not implement
+ system call restart.
</para>
</listitem>
<listitem>
- <para> gdb functionalities not supported.</para>
- <para> gdb provides an awful lot of debugging functionalities.
- At least the following are not supported: reversible debugging,
- tracepoints.
+ <para>Unsupported GDB functionality.</para>
+ <para>GDB provides a lot of debugging functionality and not all
+ of it is supported. Specifically, the following are not
+ supported: reversible debugging and tracepoints.
</para>
</listitem>
<listitem>
- <para> Unknown limitations or problems.</para>
- <para> The combination of gdb, Valgrind and the Valgrind
- gdbserver has for sure some still unknown other
- limitations/problems but we do not know about these unknown
- limitations/problems :). If you encounter such (annoying)
- limitations or problems, feel free to report a bug. But first
- verify if the limitation or problem is not inherent to gdb or the
- gdb remote protocol e.g. by checking the behaviour with the
- standard gdbserver part of the gdb package.
+ <para>Unknown limitations or problems.</para>
+ <para>The combination of GDB, Valgrind and the Valgrind gdbserver
+ probably has unknown other limitations and problems. If you
+ encounter strange or unexpected behaviour, feel free to report a
+ bug. But first please verify that the limitation or problem is
+ not inherent to GDB or the GDB remote protocol. You may be able
+ to do so by checking the behaviour when using standard gdbserver
+ part of the GDB package.
</para>
</listitem>
@@ -2452,24 +2484,27 @@
<sect1 id="manual-core.vgdb"
xreflabel="vgdb">
<title>vgdb command line options</title>
-<para> Usage: vgdb [OPTION]... [[-c] COMMAND]...</para>
+<para> Usage: <computeroutput>vgdb [OPTION]... [[-c] COMMAND]...</computeroutput></para>
-<para> vgdb (Valgrind to gdb) has two usages:</para>
+<para> vgdb ("Valgrind to GDB") is a small program that is used as an
+intermediary between GDB and Valgrind. Normally you should not use it
+directly. It has two usage modes:
+</para>
<orderedlist>
<listitem id="manual-core.vgdb-standalone" xreflabel="vgdb standalone">
<para>As a standalone utility, it is used from a shell command
line to send monitor commands to a process running under
Valgrind. For this usage, the vgdb OPTION(s) must be followed by
the monitor command to send. To send more than one command,
- separate them with the -c option.
+ separate them with the <option>-c</option> option.
</para>
</listitem>
<listitem id="manual-core.vgdb-relay" xreflabel="vgdb relay">
- <para>In combination with gdb 'target remote |' command, it is
- used as the relay application between gdb and the Valgrind
- gdbserver. For this usage, only OPTION(s) can be given, no
- command can be given.
+ <para>In combination with GDB "target remote |" command, it is
+ used as the relay application between GDB and the Valgrind
+ gdbserver. For this usage, only OPTION(s) can be given, but no
+ COMMAND can be given.
</para>
</listitem>
@@ -2479,34 +2514,34 @@
options:</para>
<itemizedlist>
<listitem>
- <para><option>--pid=<number></option>: specifies the pid of
- the process to which vgdb must connect to. This option is useful
- in case more than one Valgrind gdbserver can be connected to. If
- --pid argument is not given and multiple Valgrind gdbserver
- processes are running, vgdb will report the list of such processes
- and then exit.</para>
+ <para><option>--pid=<number></option>: specifies the PID of
+ the process to which vgdb must connect to. This option is useful
+ in case more than one Valgrind gdbserver can be connected to. If
+ the <option>--pid</option> argument is not given and multiple
+ Valgrind gdbserver processes are running, vgdb will report the
+ list of such processes and then exit.</para>
</listitem>
<listitem>
<para><option>--vgdb-prefix</option> must be given to both
- Valgrind and vgdb utility if you want to change the default prefix
- for the FIFOs communication between the Valgrind gdbserver and
- vgdb. </para>
+ Valgrind and vgdb if you want to change the default prefix for the
+ FIFOs (named pipes) used for communication between the Valgrind
+ gdbserver and vgdb. </para>
</listitem>
<listitem>
<para><option>--max-invoke-ms=<number></option> gives the
- number of milli-seconds after which vgdb will force the invocation
- of gdbserver embedded in valgrind. Default value is 100
- milli-seconds. A value of 0 disables the forced invocation.
+ number of milliseconds after which vgdb will force the invocation
+ of gdbserver embedded in valgrind. The default value is 100
+ milliseconds. A value of 0 disables forced invocation.
</para>
- <para>If you specify a big value here, you might need to increase
- the gdb remote timeout. The default value of the gdb remotetimeout
- is 2 seconds. You should ensure that the gdb remotetimeout (in
- seconds) is bigger than the max-invoke-ms value. For example, for
- a 5000 --max-invoke-ms, the following gdb command will set a value
- big enough:
+ <para>If you specify a large value, you might need to increase the
+ GDB "remotetimeout" value from its default value of 2 seconds.
+ You should ensure that the timeout (in seconds) is
+ bigger than the <option>--max-invoke-ms</option> value. For
+ example, for <option>--max-invoke-ms=5000</option>, the following
+ GDB command is suitable:
<screen><![CDATA[
(gdb) set remotetimeout 6
]]></screen>
@@ -2515,20 +2550,22 @@
<listitem>
<para><option>--wait=<number></option> instructs vgdb to
- check during the specified number of seconds if a Valgrind
- gdbserver can be found. This allows to start a vgdb before the
- Valgrind gdbserver is started. This option will be more useful in
- combination with a --vgdb-prefix unique for the process you want
- to wait for. Also, if you use the --wait argument in the gdb
- 'target remote' command, you must set the gdb remotetimeout to a
- value bigger than the --wait argument value. See option
- --max-invoke-ms for an example of setting this remotetimeout
- value.</para>
+ search for available Valgrind gdbservers for the specified number
+ of seconds. This makes it possible start a vgdb process
+ before starting the Valgrind gdbserver with which you intend the
+ vgdb to communicate. This option is useful when used in
+ conjunction with a <option>--vgdb-prefix</option> that is
+ unique to the process you want to wait for.
+ Also, if you use the <option>--wait</option> argument in the GDB
+ "target remote" command, you must set the GDB remotetimeout to a
+ value bigger than the --wait argument value. See option
+ <option>--max-invoke-ms</option> (just above)
+ for an example of setting the remotetimeout value.</para>
</listitem>
<listitem>
<para><option>-c</option> To give more than one command, separate
- the commands by an option -c. Example:
+ the commands by an option <option>-c</option>. Example:
<screen><![CDATA[
vgdb vg.set log_output -c mc.leak_check any
]]></screen></para>
@@ -2536,12 +2573,13 @@
<listitem>
<para><option>-d</option> instructs vgdb to produce debugging
- output. Give multiple -d args for more debug info.</para>
+ output. Give multiple <option>-d</option> args to increase the
+ verbosity.</para>
</listitem>
<listitem>
<para><option>-D</option> instructs vgdb to show the state of the
- shared memory used by the Valgrind gdbserver. vgdb will exit after
+ shared memory used by the Valgrind gdbserver. vgdb will exit after
having shown the Valgrind gdbserver shared memory state.</para>
</listitem>
@@ -2558,15 +2596,16 @@
xreflabel="Valgrind monitor commands">
<title>Valgrind monitor commands</title>
-<para>The Valgrind monitor commands are available whatever the
-tool. They can be sent either from a shell command line (using a
-standalone vgdb) or from gdb (using the gdb 'monitor' command).</para>
+<para>The Valgrind monitor commands are available regardless of the
+Valgrind tool selected. They can be sent either from a shell command
+line, by using a standalone vgdb, or from GDB, by using GDB's
+"monitor" command.</para>
<itemizedlist>
<listitem>
- <para><varname>help [debug]</varname> instructs Valgrind gdbserver
+ <para><varname>help [debug]</varname> instructs Valgrind's gdbserver
to give the list of all monitor commands of the Valgrind core and
- of the tool. The optional 'debug' argument tells to also give help
+ of the tool. The optional "debug" argument tells to also give help
for the monitor commands aimed at Valgrind internals debugging.
</para>
</listitem>
@@ -2581,35 +2620,37 @@
</listitem>
<listitem>
- <para><varname>vg.info n_errs_found</varname> shows the nr of
- errors found so far and the current value of the --vgdb-error
+ <para><varname>vg.info n_errs_found</varname> shows the number of
+ errors found so far and the current value of the
+ <option>--vgdb-error</option>
argument.</para>
</listitem>
<listitem>
<para><varname>vg.set {gdb_output | log_output |
- mixed_output}</varname> allows to redirect the Valgrind output
- (e.g. the errors detected by the tool). By default, the setting is
- mixed_output. </para>
+ mixed_output}</varname> allows redirection of the Valgrind output
+ (e.g. the errors detected by the tool). The default setting is
+ <computeroutput>mixed_output</computeroutput>.</para>
- <para>With mixed_output, the Valgrind output goes to the Valgrind
- log (typically stderr) while the output of the interactive gdb
- monitor commands (e.g. vg.info last_error) is displayed by
- gdb.</para>
+ <para>With <computeroutput>mixed_output</computeroutput>, the
+ Valgrind output goes to the Valgrind log (typically stderr) while
+ the output of the interactive GDB monitor commands (e.g.
+ <computeroutput>vg.info last_error</computeroutput>)
+ is displayed by GDB.</para>
- <para>With gdb_output, both the Valgrind output and the
- interactive gdb monitor commands output is displayed by
- gdb.</para>
+ <para>With <computeroutput>gdb_output</computeroutput>, both the
+ Valgrind output and the interactive gdb monitor commands output are
+ displayed by gdb.</para>
- <para>With log_output, both the Valgrind output and the
- interactive gdb monitor commands output go to the Valgrind
- log.</para>
+ <para>With <computeroutput>log_output</computeroutput>, both the
+ Valgrind output and the interactive gdb monitor commands output go
+ to the Valgrind log.</para>
</listitem>
<listitem>
<para><varname>vg.wait [ms (default 0)]</varname> instructs
- Valgrind gdbserver to sleep 'ms' milli-seconds and then
- continue. When sent from a standalone vgdb, if this is the last
+ Valgrind gdbserver to sleep "ms" milli-seconds and then
+ continue. When sent from a standalone vgdb, if this is the last
command, the Valgrind process will continue the execution of the
guest process. The typical usage of this is to use vgdb to send a
"no-op" command to a Valgrind gdbserver so as to continue the
@@ -2618,7 +2659,7 @@
</listitem>
<listitem>
- <para><varname>vg.kill;</varname> requests the gdbserver to kill
+ <para><varname>vg.kill</varname> requests the gdbserver to kill
the process. This can be used from a standalone vgdb to properly
kill a Valgrind process which is currently expecting a vgdb
connection.</para>
@@ -2626,65 +2667,72 @@
<listitem>
<para><varname>vg.set vgdb-error <errornr></varname>
- dynamically changes the value of the --vgdb-error argument. A
- typical usage of this is to start with --vgdb-error=0 on the
+ dynamically changes the value of the
+ <option>--vgdb-error</option> argument. A
+ typical usage of this is to start with
+ <option>--vgdb-error=0</option> on the
command line, then set a few breakpoints, set the vgdb-error value
to a huge value and continue execution.</para>
</listitem>
</itemizedlist>
-<para>The below Valgrind monitor commands are useful to investigate
-the behaviour of Valgrind or Valgrind gdbserver in case of problem or
-bug.</para>
+<para>The following Valgrind monitor commands are useful for
+investigating the behaviour of Valgrind or its gdbserver in case of
+problems or bugs.</para>
<itemizedlist>
<listitem>
<para><varname>vg.info gdbserver_status</varname> shows the
- gdbserver status. In case of problem (e.g. of communications),
- this gives the value of some relevant Valgrind gdbserver internal
+ gdbserver status. In case of problems (e.g. of communications),
+ this showns the values of some relevant Valgrind gdbserver internal
variables. Note that the variables related to breakpoints and
- watchpoints (e.g. the nr of gdbserved addresses and the nr of
- watchpoints) will be zero, as gdb by default removes all
+ watchpoints (e.g. the number of breakpoint addresses and the number of
+ watchpoints) will be zero, as GDB by default removes all
watchpoints and breakpoints when execution stops, and re-inserts
- them when resuming the execution of the debugged process. You can
- change this gdb behaviour by using the gdb command 'set breakpoint
- always-inserted on'.
+ them when resuming the execution of the debugged process. You can
+ change this gdb behaviour by using the GDB command
+ <computeroutput>set breakpoint always-inserted on</computeroutput>.
</para>
</listitem>
<listitem>
<para><varname>vg.info memory</varname> shows the statistics of
- the Valgrind heap management. If
- option <option>--profile-heap=yes=yes</option> was given, detailed
+ Valgrind's internal heap management. If
+ option <option>--profile-heap=yes</option> was given, detailed
statistics will be output.
</para>
</listitem>
<listitem>
<para><varname>vg.set debuglog <intvalue></varname> sets the
- valgrind debug log level to <intvalue>. This allows to
+ Valgrind debug log level to <intvalue>. This allows to
dynamically change the log level of Valgrind e.g. when a problem
is detected.</para>
</listitem>
<listitem>
<para><varname>vg.translate <address>
- [<traceflags>]</varname> traces the translation of the block
- containing address with the given trace flags. The traceflags is a
- bit pattern similar to the --trace-flags option. It can be given
+ [<traceflags>]</varname> shows the translation of the block
+ containing <computeroutput>address</computeroutput> with the given
+ trace flags. The <computeroutput>traceflags</computeroutput> value
+ bit pattern with similar meaning to Valgrind's
+ <option>--trace-flags</option> option. It can be given
in hexadecimal (e.g. 0x20) or decimal (e.g. 32) or in binary 1s
and 0s bit (e.g. 0b00100000). The default value of the traceflags
- is 0b00100000, corresponding to 'show after instrumentation'. Note
- that the output of this command always goes to the Valgrind
- log. The additional bit flag 0b100000000 traces in additio...
[truncated message content] |
|
From: Bart V. A. <bva...@ac...> - 2011-06-17 08:01:15
|
Nightly build on cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) Started at 2011-06-17 02:53:18 EDT Ended at 2011-06-17 04:01:01 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 == 461 tests, 20 stderr failures, 10 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == gdbserver_tests/nlfork_chain (stdout) gdbserver_tests/nlfork_chain (stderr) memcheck/tests/addressable (stderr) memcheck/tests/custom_alloc (stderr) memcheck/tests/deep_templates (stdout) memcheck/tests/describe-block (stderr) memcheck/tests/mempool (stderr) memcheck/tests/mempool2 (stderr) memcheck/tests/origin1-yes (stderr) memcheck/tests/origin3-no (stderr) memcheck/tests/wrap8 (stdout) memcheck/tests/wrap8 (stderr) callgrind/tests/simwork-both (stdout) callgrind/tests/simwork-both (stderr) callgrind/tests/simwork-branch (stdout) callgrind/tests/simwork-branch (stderr) none/tests/empty-exe (stderr) none/tests/faultstatus (stderr) none/tests/linux/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/test_gx (stdout) none/tests/ppc64/jm-fp (stdout) none/tests/ppc64/round (stdout) 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/tc23_bogus_condwait (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Last 20 lines of verbose log follow echo mc_translate.c:3418: error: 'Iop_QShortenU16Ux8' undeclared (first use in this function) mc_translate.c:3419: error: 'Iop_QShortenS32Sx4' undeclared (first use in this function) mc_translate.c:3420: error: 'Iop_QShortenU32Sx4' undeclared (first use in this function) mc_translate.c:3421: error: 'Iop_QShortenU32Ux4' undeclared (first use in this function) mc_translate.c:3422: error: 'Iop_QShortenS64Sx2' undeclared (first use in this function) mc_translate.c:3423: error: 'Iop_QShortenU64Sx2' undeclared (first use in this function) mc_translate.c:3424: error: 'Iop_QShortenU64Ux2' undeclared (first use in this function) mc_translate.c:3427: error: 'Iop_Longen8Sx8' undeclared (first use in this function) mc_translate.c:3428: error: 'Iop_Longen8Ux8' undeclared (first use in this function) mc_translate.c:3429: error: 'Iop_Longen16Sx4' undeclared (first use in this function) mc_translate.c:3430: error: 'Iop_Longen16Ux4' undeclared (first use in this function) mc_translate.c:3431: error: 'Iop_Longen32Sx2' undeclared (first use in this function) mc_translate.c:3432: error: 'Iop_Longen32Ux2' undeclared (first use in this function) make[3]: *** [memcheck_ppc64_linux-mc_translate.o] Error 1 make[3]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-old/memcheck' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-old/memcheck' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-old' make: *** [check] Error 2 ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Fri Jun 17 03:12:32 2011 --- new.short Fri Jun 17 04:01:01 2011 *************** *** 6,27 **** ! Last 20 lines of verbose log follow echo ! mc_translate.c:3418: error: 'Iop_QShortenU16Ux8' undeclared (first use in this function) ! mc_translate.c:3419: error: 'Iop_QShortenS32Sx4' undeclared (first use in this function) ! mc_translate.c:3420: error: 'Iop_QShortenU32Sx4' undeclared (first use in this function) ! mc_translate.c:3421: error: 'Iop_QShortenU32Ux4' undeclared (first use in this function) ! mc_translate.c:3422: error: 'Iop_QShortenS64Sx2' undeclared (first use in this function) ! mc_translate.c:3423: error: 'Iop_QShortenU64Sx2' undeclared (first use in this function) ! mc_translate.c:3424: error: 'Iop_QShortenU64Ux2' undeclared (first use in this function) ! mc_translate.c:3427: error: 'Iop_Longen8Sx8' undeclared (first use in this function) ! mc_translate.c:3428: error: 'Iop_Longen8Ux8' undeclared (first use in this function) ! mc_translate.c:3429: error: 'Iop_Longen16Sx4' undeclared (first use in this function) ! mc_translate.c:3430: error: 'Iop_Longen16Ux4' undeclared (first use in this function) ! mc_translate.c:3431: error: 'Iop_Longen32Sx2' undeclared (first use in this function) ! mc_translate.c:3432: error: 'Iop_Longen32Ux2' undeclared (first use in this function) ! make[3]: *** [memcheck_ppc64_linux-mc_translate.o] Error 1 ! make[3]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-old/memcheck' ! make[2]: *** [check-recursive] Error 1 ! make[2]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-old/memcheck' ! make[1]: *** [check-recursive] Error 1 ! make[1]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-old' ! make: *** [check] Error 2 --- 6,40 ---- ! Regression test results follow ! ! == 461 tests, 20 stderr failures, 10 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == ! gdbserver_tests/nlfork_chain (stdout) ! gdbserver_tests/nlfork_chain (stderr) ! memcheck/tests/addressable (stderr) ! memcheck/tests/custom_alloc (stderr) ! memcheck/tests/deep_templates (stdout) ! memcheck/tests/describe-block (stderr) ! memcheck/tests/mempool (stderr) ! memcheck/tests/mempool2 (stderr) ! memcheck/tests/origin1-yes (stderr) ! memcheck/tests/origin3-no (stderr) ! memcheck/tests/wrap8 (stdout) ! memcheck/tests/wrap8 (stderr) ! callgrind/tests/simwork-both (stdout) ! callgrind/tests/simwork-both (stderr) ! callgrind/tests/simwork-branch (stdout) ! callgrind/tests/simwork-branch (stderr) ! none/tests/empty-exe (stderr) ! none/tests/faultstatus (stderr) ! none/tests/linux/mremap (stderr) ! none/tests/ppc32/jm-fp (stdout) ! none/tests/ppc32/round (stdout) ! none/tests/ppc32/test_gx (stdout) ! none/tests/ppc64/jm-fp (stdout) ! none/tests/ppc64/round (stdout) ! 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/tc23_bogus_condwait (stderr) ! |
|
From: Rich C. <rc...@wi...> - 2011-06-17 05:16:26
|
Nightly build on ppc32 ( Linux 2.6.27.45-0.1-default ppc )
Started at 2011-06-16 23:26:01 CDT
Ended at 2011-06-17 00:16:16 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
== 461 tests, 15 stderr failures, 5 stdout failures, 2 stderrB failures, 0 stdoutB failures, 2 post failures ==
gdbserver_tests/mcinfcallWSRU (stderrB)
gdbserver_tests/mcvabits (stderrB)
memcheck/tests/badjump (stderr)
memcheck/tests/badjump2 (stderr)
memcheck/tests/linux/stack_changes (stderr)
memcheck/tests/origin5-bz2 (stderr)
memcheck/tests/supp_unknown (stderr)
memcheck/tests/varinfo6 (stderr)
massif/tests/deep-D (post)
massif/tests/overloaded-new (post)
none/tests/linux/mremap (stderr)
none/tests/ppc32/jm-fp (stdout)
none/tests/ppc32/jm-fp (stderr)
none/tests/ppc32/power5+_round (stdout)
none/tests/ppc32/power5+_round (stderr)
none/tests/ppc32/round (stdout)
none/tests/ppc32/round (stderr)
none/tests/ppc32/test_fx (stdout)
none/tests/ppc32/test_fx (stderr)
none/tests/ppc32/test_gx (stdout)
helgrind/tests/hg05_race2 (stderr)
helgrind/tests/tc06_two_races_xml (stderr)
helgrind/tests/tc23_bogus_condwait (stderr)
drd/tests/tc23_bogus_condwait (stderr)
=================================================
== Results from 24 hours ago ==
=================================================
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... failed
Last 20 lines of verbose log follow echo
mc_translate.c:3418: error: 'Iop_QShortenU16Ux8' undeclared (first use in this function)
mc_translate.c:3419: error: 'Iop_QShortenS32Sx4' undeclared (first use in this function)
mc_translate.c:3420: error: 'Iop_QShortenU32Sx4' undeclared (first use in this function)
mc_translate.c:3421: error: 'Iop_QShortenU32Ux4' undeclared (first use in this function)
mc_translate.c:3422: error: 'Iop_QShortenS64Sx2' undeclared (first use in this function)
mc_translate.c:3423: error: 'Iop_QShortenU64Sx2' undeclared (first use in this function)
mc_translate.c:3424: error: 'Iop_QShortenU64Ux2' undeclared (first use in this function)
mc_translate.c:3427: error: 'Iop_Longen8Sx8' undeclared (first use in this function)
mc_translate.c:3428: error: 'Iop_Longen8Ux8' undeclared (first use in this function)
mc_translate.c:3429: error: 'Iop_Longen16Sx4' undeclared (first use in this function)
mc_translate.c:3430: error: 'Iop_Longen16Ux4' undeclared (first use in this function)
mc_translate.c:3431: error: 'Iop_Longen32Sx2' undeclared (first use in this function)
mc_translate.c:3432: error: 'Iop_Longen32Ux2' undeclared (first use in this function)
make[3]: *** [memcheck_ppc32_linux-mc_translate.o] Error 1
make[3]: Leaving directory `/root/src/vg/nightly/valgrind-old/memcheck'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/root/src/vg/nightly/valgrind-old/memcheck'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/src/vg/nightly/valgrind-old'
make: *** [all] Error 2
=================================================
== Difference between 24 hours ago and now ==
=================================================
*** old.short Thu Jun 16 23:37:19 2011
--- new.short Fri Jun 17 00:16:16 2011
***************
*** 3,26 ****
Configuring valgrind ... done
! Building valgrind ... failed
- Last 20 lines of verbose log follow echo
- mc_translate.c:3418: error: 'Iop_QShortenU16Ux8' undeclared (first use in this function)
- mc_translate.c:3419: error: 'Iop_QShortenS32Sx4' undeclared (first use in this function)
- mc_translate.c:3420: error: 'Iop_QShortenU32Sx4' undeclared (first use in this function)
- mc_translate.c:3421: error: 'Iop_QShortenU32Ux4' undeclared (first use in this function)
- mc_translate.c:3422: error: 'Iop_QShortenS64Sx2' undeclared (first use in this function)
- mc_translate.c:3423: error: 'Iop_QShortenU64Sx2' undeclared (first use in this function)
- mc_translate.c:3424: error: 'Iop_QShortenU64Ux2' undeclared (first use in this function)
- mc_translate.c:3427: error: 'Iop_Longen8Sx8' undeclared (first use in this function)
- mc_translate.c:3428: error: 'Iop_Longen8Ux8' undeclared (first use in this function)
- mc_translate.c:3429: error: 'Iop_Longen16Sx4' undeclared (first use in this function)
- mc_translate.c:3430: error: 'Iop_Longen16Ux4' undeclared (first use in this function)
- mc_translate.c:3431: error: 'Iop_Longen32Sx2' undeclared (first use in this function)
- mc_translate.c:3432: error: 'Iop_Longen32Ux2' undeclared (first use in this function)
- make[3]: *** [memcheck_ppc32_linux-mc_translate.o] Error 1
- make[3]: Leaving directory `/root/src/vg/nightly/valgrind-old/memcheck'
- make[2]: *** [all-recursive] Error 1
- make[2]: Leaving directory `/root/src/vg/nightly/valgrind-old/memcheck'
- make[1]: *** [all-recursive] Error 1
- make[1]: Leaving directory `/root/src/vg/nightly/valgrind-old'
- make: *** [all] Error 2
--- 3,34 ----
Configuring valgrind ... done
! Building valgrind ... done
! Running regression tests ... failed
!
! Regression test results follow
!
! == 461 tests, 15 stderr failures, 5 stdout failures, 2 stderrB failures, 0 stdoutB failures, 2 post failures ==
! gdbserver_tests/mcinfcallWSRU (stderrB)
! gdbserver_tests/mcvabits (stderrB)
! memcheck/tests/badjump (stderr)
! memcheck/tests/badjump2 (stderr)
! memcheck/tests/linux/stack_changes (stderr)
! memcheck/tests/origin5-bz2 (stderr)
! memcheck/tests/supp_unknown (stderr)
! memcheck/tests/varinfo6 (stderr)
! massif/tests/deep-D (post)
! massif/tests/overloaded-new (post)
! none/tests/linux/mremap (stderr)
! none/tests/ppc32/jm-fp (stdout)
! none/tests/ppc32/jm-fp (stderr)
! none/tests/ppc32/power5+_round (stdout)
! none/tests/ppc32/power5+_round (stderr)
! none/tests/ppc32/round (stdout)
! none/tests/ppc32/round (stderr)
! none/tests/ppc32/test_fx (stdout)
! none/tests/ppc32/test_fx (stderr)
! none/tests/ppc32/test_gx (stdout)
! helgrind/tests/hg05_race2 (stderr)
! helgrind/tests/tc06_two_races_xml (stderr)
! helgrind/tests/tc23_bogus_condwait (stderr)
! drd/tests/tc23_bogus_condwait (stderr)
=================================================
./valgrind-new/drd/tests/tc23_bogus_condwait.stderr.diff-darwin-amd64
=================================================
--- tc23_bogus_condwait.stderr.exp-darwin-amd64 2011-06-16 23:37:47.000000000 -0500
+++ tc23_bogus_condwait.stderr.out 2011-06-17 00:15:55.000000000 -0500
@@ -3,67 +3,11 @@
at 0x........: pthread_cond_wait (drd_pthread_intercepts.c:?)
by 0x........: main (tc23_bogus_condwait.c:69)
-Mutex not locked: mutex 0x........, recursion count 0, owner 0.
- at 0x........: pthread_cond_wait (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:72)
-mutex 0x........ was first observed at:
- at 0x........: pthread_mutex_init (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:51)
-
-Thread 3:
-Probably a race condition: condition variable 0x........ has been signaled but the associated mutex 0x........ is not locked by the signalling thread.
- at 0x........: pthread_cond_signal (drd_pthread_intercepts.c:?)
- by 0x........: rescue_me (tc23_bogus_condwait.c:20)
- by 0x........: vgDrd_thread_wrapper (drd_pthread_intercepts.c:?)
-cond 0x........ was first observed at:
- at 0x........: pthread_cond_init (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:56)
-mutex 0x........ was first observed at:
- at 0x........: pthread_mutex_init (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:51)
-
-Thread 1:
-The object at address 0x........ is not a mutex.
- at 0x........: pthread_cond_wait (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:75)
-rwlock 0x........ was first observed at:
- at 0x........: pthread_rwlock_init (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:57)
-
-Mutex not locked by calling thread: mutex 0x........, recursion count 1, owner 2.
- at 0x........: pthread_cond_wait (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:78)
-mutex 0x........ was first observed at:
- at 0x........: pthread_mutex_init (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:53)
-
-Thread 3:
-Probably a race condition: condition variable 0x........ has been signaled but the associated mutex 0x........ is not locked by the signalling thread.
- at 0x........: pthread_cond_signal (drd_pthread_intercepts.c:?)
- by 0x........: rescue_me (tc23_bogus_condwait.c:24)
- by 0x........: vgDrd_thread_wrapper (drd_pthread_intercepts.c:?)
-cond 0x........ was first observed at:
- at 0x........: pthread_cond_init (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:56)
-mutex 0x........ was first observed at:
- at 0x........: pthread_mutex_init (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:53)
-
-The impossible happened: mutex 0x........ is locked simultaneously by two threads (recursion count 1, owners 2 and 1) !
-Thread 2:
-Mutex not locked by calling thread: mutex 0x........, recursion count 2, owner 1.
- at 0x........: pthread_mutex_unlock (drd_pthread_intercepts.c:?)
- by 0x........: grab_the_lock (tc23_bogus_condwait.c:42)
- by 0x........: vgDrd_thread_wrapper (drd_pthread_intercepts.c:?)
-mutex 0x........ was first observed at:
- at 0x........: pthread_mutex_init (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:53)
-
-Assertion failed: (!r), function main, file tc23_bogus_condwait.c, line 86.
-Process terminating with default action of signal 6 (SIGABRT)
- at 0x........: __kill (in /...libc...)
- by 0x........: __assert_rtn (in /...libc...)
- by 0x........: main (tc23_bogus_condwait.c:86)
+Process terminating with default action of signal 7 (SIGBUS)
+ Invalid address alignment at address 0x........
+ at 0x........: __pthread_mutex_unlock_usercnt (pthread_mutex_unlock.c:?)
+ by 0x........: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.c:?)
+ by 0x........: pthread_cond_wait (drd_pthread_intercepts.c:?)
-ERROR SUMMARY: 9 errors from 7 contexts (suppressed: 0 from 0)
+ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 0 from 0)
=================================================
./valgrind-new/drd/tests/tc23_bogus_condwait.stderr.diff-darwin-x86
=================================================
--- tc23_bogus_condwait.stderr.exp-darwin-x86 2011-06-16 23:37:46.000000000 -0500
+++ tc23_bogus_condwait.stderr.out 2011-06-17 00:15:55.000000000 -0500
@@ -3,61 +3,11 @@
at 0x........: pthread_cond_wait (drd_pthread_intercepts.c:?)
by 0x........: main (tc23_bogus_condwait.c:69)
-Mutex not locked: mutex 0x........, recursion count 0, owner 0.
- at 0x........: pthread_cond_wait (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:72)
-mutex 0x........ was first observed at:
- at 0x........: pthread_mutex_init (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:51)
-
-Thread 3:
-Probably a race condition: condition variable 0x........ has been signaled but the associated mutex 0x........ is not locked by the signalling thread.
- at 0x........: pthread_cond_signal (drd_pthread_intercepts.c:?)
- by 0x........: rescue_me (tc23_bogus_condwait.c:20)
- by 0x........: vgDrd_thread_wrapper (drd_pthread_intercepts.c:?)
-cond 0x........ was first observed at:
- at 0x........: pthread_cond_init (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:56)
-mutex 0x........ was first observed at:
- at 0x........: pthread_mutex_init (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:51)
-
-Thread 1:
-The object at address 0x........ is not a mutex.
- at 0x........: pthread_cond_wait (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:75)
-rwlock 0x........ was first observed at:
- at 0x........: pthread_rwlock_init (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:57)
-
-Mutex not locked by calling thread: mutex 0x........, recursion count 1, owner 2.
- at 0x........: pthread_cond_wait (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:78)
-mutex 0x........ was first observed at:
- at 0x........: pthread_mutex_init (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:53)
-
-Thread 3:
-Probably a race condition: condition variable 0x........ has been signaled but the associated mutex 0x........ is not locked by the signalling thread.
- at 0x........: pthread_cond_signal (drd_pthread_intercepts.c:?)
- by 0x........: rescue_me (tc23_bogus_condwait.c:24)
- by 0x........: vgDrd_thread_wrapper (drd_pthread_intercepts.c:?)
-cond 0x........ was first observed at:
- at 0x........: pthread_cond_init (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:56)
-mutex 0x........ was first observed at:
- at 0x........: pthread_mutex_init (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:53)
-
-The impossible happened: mutex 0x........ is locked simultaneously by two threads (recursion count 1, owners 2 and 1) !
-Thread 2:
-Mutex not locked by calling thread: mutex 0x........, recursion count 2, owner 1.
- at 0x........: pthread_mutex_unlock (drd_pthread_intercepts.c:?)
- by 0x........: grab_the_lock (tc23_bogus_condwait.c:42)
- by 0x........: vgDrd_thread_wrapper (drd_pthread_intercepts.c:?)
-mutex 0x........ was first observed at:
- at 0x........: pthread_mutex_init (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:53)
+Process terminating with default action of signal 7 (SIGBUS)
+ Invalid address alignment at address 0x........
+ at 0x........: __pthread_mutex_unlock_usercnt (pthread_mutex_unlock.c:?)
+ by 0x........: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.c:?)
+ by 0x........: pthread_cond_wait (drd_pthread_intercepts.c:?)
-ERROR SUMMARY: 9 errors from 7 contexts (suppressed: 0 from 0)
+ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 0 from 0)
=================================================
./valgrind-new/drd/tests/tc23_bogus_condwait.stderr.diff-linux-ppc
=================================================
--- tc23_bogus_condwait.stderr.exp-linux-ppc 2011-06-16 23:37:46.000000000 -0500
+++ tc23_bogus_condwait.stderr.out 2011-06-17 00:15:55.000000000 -0500
@@ -6,8 +6,8 @@
Process terminating with default action of signal 7 (SIGBUS)
Invalid address alignment at address 0x........
- at 0x........: (within libpthread-?.?.so)
- by 0x........: pthread_cond_wait@@GLIBC_2.3.2(within libpthread-?.?.so)
+ at 0x........: __pthread_mutex_unlock_usercnt (pthread_mutex_unlock.c:?)
+ by 0x........: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.c:?)
by 0x........: pthread_cond_wait (drd_pthread_intercepts.c:?)
ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 0 from 0)
=================================================
./valgrind-new/drd/tests/tc23_bogus_condwait.stderr.diff-linux-x86
=================================================
--- tc23_bogus_condwait.stderr.exp-linux-x86 2011-06-16 23:37:47.000000000 -0500
+++ tc23_bogus_condwait.stderr.out 2011-06-17 00:15:55.000000000 -0500
@@ -3,84 +3,11 @@
at 0x........: pthread_cond_wait (drd_pthread_intercepts.c:?)
by 0x........: main (tc23_bogus_condwait.c:69)
-Thread 3:
-Probably a race condition: condition variable 0x........ has been signaled but the associated mutex 0x........ is not locked by the signalling thread.
- at 0x........: pthread_cond_signal (drd_pthread_intercepts.c:?)
- by 0x........: rescue_me (tc23_bogus_condwait.c:20)
- by 0x........: vgDrd_thread_wrapper (drd_pthread_intercepts.c:?)
-cond 0x........ was first observed at:
- at 0x........: pthread_cond_init (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:56)
-
-Thread 1:
-Mutex not locked: mutex 0x........, recursion count 0, owner 0.
- at 0x........: pthread_cond_wait (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:72)
-mutex 0x........ was first observed at:
- at 0x........: pthread_mutex_init (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:51)
-
-Thread 3:
-Probably a race condition: condition variable 0x........ has been signaled but the associated mutex 0x........ is not locked by the signalling thread.
- at 0x........: pthread_cond_signal (drd_pthread_intercepts.c:?)
- by 0x........: rescue_me (tc23_bogus_condwait.c:24)
- by 0x........: vgDrd_thread_wrapper (drd_pthread_intercepts.c:?)
-cond 0x........ was first observed at:
- at 0x........: pthread_cond_init (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:56)
-mutex 0x........ was first observed at:
- at 0x........: pthread_mutex_init (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:51)
-
-Thread 1:
-The object at address 0x........ is not a mutex.
- at 0x........: pthread_cond_wait (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:75)
-rwlock 0x........ was first observed at:
- at 0x........: pthread_rwlock_init (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:57)
-
-Thread 3:
-Probably a race condition: condition variable 0x........ has been signaled but the associated mutex 0x........ is not locked by the signalling thread.
- at 0x........: pthread_cond_signal (drd_pthread_intercepts.c:?)
- by 0x........: rescue_me (tc23_bogus_condwait.c:28)
- by 0x........: vgDrd_thread_wrapper (drd_pthread_intercepts.c:?)
-cond 0x........ was first observed at:
- at 0x........: pthread_cond_init (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:56)
-rwlock 0x........ was first observed at:
- at 0x........: pthread_rwlock_init (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:57)
-
-Thread 1:
-Mutex not locked by calling thread: mutex 0x........, recursion count 1, owner 2.
- at 0x........: pthread_cond_wait (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:78)
-mutex 0x........ was first observed at:
- at 0x........: pthread_mutex_init (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:53)
-
-Thread 3:
-Probably a race condition: condition variable 0x........ has been signaled but the associated mutex 0x........ is not locked by the signalling thread.
- at 0x........: pthread_cond_signal (drd_pthread_intercepts.c:?)
- by 0x........: rescue_me (tc23_bogus_condwait.c:32)
- by 0x........: vgDrd_thread_wrapper (drd_pthread_intercepts.c:?)
-cond 0x........ was first observed at:
- at 0x........: pthread_cond_init (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:56)
-mutex 0x........ was first observed at:
- at 0x........: pthread_mutex_init (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:53)
-
-The impossible happened: mutex 0x........ is locked simultaneously by two threads (recursion count 1, owners 2 and 1) !
-Thread 2:
-Mutex not locked by calling thread: mutex 0x........, recursion count 2, owner 1.
- at 0x........: pthread_mutex_unlock (drd_pthread_intercepts.c:?)
- by 0x........: grab_the_lock (tc23_bogus_condwait.c:42)
- by 0x........: vgDrd_thread_wrapper (drd_pthread_intercepts.c:?)
-mutex 0x........ was first observed at:
- at 0x........: pthread_mutex_init (drd_pthread_intercepts.c:?)
- by 0x........: main (tc23_bogus_condwait.c:53)
+Process terminating with default action of signal 7 (SIGBUS)
+ Invalid address alignment at address 0x........
+ at 0x........: __pthread_mutex_unlock_usercnt (pthread_mutex_unlock.c:?)
+ by 0x........: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.c:?)
+ by 0x........: pthread_cond_wait (drd_pthread_intercepts.c:?)
-ERROR SUMMARY: 11 errors from 9 contexts (suppressed: 0 from 0)
+ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 0 from 0)
=================================================
./valgrind-new/gdbserver_tests/mcinfcallWSRU.stderrB.diff
=================================================
--- mcinfcallWSRU.stderrB.exp 2011-06-16 23:37:27.000000000 -0500
+++ mcinfcallWSRU.stderrB.out 2011-06-16 23:53:26.000000000 -0500
@@ -26,30 +26,27 @@
$1 = void
[Switching to thread 2 (Thread ....)]
#0 0x........ in syscall ...
-Could not write register "xxx"; remote failure reply 'E.
+Remote failure reply: E.
ERROR changing register xxx regno y
gdb commands changing registers (pc, sp, ...) (e.g. 'jump',
set pc, calling from gdb a function in the debugged process, ...)
can only be accepted if the thread is VgTs_Runnable or VgTs_Yielding state
Thread status is VgTs_WaitSys
-'
[Switching to thread 3 (Thread ....)]
#0 0x........ in syscall ...
-Could not write register "xxx"; remote failure reply 'E.
+Remote failure reply: E.
ERROR changing register xxx regno y
gdb commands changing registers (pc, sp, ...) (e.g. 'jump',
set pc, calling from gdb a function in the debugged process, ...)
can only be accepted if the thread is VgTs_Runnable or VgTs_Yielding state
Thread status is VgTs_WaitSys
-'
[Switching to thread 4 (Thread ....)]
#0 0x........ in syscall ...
-Could not write register "xxx"; remote failure reply 'E.
+Remote failure reply: E.
ERROR changing register xxx regno y
gdb commands changing registers (pc, sp, ...) (e.g. 'jump',
set pc, calling from gdb a function in the debugged process, ...)
can only be accepted if the thread is VgTs_Runnable or VgTs_Yielding state
Thread status is VgTs_WaitSys
-'
monitor command request to kill this process
Remote connection closed
=================================================
./valgrind-new/gdbserver_tests/mcvabits.stderrB.diff
=================================================
--- mcvabits.stderrB.exp 2011-06-16 23:37:27.000000000 -0500
+++ mcvabits.stderrB.out 2011-06-16 23:53:50.000000000 -0500
@@ -1,55 +1,32 @@
relaying data between gdb and process ....
vgdb-error value changed from 0 to 999999
-Address 0x........ len 10 addressable
- Address 0x........ is 0 bytes inside data symbol "undefined"
-Address 0x........ len 10 defined
- Address 0x........ is 0 bytes inside data symbol "undefined"
-00000000 00000000 0000
-Address 0x........ len 10 addressable
- Address 0x........ is 0 bytes inside data symbol "undefined"
-Address 0x........ len 10 not defined:
-Uninitialised value at 0x........
- Address 0x........ is 0 bytes inside data symbol "undefined"
-ff00ff00 ff00ff00 ff00
-Address 0x........ len 10 addressable
- Address 0x........ is 0 bytes inside data symbol "undefined"
-Address 0x........ len 10 not defined:
-Uninitialised value at 0x........
- Address 0x........ is 0 bytes inside data symbol "undefined"
-ff000000 0000ff00 ff00
-Address 0x........ len 10 addressable
- Address 0x........ is 0 bytes inside data symbol "undefined"
-Address 0x........ len 10 not defined:
-Uninitialised value at 0x........
- Address 0x........ is 0 bytes inside data symbol "undefined"
-ff00ffff ffffff00 ff00
-Address 0x........ len 2 addressable
- Address 0x........ is 0 bytes inside data symbol "undefined"
-Address 0x........ len 2 not defined:
-Uninitialised value at 0x........
- Address 0x........ is 0 bytes inside data symbol "undefined"
-ff00
-Address 0x........ len 2 not addressable:
-bad address 0x........
- Address 0x........ is 2 bytes inside data symbol "undefined"
-Address 0x........ len 2 not addressable:
-bad address 0x........
- Address 0x........ is 2 bytes inside data symbol "undefined"
-____
-Address 0x........ len 2 has 2 bytes unaddressable
-Address 0x........ len 6 addressable
- Address 0x........ is 4 bytes inside data symbol "undefined"
-Address 0x........ len 6 not defined:
-Uninitialised value at 0x........
- Address 0x........ is 4 bytes inside data symbol "undefined"
-ffffff00 ff00
-Address 0x........ len 10 not addressable:
-bad address 0x........
- Address 0x........ is 0 bytes inside data symbol "undefined"
-Address 0x........ len 10 not addressable:
-bad address 0x........
- Address 0x........ is 0 bytes inside data symbol "undefined"
-0000____ 00000000 0000
-Address 0x........ len 10 has 2 bytes unaddressable
+Undefined command: "eval". Try "help".
+Undefined command: "eval". Try "help".
+Undefined command: "eval". Try "help".
+Undefined command: "eval". Try "help".
+Undefined command: "eval". Try "help".
+Undefined command: "eval". Try "help".
+Undefined command: "eval". Try "help".
+Undefined command: "eval". Try "help".
+Undefined command: "eval". Try "help".
+Undefined command: "eval". Try "help".
+Undefined command: "eval". Try "help".
+Undefined command: "eval". Try "help".
+Undefined command: "eval". Try "help".
+Undefined command: "eval". Try "help".
+Undefined command: "eval". Try "help".
+Undefined command: "eval". Try "help".
+Undefined command: "eval". Try "help".
+Undefined command: "eval". Try "help".
+Undefined command: "eval". Try "help".
+Undefined command: "eval". Try "help".
+Undefined command: "eval". Try "help".
+Undefined command: "eval". Try "help".
+Undefined command: "eval". Try "help".
+Undefined command: "eval". Try "help".
+Undefined command: "eval". Try "help".
+Undefined command: "eval". Try "help".
+Undefined command: "eval". Try "help".
+Undefined command: "eval". Try "help".
monitor command request to kill this process
Remote connection closed
=================================================
./valgrind-new/helgrind/tests/hg05_race2.stderr.diff
=================================================
--- hg05_race2.stderr.exp 2011-06-16 23:37:25.000000000 -0500
+++ hg05_race2.stderr.out 2011-06-17 00:05:48.000000000 -0500
@@ -17,8 +17,6 @@
at 0x........: th (hg05_race2.c:17)
by 0x........: mythread_wrapper (hg_intercepts.c:...)
...
- Location 0x........ is 0 bytes inside foo.poot[5].plop[11],
- declared at hg05_race2.c:24, in frame #x of thread x
Possible data race during write of size 4 at 0x........ by thread #x
at 0x........: th (hg05_race2.c:17)
@@ -28,8 +26,6 @@
at 0x........: th (hg05_race2.c:17)
by 0x........: mythread_wrapper (hg_intercepts.c:...)
...
- Location 0x........ is 0 bytes inside foo.poot[5].plop[11],
- declared at hg05_race2.c:24, in frame #x of thread x
ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
=================================================
./valgrind-new/helgrind/tests/tc06_two_races_xml.stderr.diff
=================================================
--- tc06_two_races_xml.stderr.exp 2011-06-16 23:37:25.000000000 -0500
+++ tc06_two_races_xml.stderr.out 2011-06-17 00:06:33.000000000 -0500
@@ -45,11 +45,17 @@
<ip>0x........</ip>
<obj>...</obj>
<fn>do_clone</fn>
+ <dir>...</dir>
+ <file>createthread.c</file>
+ <line>...</line>
</frame>
<frame>
<ip>0x........</ip>
<obj>...</obj>
- <fn>pthread_create@@GLIBC_2.2.5</fn>
+ <fn>pthread_create@@GLIBC_2.1</fn>
+ <dir>...</dir>
+ <file>createthread.c</file>
+ <line>...</line>
</frame>
<frame>
<ip>0x........</ip>
@@ -121,6 +127,9 @@
<ip>0x........</ip>
<obj>...</obj>
<fn>start_thread</fn>
+ <dir>...</dir>
+ <file>pthread_create.c</file>
+ <line>...</line>
</frame>
<frame>
<ip>0x........</ip>
@@ -175,6 +184,9 @@
<ip>0x........</ip>
<obj>...</obj>
<fn>start_thread</fn>
+ <dir>...</dir>
+ <file>pthread_create.c</file>
+ <line>...</line>
</frame>
<frame>
<ip>0x........</ip>
@@ -229,6 +241,9 @@
<ip>0x........</ip>
<obj>...</obj>
<fn>start_thread</fn>
+ <dir>...</dir>
+ <file>pthread_create.c</file>
+ <line>...</line>
</frame>
<frame>
<ip>0x........</ip>
@@ -283,6 +298,9 @@
<ip>0x........</ip>
<obj>...</obj>
<fn>start_thread</fn>
+ <dir>...</dir>
+ <file>pthread_create.c</file>
+ <line>...</line>
</frame>
<frame>
<ip>0x........</ip>
=================================================
./valgrind-new/helgrind/tests/tc23_bogus_condwait.stderr.diff
=================================================
--- tc23_bogus_condwait.stderr.exp 2011-06-16 23:37:25.000000000 -0500
+++ tc23_bogus_condwait.stderr.out 2011-06-17 00:07:37.000000000 -0500
@@ -2,39 +2,24 @@
Thread #x is the program's root thread
Thread #x: pthread_cond_{timed}wait called with invalid mutex
- at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
- by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
+ at 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
by 0x........: main (tc23_bogus_condwait.c:69)
-Thread #x: pthread_cond_{timed}wait called with un-held mutex
- at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
- by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
- by 0x........: main (tc23_bogus_condwait.c:72)
-
-Thread #x: pthread_cond_{timed}wait: cond is associated with a different mutex
- at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
- by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
- by 0x........: main (tc23_bogus_condwait.c:72)
-
-Thread #x: pthread_cond_{timed}wait called with mutex of type pthread_rwlock_t*
- at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
- by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
- by 0x........: main (tc23_bogus_condwait.c:75)
-
-Thread #x: pthread_cond_{timed}wait: cond is associated with a different mutex
- at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
- by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
- by 0x........: main (tc23_bogus_condwait.c:75)
-Thread #x: pthread_cond_{timed}wait called with mutex held by a different thread
- at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
+Process terminating with default action of signal 7 (SIGBUS)
+ Invalid address alignment at address 0x........
+ at 0x........: __pthread_mutex_unlock_usercnt (pthread_mutex_unlock.c:64)
+ by 0x........: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.c:108)
by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
- by 0x........: main (tc23_bogus_condwait.c:78)
+ by 0x........: main (tc23_bogus_condwait.c:69)
+Thread #x was created
+ ...
+ by 0x........: pthread_create@* (hg_intercepts.c:...)
+ by 0x........: main (tc23_bogus_condwait.c:61)
-Thread #x: pthread_cond_{timed}wait: cond is associated with a different mutex
- at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
- by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
- by 0x........: main (tc23_bogus_condwait.c:78)
+Thread #x: Exiting thread still holds 1 lock
+ ...
+ ...
-ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 0 from 0)
+ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
=================================================
./valgrind-new/massif/tests/deep-D.post.diff
=================================================
--- deep-D.post.exp 2011-06-16 23:37:33.000000000 -0500
+++ deep-D.post.out 2011-06-17 00:02:13.000000000 -0500
@@ -46,8 +46,9 @@
8 3,264 3,264 3,200 64 0
9 3,672 3,672 3,600 72 0
98.04% (3,600B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
-->98.04% (3,600B) 0x........: (below main)
-
+->98.04% (3,600B) 0x........: ??? (in /...libc...)
+ ->98.04% (3,600B) 0x........: (below main)
+
--------------------------------------------------------------------------------
n time(B) total(B) useful-heap(B) extra-heap(B) stacks(B)
--------------------------------------------------------------------------------
=================================================
./valgrind-new/massif/tests/overloaded-new.post.diff
=================================================
--- overloaded-new.post.exp 2011-06-16 23:37:33.000000000 -0500
+++ overloaded-new.post.out 2011-06-17 00:02:24.000000000 -0500
@@ -42,14 +42,18 @@
4 12,032 12,032 12,000 32 0
5 12,032 12,032 12,000 32 0
99.73% (12,000B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
-->33.24% (4,000B) 0x........: main (overloaded-new.cpp:49)
-|
-->33.24% (4,000B) 0x........: main (overloaded-new.cpp:50)
-|
-->16.62% (2,000B) 0x........: main (overloaded-new.cpp:51)
-|
-->16.62% (2,000B) 0x........: main (overloaded-new.cpp:52)
-
+->33.24% (4,000B) 0x........: operator new(unsigned int) (overloaded-new.cpp:19)
+| ->33.24% (4,000B) 0x........: main (overloaded-new.cpp:49)
+|
+->33.24% (4,000B) 0x........: operator new(unsigned int, std::nothrow_t const&) (overloaded-new.cpp:24)
+| ->33.24% (4,000B) 0x........: main (overloaded-new.cpp:50)
+|
+->16.62% (2,000B) 0x........: operator new[](unsigned int) (overloaded-new.cpp:29)
+| ->16.62% (2,000B) 0x........: main (overloaded-new.cpp:51)
+|
+->16.62% (2,000B) 0x........: operator new[](unsigned int, std::nothrow_t const&) (overloaded-new.cpp:34)
+ ->16.62% (2,000B) 0x........: main (overloaded-new.cpp:52)
+
--------------------------------------------------------------------------------
n time(B) total(B) useful-heap(B) extra-heap(B) stacks(B)
--------------------------------------------------------------------------------
=================================================
./valgrind-new/memcheck/tests/badjump.stderr.diff
=================================================
--- badjump.stderr.exp 2011-06-16 23:37:32.000000000 -0500
+++ badjump.stderr.out 2011-06-16 23:55:16.000000000 -0500
@@ -1,6 +1,7 @@
Jump to the invalid address stated on the next line
at 0x........: ???
+ by 0x........: ??? (in /...libc...)
by 0x........: (below main)
Address 0x........ is not stack'd, malloc'd or (recently) free'd
@@ -8,6 +9,7 @@
Process terminating with default action of signal 11 (SIGSEGV)
Access not within mapped region at address 0x........
at 0x........: ???
+ by 0x........: ??? (in /...libc...)
by 0x........: (below main)
If you believe this happened as a result of a stack
overflow in your program's main thread (unlikely but
=================================================
./valgrind-new/memcheck/tests/badjump.stderr.diff-s390x
=================================================
--- badjump.stderr.exp-s390x 2011-06-16 23:37:31.000000000 -0500
+++ badjump.stderr.out 2011-06-16 23:55:16.000000000 -0500
@@ -1,14 +1,16 @@
Jump to the invalid address stated on the next line
at 0x........: ???
- by 0x........: main (badjump.c:17)
+ by 0x........: ??? (in /...libc...)
+ by 0x........: (below main)
Address 0x........ is not stack'd, malloc'd or (recently) free'd
Process terminating with default action of signal 11 (SIGSEGV)
Access not within mapped region at address 0x........
at 0x........: ???
- by 0x........: main (badjump.c:17)
+ by 0x........: ??? (in /...libc...)
+ by 0x........: (below main)
If you believe this happened as a result of a stack
overflow in your program's main thread (unlikely but
possible), you can try to increase the size of the
=================================================
./valgrind-new/memcheck/tests/badjump2.stderr.diff
=================================================
--- badjump2.stderr.exp 2011-06-16 23:37:32.000000000 -0500
+++ badjump2.stderr.out 2011-06-16 23:55:18.000000000 -0500
@@ -1,5 +1,6 @@
Jump to the invalid address stated on the next line
at 0x........: ???
+ by 0x........: ??? (in /...libc...)
by 0x........: (below main)
Address 0x........ is not stack'd, malloc'd or (recently) free'd
=================================================
./valgrind-new/memcheck/tests/badjump2.stderr.diff-s390x
=================================================
--- badjump2.stderr.exp-s390x 2011-06-16 23:37:32.000000000 -0500
+++ badjump2.stderr.out 2011-06-16 23:55:18.000000000 -0500
@@ -1,6 +1,7 @@
Jump to the invalid address stated on the next line
at 0x........: ???
- by 0x........: main (badjump2.c:46)
+ by 0x........: ??? (in /...libc...)
+ by 0x........: (below main)
Address 0x........ is not stack'd, malloc'd or (recently) free'd
Signal caught, as expected
=================================================
./valgrind-new/memcheck/tests/linux/stack_changes.stderr.diff
=================================================
--- stack_changes.stderr.exp 2011-06-16 23:37:30.000000000 -0500
+++ stack_changes.stderr.out 2011-06-16 23:56:41.000000000 -0500
@@ -0,0 +1,5 @@
+WARNING: unhandled syscall: 249
+You may be able to write your own handler.
+Read the file README_MISSING_SYSCALL_OR_IOCTL.
+Nevertheless we consider this a bug. Please report
+it at http://valgrind.org/support/bug_reports.html.
=================================================
./valgrind-new/memcheck/tests/origin5-bz2.stderr.diff-glibc212-s390x
=================================================
--- origin5-bz2.stderr.exp-glibc212-s390x 2011-06-16 23:37:32.000000000 -0500
+++ origin5-bz2.stderr.out 2011-06-16 23:58:03.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,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,18 +71,7 @@
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:2859)
- by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
- by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
- by 0x........: handle_compress (origin5-bz2.c:4753)
- by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
- by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
- by 0x........: main (origin5-bz2.c:6484)
- Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6479)
-
-Use of uninitialised value of size 8
+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)
@@ -93,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)
@@ -104,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)
@@ -115,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
<truncated beyond 100 lines>
=================================================
./valgrind-new/memcheck/tests/origin5-bz2.stderr.diff-glibc25-amd64
=================================================
--- origin5-bz2.stderr.exp-glibc25-amd64 2011-06-16 23:37:31.000000000 -0500
+++ origin5-bz2.stderr.out 2011-06-16 23:58:03.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,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 2011-06-16 23:37:32.000000000 -0500
+++ origin5-bz2.stderr.out 2011-06-16 23:58:03.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: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 2011-06-16 23:37:31.000000000 -0500
+++ origin5-bz2.stderr.out 2011-06-16 23:58:03.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,25 +9,25 @@
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
+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)
@@ -36,9 +36,9 @@
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........: mainSort (origin5-bz2.c:2823)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -47,9 +47,9 @@
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........: mainSort (origin5-bz2.c:2854)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -58,9 +58,9 @@
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........: mainSort (origin5-bz2.c:2858)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -69,9 +69,9 @@
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........: mainSort (origin5-bz2.c:2963)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -80,9 +80,9 @@
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
<truncated beyond 100 lines>
=================================================
./valgrind-new/memcheck/tests/supp_unknown.stderr.diff
=================================================
--- supp_unknown.stderr.exp 2011-06-16 23:37:31.000000000 -0500
+++ supp_unknown.stderr.out 2011-06-16 23:59:51.000000000 -0500
@@ -1,7 +1,14 @@
+Jump to the invalid address stated on the next line
+ at 0x........: ???
+ by 0x........: ??? (in /...libc...)
+ by 0x........: (below main)
+ Address 0x........ is not stack'd, malloc'd or (recently) free'd
+
Process terminating with default action of signal 11 (SIGSEGV)
Access not within mapped region at address 0x........
at 0x........: ???
+ by 0x........: ??? (in /...libc...)
by 0x........: (below main)
If you believe this happened as a result of a stack
overflow in your program's main thread (unlikely but
=================================================
./valgrind-new/memcheck/tests/supp_unknown.stderr.diff-s390x
=================================================
--- supp_unknown.stderr.exp-s390x 2011-06-16 23:37:31.000000000 -0500
+++ supp_unknown.stderr.out 2011-06-16 23:59:51.000000000 -0500
@@ -1,8 +1,15 @@
+Jump to the invalid address stated on the next line
+ at 0x........: ???
+ by 0x........: ??? (in /...libc...)
+ by 0x........: (below main)
+ Address 0x........ is not stack'd, malloc'd or (recently) free'd
+
Process terminating with default action of signal 11 (SIGSEGV)
Access not within mapped region at address 0x........
at 0x........: ???
- by 0x........: main (badjump.c:17)
+ by 0x........: ??? (in /...libc...)
+ by 0x........: (below main)
If you believe this happened as a result of a stack
overflow in your program's main thread (unlikely but
possible), you can try to increase the size of the
=================================================
./valgrind-new/memcheck/tests/varinfo6.stderr.diff
=================================================
--- varinfo6.stderr.exp 2011-06-16 23:37:32.000000000 -0500
+++ varinfo6.stderr.out 2011-06-17 00:00:34.000000000 -0500
@@ -7,8 +7,7 @@
by 0x........: BZ2_bzCompress (varinfo6.c:4860)
by 0x........: BZ2_bzBuffToBuffCompress (varinfo6.c:5667)
by 0x........: main (varinfo6.c:6517)
- Location 0x........ is 2 bytes inside local var "budget"
- declared at varinfo6.c:3115, in frame #2 of thread 1
+ Address 0x........ is on thread 1's stack
Uninitialised byte(s) found during client check request
at 0x........: croak (varinfo6.c:34)
=================================================
./valgrind-new/memcheck/tests/varinfo6.stderr.diff-ppc64
=================================================
--- varinfo6.stderr.exp-ppc64 2011-06-16 23:37:31.000000000 -0500
+++ varinfo6.stderr.out 2011-06-17 00:00:34.000000000 -0500
@@ -1,5 +1,5 @@
Uninitialised byte(s) found during client check request
- at 0x........: croak (varinfo6.c:35)
+ at 0x........: croak (varinfo6.c:34)
by 0x........: mainSort (varinfo6.c:2999)
by 0x........: BZ2_blockSort (varinfo6.c:3143)
by 0x........: BZ2_compressBlock (varinfo6.c:4072)
@@ -10,7 +10,7 @@
Address 0x........ is on thread 1's stack
Uninitialised byte(s) found during client check request
- at 0x........: croak (varinfo6.c:35)
+ at 0x........: croak (varinfo6.c:34)
by 0x........: BZ2_decompress (varinfo6.c:1699)
by 0x........: BZ2_bzDecompress (varinfo6.c:5230)
by 0x........: BZ2_bzBuffToBuffDecompress (varinfo6.c:5715)
=================================================
./valgrind-new/none/tests/linux/mremap.stderr.diff
=================================================
--- mremap.stderr.exp 2011-06-16 23:37:41.000000000 -0500
+++ mremap.stderr.out 2011-06-17 00:03:21.000000000 -0500
@@ -1,3 +1,12 @@
-mremap(grow, nomove, constrained): Cannot allocate memory
+mremap(shrink, fixed): Invalid argument
+shrink, nomove: p=0x........ np=0x........: shrink moved?!
+mremap(shrink, maymove): Invalid argument
+shrink, maymove: p=0x........ np=0x........: shrink moved?!
+mremap(grow, fixed): Invalid argument
+grow, nomove: p=0x........ np=0x........: shrink moved?!
+mremap(grow, maymove): Invalid argument
+grow, maymove: p=0x........ np=0x........: shrink moved?!
+mremap(grow, nomove, constrained): Invalid argument
+mremap(grow, maymove, constrained): Invalid argument
=================================================
./valgrind-new/none/tests/linux/mremap.stderr.diff-glibc27
=================================================
--- mremap.stderr.exp-glibc27 2011-06-16 23:37:41.000000000 -0500
+++ mremap.stderr.out 2011-06-17 00:03:21.000000000 -0500
@@ -1,6 +1,12 @@
-mremap(grow, fixed): Cannot allocate memory
+mremap(shrink, fixed): Invalid argument
+shrink, nomove: p=0x........ np=0x........: shrink moved?!
+mremap(shrink, maymove): Invalid argument
+shrink, maymove: p=0x........ np=0x........: shrink moved?!
+mremap(grow, fixed): Invalid argument
grow, nomove: p=0x........ np=0x........: shrink moved?!
+mremap(grow, maymove): Invalid argument
grow, maymove: p=0x........ np=0x........: shrink moved?!
-mremap(grow, nomove, constrained): Cannot allocate memory
+mremap(grow, nomove, constrained): Invalid argument
+mremap(grow, maymove, constrained): Invalid argument
=================================================
./valgrind-new/none/tests/ppc32/jm-fp.stderr.diff
=================================================
--- jm-fp.stderr.exp 2011-06-16 23:37:40.000000000 -0500
+++ jm-fp.stderr.out 2011-06-17 00:03:54.000000000 -0500
@@ -1,2 +1,27 @@
+disInstr(ppc): declined to decode a GeneralPurpose-Optional insn.
+disInstr(ppc): unhandled instruction: 0x........
+ primary 63(0x........), secondary 44(0x........)
+valgrind: Unrecognised instruction at address 0x.........
+ at 0x........: test_fsqrt (jm-insns.c:1986)
+ by 0x........: test_float_one_arg (jm-insns.c:5738)
+ by 0x........: ??? (in /...libc...)
+ by 0x........: (below main)
+Your program just tried to execute an instruction that Valgrind
+did not recognise. There are two possible reasons for this.
+1. Your program has a bug and erroneously jumped to a non-code
+ location. If you are running Memcheck and you just saw a
+ warning about a bad jump, it's probably your program's fault.
+2. The instruction is legitimate but Valgrind doesn't handle it,
+ i.e. it's Valgrind's fault. If you think this is the case or
+ you are not sure, please let us know and we'll try to fix it.
+Either way, Valgrind will now raise a SIGILL signal which will
+probably kill your program.
+
+Process terminating with default action of signal 4 (SIGILL)
+ Illegal opcode at address 0x........
+ at 0x........: test_fsqrt (jm-insns.c:1986)
+ by 0x........: test_float_one_arg (jm-insns.c:5738)
+ by 0x........: ??? (in /...libc...)
+ by 0x........: (below main)
=================================================
./valgrind-new/none/tests/ppc32/jm-fp.stdout.diff
=================================================
--- jm-fp.stdout.exp 2011-06-16 23:37:40.000000000 -0500
+++ jm-fp.stdout.out 2011-06-17 00:03:...
[truncated message content] |
|
From: Tom H. <th...@cy...> - 2011-06-17 02:53:07
|
Nightly build on bristol ( x86_64, Fedora 9 )
Started at 2011-06-17 03:40:42 BST
Ended at 2011-06-17 03:52:43 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
== 561 tests, 19 stderr failures, 4 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
cachegrind/tests/chdir (stderr)
cachegrind/tests/clreq (stderr)
cachegrind/tests/dlclose (stderr)
cachegrind/tests/notpower2 (stderr)
cachegrind/tests/wrap5 (stderr)
cachegrind/tests/x86/fpu-28-108 (stderr)
callgrind/tests/notpower2-hwpref (stderr)
callgrind/tests/notpower2-use (stderr)
callgrind/tests/notpower2-wb (stderr)
callgrind/tests/notpower2 (stderr)
callgrind/tests/simwork-both (stderr)
callgrind/tests/simwork-cache (stderr)
callgrind/tests/simwork1 (stderr)
callgrind/tests/simwork2 (stderr)
callgrind/tests/simwork3 (stderr)
callgrind/tests/threads-use (stderr)
none/tests/amd64/bug132918 (stdout)
none/tests/amd64/fxtract (stdout)
none/tests/amd64/sse4-64 (stdout)
none/tests/x86/fxtract (stdout)
helgrind/tests/tc06_two_races_xml (stderr)
helgrind/tests/tc20_verifywrap (stderr)
helgrind/tests/tc23_bogus_condwait (stderr)
=================================================
== Results from 24 hours ago ==
=================================================
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... failed
Last 20 lines of verbose log follow echo
mc_translate.c:3418: error: 'Iop_QShortenU16Ux8' undeclared (first use in this function)
mc_translate.c:3419: error: 'Iop_QShortenS32Sx4' undeclared (first use in this function)
mc_translate.c:3420: error: 'Iop_QShortenU32Sx4' undeclared (first use in this function)
mc_translate.c:3421: error: 'Iop_QShortenU32Ux4' undeclared (first use in this function)
mc_translate.c:3422: error: 'Iop_QShortenS64Sx2' undeclared (first use in this function)
mc_translate.c:3423: error: 'Iop_QShortenU64Sx2' undeclared (first use in this function)
mc_translate.c:3424: error: 'Iop_QShortenU64Ux2' undeclared (first use in this function)
mc_translate.c:3427: error: 'Iop_Longen8Sx8' undeclared (first use in this function)
mc_translate.c:3428: error: 'Iop_Longen8Ux8' undeclared (first use in this function)
mc_translate.c:3429: error: 'Iop_Longen16Sx4' undeclared (first use in this function)
mc_translate.c:3430: error: 'Iop_Longen16Ux4' undeclared (first use in this function)
mc_translate.c:3431: error: 'Iop_Longen32Sx2' undeclared (first use in this function)
mc_translate.c:3432: error: 'Iop_Longen32Ux2' undeclared (first use in this function)
make[3]: *** [memcheck_amd64_linux-mc_translate.o] Error 1
make[3]: Leaving directory `/tmp/vgtest-17905/2011-06-17/valgrind-old/memcheck'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/tmp/vgtest-17905/2011-06-17/valgrind-old/memcheck'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/vgtest-17905/2011-06-17/valgrind-old'
make: *** [all] Error 2
=================================================
== Difference between 24 hours ago and now ==
=================================================
*** old.short Fri Jun 17 03:43:00 2011
--- new.short Fri Jun 17 03:52:43 2011
***************
*** 3,26 ****
Configuring valgrind ... done
! Building valgrind ... failed
- Last 20 lines of verbose log follow echo
- mc_translate.c:3418: error: 'Iop_QShortenU16Ux8' undeclared (first use in this function)
- mc_translate.c:3419: error: 'Iop_QShortenS32Sx4' undeclared (first use in this function)
- mc_translate.c:3420: error: 'Iop_QShortenU32Sx4' undeclared (first use in this function)
- mc_translate.c:3421: error: 'Iop_QShortenU32Ux4' undeclared (first use in this function)
- mc_translate.c:3422: error: 'Iop_QShortenS64Sx2' undeclared (first use in this function)
- mc_translate.c:3423: error: 'Iop_QShortenU64Sx2' undeclared (first use in this function)
- mc_translate.c:3424: error: 'Iop_QShortenU64Ux2' undeclared (first use in this function)
- mc_translate.c:3427: error: 'Iop_Longen8Sx8' undeclared (first use in this function)
- mc_translate.c:3428: error: 'Iop_Longen8Ux8' undeclared (first use in this function)
- mc_translate.c:3429: error: 'Iop_Longen16Sx4' undeclared (first use in this function)
- mc_translate.c:3430: error: 'Iop_Longen16Ux4' undeclared (first use in this function)
- mc_translate.c:3431: error: 'Iop_Longen32Sx2' undeclared (first use in this function)
- mc_translate.c:3432: error: 'Iop_Longen32Ux2' undeclared (first use in this function)
- make[3]: *** [memcheck_amd64_linux-mc_translate.o] Error 1
- make[3]: Leaving directory `/tmp/vgtest-17905/2011-06-17/valgrind-old/memcheck'
- make[2]: *** [all-recursive] Error 1
- make[2]: Leaving directory `/tmp/vgtest-17905/2011-06-17/valgrind-old/memcheck'
- make[1]: *** [all-recursive] Error 1
- make[1]: Leaving directory `/tmp/vgtest-17905/2011-06-17/valgrind-old'
- make: *** [all] Error 2
--- 3,33 ----
Configuring valgrind ... done
! Building valgrind ... done
! Running regression tests ... failed
!
! Regression test results follow
!
! == 561 tests, 19 stderr failures, 4 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
! cachegrind/tests/chdir (stderr)
! cachegrind/tests/clreq (stderr)
! cachegrind/tests/dlclose (stderr)
! cachegrind/tests/notpower2 (stderr)
! cachegrind/tests/wrap5 (stderr)
! cachegrind/tests/x86/fpu-28-108 (stderr)
! callgrind/tests/notpower2-hwpref (stderr)
! callgrind/tests/notpower2-use (stderr)
! callgrind/tests/notpower2-wb (stderr)
! callgrind/tests/notpower2 (stderr)
! callgrind/tests/simwork-both (stderr)
! callgrind/tests/simwork-cache (stderr)
! callgrind/tests/simwork1 (stderr)
! callgrind/tests/simwork2 (stderr)
! callgrind/tests/simwork3 (stderr)
! callgrind/tests/threads-use (stderr)
! none/tests/amd64/bug132918 (stdout)
! none/tests/amd64/fxtract (stdout)
! none/tests/amd64/sse4-64 (stdout)
! none/tests/x86/fxtract (stdout)
! helgrind/tests/tc06_two_races_xml (stderr)
! helgrind/tests/tc20_verifywrap (stderr)
! helgrind/tests/tc23_bogus_condwait (stderr)
|
|
From: Tom H. <th...@cy...> - 2011-06-17 02:43:16
|
Nightly build on bristol ( x86_64, Fedora 11 )
Started at 2011-06-17 03:30:30 BST
Ended at 2011-06-17 03:42:00 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
== 561 tests, 19 stderr failures, 4 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
memcheck/tests/linux/stack_switch (stderr)
memcheck/tests/long_namespace_xml (stderr)
cachegrind/tests/chdir (stderr)
cachegrind/tests/clreq (stderr)
cachegrind/tests/dlclose (stderr)
cachegrind/tests/notpower2 (stderr)
cachegrind/tests/wrap5 (stderr)
cachegrind/tests/x86/fpu-28-108 (stderr)
callgrind/tests/notpower2-hwpref (stderr)
callgrind/tests/notpower2-use (stderr)
callgrind/tests/notpower2-wb (stderr)
callgrind/tests/notpower2 (stderr)
callgrind/tests/simwork-both (stderr)
callgrind/tests/simwork-cache (stderr)
callgrind/tests/simwork1 (stderr)
callgrind/tests/simwork2 (stderr)
callgrind/tests/simwork3 (stderr)
callgrind/tests/threads-use (stderr)
none/tests/amd64/bug132918 (stdout)
none/tests/amd64/fxtract (stdout)
none/tests/amd64/sse4-64 (stdout)
none/tests/x86/fxtract (stdout)
helgrind/tests/tc06_two_races_xml (stderr)
=================================================
== Results from 24 hours ago ==
=================================================
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... failed
Last 20 lines of verbose log follow echo
mc_translate.c:3418: error: 'Iop_QShortenU16Ux8' undeclared (first use in this function)
mc_translate.c:3419: error: 'Iop_QShortenS32Sx4' undeclared (first use in this function)
mc_translate.c:3420: error: 'Iop_QShortenU32Sx4' undeclared (first use in this function)
mc_translate.c:3421: error: 'Iop_QShortenU32Ux4' undeclared (first use in this function)
mc_translate.c:3422: error: 'Iop_QShortenS64Sx2' undeclared (first use in this function)
mc_translate.c:3423: error: 'Iop_QShortenU64Sx2' undeclared (first use in this function)
mc_translate.c:3424: error: 'Iop_QShortenU64Ux2' undeclared (first use in this function)
mc_translate.c:3427: error: 'Iop_Longen8Sx8' undeclared (first use in this function)
mc_translate.c:3428: error: 'Iop_Longen8Ux8' undeclared (first use in this function)
mc_translate.c:3429: error: 'Iop_Longen16Sx4' undeclared (first use in this function)
mc_translate.c:3430: error: 'Iop_Longen16Ux4' undeclared (first use in this function)
mc_translate.c:3431: error: 'Iop_Longen32Sx2' undeclared (first use in this function)
mc_translate.c:3432: error: 'Iop_Longen32Ux2' undeclared (first use in this function)
make[3]: *** [memcheck_amd64_linux-mc_translate.o] Error 1
make[3]: Leaving directory `/tmp/vgtest-16801/2011-06-17/valgrind-old/memcheck'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/tmp/vgtest-16801/2011-06-17/valgrind-old/memcheck'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/vgtest-16801/2011-06-17/valgrind-old'
make: *** [all] Error 2
=================================================
== Difference between 24 hours ago and now ==
=================================================
*** old.short Fri Jun 17 03:32:35 2011
--- new.short Fri Jun 17 03:42:00 2011
***************
*** 3,26 ****
Configuring valgrind ... done
! Building valgrind ... failed
- Last 20 lines of verbose log follow echo
- mc_translate.c:3418: error: 'Iop_QShortenU16Ux8' undeclared (first use in this function)
- mc_translate.c:3419: error: 'Iop_QShortenS32Sx4' undeclared (first use in this function)
- mc_translate.c:3420: error: 'Iop_QShortenU32Sx4' undeclared (first use in this function)
- mc_translate.c:3421: error: 'Iop_QShortenU32Ux4' undeclared (first use in this function)
- mc_translate.c:3422: error: 'Iop_QShortenS64Sx2' undeclared (first use in this function)
- mc_translate.c:3423: error: 'Iop_QShortenU64Sx2' undeclared (first use in this function)
- mc_translate.c:3424: error: 'Iop_QShortenU64Ux2' undeclared (first use in this function)
- mc_translate.c:3427: error: 'Iop_Longen8Sx8' undeclared (first use in this function)
- mc_translate.c:3428: error: 'Iop_Longen8Ux8' undeclared (first use in this function)
- mc_translate.c:3429: error: 'Iop_Longen16Sx4' undeclared (first use in this function)
- mc_translate.c:3430: error: 'Iop_Longen16Ux4' undeclared (first use in this function)
- mc_translate.c:3431: error: 'Iop_Longen32Sx2' undeclared (first use in this function)
- mc_translate.c:3432: error: 'Iop_Longen32Ux2' undeclared (first use in this function)
- make[3]: *** [memcheck_amd64_linux-mc_translate.o] Error 1
- make[3]: Leaving directory `/tmp/vgtest-16801/2011-06-17/valgrind-old/memcheck'
- make[2]: *** [all-recursive] Error 1
- make[2]: Leaving directory `/tmp/vgtest-16801/2011-06-17/valgrind-old/memcheck'
- make[1]: *** [all-recursive] Error 1
- make[1]: Leaving directory `/tmp/vgtest-16801/2011-06-17/valgrind-old'
- make: *** [all] Error 2
--- 3,33 ----
Configuring valgrind ... done
! Building valgrind ... done
! Running regression tests ... failed
!
! Regression test results follow
!
! == 561 tests, 19 stderr failures, 4 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
! memcheck/tests/linux/stack_switch (stderr)
! memcheck/tests/long_namespace_xml (stderr)
! cachegrind/tests/chdir (stderr)
! cachegrind/tests/clreq (stderr)
! cachegrind/tests/dlclose (stderr)
! cachegrind/tests/notpower2 (stderr)
! cachegrind/tests/wrap5 (stderr)
! cachegrind/tests/x86/fpu-28-108 (stderr)
! callgrind/tests/notpower2-hwpref (stderr)
! callgrind/tests/notpower2-use (stderr)
! callgrind/tests/notpower2-wb (stderr)
! callgrind/tests/notpower2 (stderr)
! callgrind/tests/simwork-both (stderr)
! callgrind/tests/simwork-cache (stderr)
! callgrind/tests/simwork1 (stderr)
! callgrind/tests/simwork2 (stderr)
! callgrind/tests/simwork3 (stderr)
! callgrind/tests/threads-use (stderr)
! none/tests/amd64/bug132918 (stdout)
! none/tests/amd64/fxtract (stdout)
! none/tests/amd64/sse4-64 (stdout)
! none/tests/x86/fxtract (stdout)
! helgrind/tests/tc06_two_races_xml (stderr)
|
|
From: Rich C. <rc...@wi...> - 2011-06-17 02:43:15
|
Nightly build on ultra ( gcc 4.5.1 Linux 2.6.37.1-1.2-desktop x86_64 )
Started at 2011-06-16 21:30:01 CDT
Ended at 2011-06-16 21:43:04 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
== 567 tests, 76 stderr failures, 56 stdout failures, 1 stderrB failure, 0 stdoutB failures, 3 post failures ==
gdbserver_tests/mssnapshot (stderrB)
memcheck/tests/linux/stack_switch (stderr)
memcheck/tests/origin5-bz2 (stderr)
memcheck/tests/x86/bug152022 (stderr)
memcheck/tests/x86/espindola2 (stderr)
memcheck/tests/x86/fpeflags (stderr)
memcheck/tests/x86/fprem (stdout)
memcheck/tests/x86/fprem (stderr)
memcheck/tests/x86/fxsave (stdout)
memcheck/tests/x86/fxsave (stderr)
memcheck/tests/x86/insn_basic (stdout)
memcheck/tests/x86/insn_basic (stderr)
memcheck/tests/x86/insn_cmov (stdout)
memcheck/tests/x86/insn_cmov (stderr)
memcheck/tests/x86/insn_fpu (stdout)
memcheck/tests/x86/insn_fpu (stderr)
memcheck/tests/x86/insn_mmx (stdout)
memcheck/tests/x86/insn_mmx (stderr)
memcheck/tests/x86/insn_sse (stdout)
memcheck/tests/x86/insn_sse (stderr)
memcheck/tests/x86/insn_sse2 (stdout)
memcheck/tests/x86/insn_sse2 (stderr)
memcheck/tests/x86/more_x86_fp (stdout)
memcheck/tests/x86/more_x86_fp (stderr)
memcheck/tests/x86/pushfpopf (stdout)
memcheck/tests/x86/pushfpopf (stderr)
memcheck/tests/x86/pushfw_x86 (stdout)
memcheck/tests/x86/pushfw_x86 (stderr)
memcheck/tests/x86/pushpopmem (stdout)
memcheck/tests/x86/pushpopmem (stderr)
memcheck/tests/x86/sse1_memory (stdout)
memcheck/tests/x86/sse1_memory (stderr)
memcheck/tests/x86/sse2_memory (stdout)
memcheck/tests/x86/sse2_memory (stderr)
memcheck/tests/x86/tronical (stderr)
memcheck/tests/x86/xor-undef-x86 (stdout)
memcheck/tests/x86/xor-undef-x86 (stderr)
memcheck/tests/x86-linux/bug133694 (stdout)
memcheck/tests/x86-linux/bug133694 (stderr)
memcheck/tests/x86-linux/int3-x86 (stdout)
memcheck/tests/x86-linux/int3-x86 (stderr)
memcheck/tests/x86-linux/scalar (stderr)
memcheck/tests/x86-linux/scalar_exit_group (stderr)
memcheck/tests/x86-linux/scalar_fork (stderr)
memcheck/tests/x86-linux/scalar_supp (stderr)
memcheck/tests/x86-linux/scalar_vfork (stderr)
cachegrind/tests/x86/fpu-28-108 (stderr)
none/tests/x86/aad_aam (stdout)
none/tests/x86/aad_aam (stderr)
none/tests/x86/badseg (stdout)
none/tests/x86/badseg (stderr)
none/tests/x86/bt_everything (stdout)
none/tests/x86/bt_everything (stderr)
none/tests/x86/bt_literal (stdout)
none/tests/x86/bt_literal (stderr)
none/tests/x86/bug125959-x86 (stdout)
none/tests/x86/bug125959-x86 (stderr)
none/tests/x86/bug126147-x86 (stdout)
none/tests/x86/bug126147-x86 (stderr)
none/tests/x86/bug132813-x86 (stdout)
none/tests/x86/bug132813-x86 (stderr)
none/tests/x86/bug135421-x86 (stdout)
none/tests/x86/bug135421-x86 (stderr)
none/tests/x86/bug137714-x86 (stdout)
none/tests/x86/bug137714-x86 (stderr)
none/tests/x86/bug152818-x86 (stdout)
none/tests/x86/bug152818-x86 (stderr)
none/tests/x86/cmpxchg8b (stdout)
none/tests/x86/cmpxchg8b (stderr)
none/tests/x86/cpuid (stdout)
none/tests/x86/cpuid (stderr)
none/tests/x86/cse_fail (stdout)
none/tests/x86/cse_fail (stderr)
none/tests/x86/fcmovnu (stdout)
none/tests/x86/fcmovnu (stderr)
none/tests/x86/fpu_lazy_eflags (stdout)
none/tests/x86/fpu_lazy_eflags (stderr)
none/tests/x86/fxtract (stdout)
none/tests/x86/fxtract (stderr)
none/tests/x86/getseg (stdout)
none/tests/x86/getseg (stderr)
none/tests/x86/incdec_alt (stdout)
none/tests/x86/incdec_alt (stderr)
none/tests/x86/insn_basic (stdout)
none/tests/x86/insn_basic (stderr)
none/tests/x86/insn_cmov (stdout)
none/tests/x86/insn_cmov (stderr)
none/tests/x86/insn_fpu (stdout)
none/tests/x86/insn_fpu (stderr)
none/tests/x86/insn_mmx (stdout)
none/tests/x86/insn_mmx (stderr)
none/tests/x86/insn_sse (stdout)
none/tests/x86/insn_sse (stderr)
none/tests/x86/insn_sse2 (stdout)
none/tests/x86/insn_sse2 (stderr)
none/tests/x86/insn_sse3 (stdout)
none/tests/x86/insn_sse3 (stderr)
none/tests/x86/insn_ssse3 (stdout)
none/tests/x86/insn_ssse3 (stderr)
none/tests/x86/jcxz (stdout)
none/tests/x86/jcxz (stderr)
none/tests/x86/lahf (stdout)
none/tests/x86/lahf (stderr)
none/tests/x86/looper (stdout)
none/tests/x86/looper (stderr)
none/tests/x86/movx (stdout)
none/tests/x86/movx (stderr)
none/tests/x86/pushpopseg (stdout)
none/tests/x86/pushpopseg (stderr)
none/tests/x86/sbbmisc (stdout)
none/tests/x86/sbbmisc (stderr)
none/tests/x86/shift_ndep (stdout)
none/tests/x86/shift_ndep (stderr)
none/tests/x86/smc1 (stdout)
none/tests/x86/smc1 (stderr)
none/tests/x86/ssse3_misaligned (stderr)
none/tests/x86/x86locked (stdout)
none/tests/x86/x86locked (stderr)
none/tests/x86/xadd (stdout)
none/tests/x86/xadd (stderr)
none/tests/x86-linux/seg_override (stdout)
none/tests/x86-linux/seg_override (stderr)
none/tests/x86-linux/sigcontext (stdout)
none/tests/x86-linux/sigcontext (stderr)
helgrind/tests/tc06_two_races_xml (stderr)
exp-sgcheck/tests/bad_percentify (stderr)
exp-bbv/tests/x86/complex_rep (stderr)
exp-bbv/tests/x86/fldcw_check (stderr)
exp-bbv/tests/x86/million (stderr)
exp-bbv/tests/x86/rep_prefix (stderr)
exp-bbv/tests/x86-linux/clone_test (stderr)
exp-bbv/tests/x86-linux/clone_test (post)
exp-bbv/tests/x86-linux/ll (stdout)
exp-bbv/tests/x86-linux/ll (stderr)
=================================================
== Results from 24 hours ago ==
=================================================
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... failed
Last 20 lines of verbose log follow echo
mc_translate.c:3418:12: error: 'Iop_QShortenU16Ux8' undeclared (first use in this function)
mc_translate.c:3419:12: error: 'Iop_QShortenS32Sx4' undeclared (first use in this function)
mc_translate.c:3420:12: error: 'Iop_QShortenU32Sx4' undeclared (first use in this function)
mc_translate.c:3421:12: error: 'Iop_QShortenU32Ux4' undeclared (first use in this function)
mc_translate.c:3422:12: error: 'Iop_QShortenS64Sx2' undeclared (first use in this function)
mc_translate.c:3423:12: error: 'Iop_QShortenU64Sx2' undeclared (first use in this function)
mc_translate.c:3424:12: error: 'Iop_QShortenU64Ux2' undeclared (first use in this function)
mc_translate.c:3427:12: error: 'Iop_Longen8Sx8' undeclared (first use in this function)
mc_translate.c:3428:12: error: 'Iop_Longen8Ux8' undeclared (first use in this function)
mc_translate.c:3429:12: error: 'Iop_Longen16Sx4' undeclared (first use in this function)
mc_translate.c:3430:12: error: 'Iop_Longen16Ux4' undeclared (first use in this function)
mc_translate.c:3431:12: error: 'Iop_Longen32Sx2' undeclared (first use in this function)
mc_translate.c:3432:12: error: 'Iop_Longen32Ux2' undeclared (first use in this function)
make[3]: *** [memcheck_amd64_linux-mc_translate.o] Error 1
make[3]: Leaving directory `/home/coe/src/vg/nightly/valgrind-old/memcheck'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/coe/src/vg/nightly/valgrind-old/memcheck'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/coe/src/vg/nightly/valgrind-old'
make: *** [all] Error 2
=================================================
== Difference between 24 hours ago and now ==
=================================================
*** old.short Thu Jun 16 21:32:39 2011
--- new.short Thu Jun 16 21:43:04 2011
***************
*** 3,26 ****
Configuring valgrind ... done
! Building valgrind ... failed
- Last 20 lines of verbose log follow echo
- mc_translate.c:3418:12: error: 'Iop_QShortenU16Ux8' undeclared (first use in this function)
- mc_translate.c:3419:12: error: 'Iop_QShortenS32Sx4' undeclared (first use in this function)
- mc_translate.c:3420:12: error: 'Iop_QShortenU32Sx4' undeclared (first use in this function)
- mc_translate.c:3421:12: error: 'Iop_QShortenU32Ux4' undeclared (first use in this function)
- mc_translate.c:3422:12: error: 'Iop_QShortenS64Sx2' undeclared (first use in this function)
- mc_translate.c:3423:12: error: 'Iop_QShortenU64Sx2' undeclared (first use in this function)
- mc_translate.c:3424:12: error: 'Iop_QShortenU64Ux2' undeclared (first use in this function)
- mc_translate.c:3427:12: error: 'Iop_Longen8Sx8' undeclared (first use in this function)
- mc_translate.c:3428:12: error: 'Iop_Longen8Ux8' undeclared (first use in this function)
- mc_translate.c:3429:12: error: 'Iop_Longen16Sx4' undeclared (first use in this function)
- mc_translate.c:3430:12: error: 'Iop_Longen16Ux4' undeclared (first use in this function)
- mc_translate.c:3431:12: error: 'Iop_Longen32Sx2' undeclared (first use in this function)
- mc_translate.c:3432:12: error: 'Iop_Longen32Ux2' undeclared (first use in this function)
- make[3]: *** [memcheck_amd64_linux-mc_translate.o] Error 1
- make[3]: Leaving directory `/home/coe/src/vg/nightly/valgrind-old/memcheck'
- make[2]: *** [all-recursive] Error 1
- make[2]: Leaving directory `/home/coe/src/vg/nightly/valgrind-old/memcheck'
- make[1]: *** [all-recursive] Error 1
- make[1]: Leaving directory `/home/coe/src/vg/nightly/valgrind-old'
- make: *** [all] Error 2
--- 3,144 ----
Configuring valgrind ... done
! Building valgrind ... done
! Running regression tests ... failed
!
! Regression test results follow
!
! == 567 tests, 76 stderr failures, 56 stdout failures, 1 stderrB failure, 0 stdoutB failures, 3 post failures ==
! gdbserver_tests/mssnapshot (stderrB)
! memcheck/tests/linux/stack_switch (stderr)
! memcheck/tests/origin5-bz2 (stderr)
! memcheck/tests/x86/bug152022 (stderr)
! memcheck/tests/x86/espindola2 (stderr)
! memcheck/tests/x86/fpeflags (stderr)
! memcheck/tests/x86/fprem (stdout)
! memcheck/tests/x86/fprem (stderr)
! memcheck/tests/x86/fxsave (stdout)
! memcheck/tests/x86/fxsave (stderr)
! memcheck/tests/x86/insn_basic (stdout)
! memcheck/tests/x86/insn_basic (stderr)
! memcheck/tests/x86/insn_cmov (stdout)
! memcheck/tests/x86/insn_cmov (stderr)
! memcheck/tests/x86/insn_fpu (stdout)
! memcheck/tests/x86/insn_fpu (stderr)
! memcheck/tests/x86/insn_mmx (stdout)
! memcheck/tests/x86/insn_mmx (stderr)
! memcheck/tests/x86/insn_sse (stdout)
! memcheck/tests/x86/insn_sse (stderr)
! memcheck/tests/x86/insn_sse2 (stdout)
! memcheck/tests/x86/insn_sse2 (stderr)
! memcheck/tests/x86/more_x86_fp (stdout)
! memcheck/tests/x86/more_x86_fp (stderr)
! memcheck/tests/x86/pushfpopf (stdout)
! memcheck/tests/x86/pushfpopf (stderr)
! memcheck/tests/x86/pushfw_x86 (stdout)
! memcheck/tests/x86/pushfw_x86 (stderr)
! memcheck/tests/x86/pushpopmem (stdout)
! memcheck/tests/x86/pushpopmem (stderr)
! memcheck/tests/x86/sse1_memory (stdout)
! memcheck/tests/x86/sse1_memory (stderr)
! memcheck/tests/x86/sse2_memory (stdout)
! memcheck/tests/x86/sse2_memory (stderr)
! memcheck/tests/x86/tronical (stderr)
! memcheck/tests/x86/xor-undef-x86 (stdout)
! memcheck/tests/x86/xor-undef-x86 (stderr)
! memcheck/tests/x86-linux/bug133694 (stdout)
! memcheck/tests/x86-linux/bug133694 (stderr)
! memcheck/tests/x86-linux/int3-x86 (stdout)
! memcheck/tests/x86-linux/int3-x86 (stderr)
! memcheck/tests/x86-linux/scalar (stderr)
! memcheck/tests/x86-linux/scalar_exit_group (stderr)
! memcheck/tests/x86-linux/scalar_fork (stderr)
! memcheck/tests/x86-linux/scalar_supp (stderr)
! memcheck/tests/x86-linux/scalar_vfork (stderr)
! cachegrind/tests/x86/fpu-28-108 (stderr)
! none/tests/x86/aad_aam (stdout)
! none/tests/x86/aad_aam (stderr)
! none/tests/x86/badseg (stdout)
! none/tests/x86/badseg (stderr)
! none/tests/x86/bt_everything (stdout)
! none/tests/x86/bt_everything (stderr)
! none/tests/x86/bt_literal (stdout)
! none/tests/x86/bt_literal (stderr)
! none/tests/x86/bug125959-x86 (stdout)
! none/tests/x86/bug125959-x86 (stderr)
! none/tests/x86/bug126147-x86 (stdout)
! none/tests/x86/bug126147-x86 (stderr)
! none/tests/x86/bug132813-x86 (stdout)
! none/tests/x86/bug132813-x86 (stderr)
! none/tests/x86/bug135421-x86 (stdout)
! none/tests/x86/bug135421-x86 (stderr)
! none/tests/x86/bug137714-x86 (stdout)
! none/tests/x86/bug137714-x86 (stderr)
! none/tests/x86/bug152818-x86 (stdout)
! none/tests/x86/bug152818-x86 (stderr)
! none/tests/x86/cmpxchg8b (stdout)
! none/tests/x86/cmpxchg8b (stderr)
! none/tests/x86/cpuid (stdout)
! none/tests/x86/cpuid (stderr)
! none/tests/x86/cse_fail (stdout)
! none/tests/x86/cse_fail (stderr)
! none/tests/x86/fcmovnu (stdout)
! none/tests/x86/fcmovnu (stderr)
! none/tests/x86/fpu_lazy_eflags (stdout)
! none/tests/x86/fpu_lazy_eflags (stderr)
! none/tests/x86/fxtract (stdout)
! none/tests/x86/fxtract (stderr)
! none/tests/x86/getseg (stdout)
! none/tests/x86/getseg (stderr)
! none/tests/x86/incdec_alt (stdout)
! none/tests/x86/incdec_alt (stderr)
! none/tests/x86/insn_basic (stdout)
! none/tests/x86/insn_basic (stderr)
! none/tests/x86/insn_cmov (stdout)
! none/tests/x86/insn_cmov (stderr)
! none/tests/x86/insn_fpu (stdout)
! none/tests/x86/insn_fpu (stderr)
! none/tests/x86/insn_mmx (stdout)
! none/tests/x86/insn_mmx (stderr)
! none/tests/x86/insn_sse (stdout)
! none/tests/x86/insn_sse (stderr)
! none/tests/x86/insn_sse2 (stdout)
! none/tests/x86/insn_sse2 (stderr)
! none/tests/x86/insn_sse3 (stdout)
! none/tests/x86/insn_sse3 (stderr)
! none/tests/x86/insn_ssse3 (stdout)
! none/tests/x86/insn_ssse3 (stderr)
! none/tests/x86/jcxz (stdout)
! none/tests/x86/jcxz (stderr)
! none/tests/x86/lahf (stdout)
! none/tests/x86/lahf (stderr)
! none/tests/x86/looper (stdout)
! none/tests/x86/looper (stderr)
! none/tests/x86/movx (stdout)
! none/tests/x86/movx (stderr)
! none/tests/x86/pushpopseg (stdout)
! none/tests/x86/pushpopseg (stderr)
! none/tests/x86/sbbmisc (stdout)
! none/tests/x86/sbbmisc (stderr)
! none/tests/x86/shift_ndep (stdout)
! none/tests/x86/shift_ndep (stderr)
! none/tests/x86/smc1 (stdout)
! none/tests/x86/smc1 (stderr)
! none/tests/x86/ssse3_misaligned (stderr)
! none/tests/x86/x86locked (stdout)
! none/tests/x86/x86locked (stderr)
! none/tests/x86/xadd (stdout)
! none/tests/x86/xadd (stderr)
! none/tests/x86-linux/seg_override (stdout)
! none/tests/x86-linux/seg_override (stderr)
! none/tests/x86-linux/sigcontext (stdout)
! none/tests/x86-linux/sigcontext (stderr)
! helgrind/tests/tc06_two_races_xml (stderr)
! exp-sgcheck/tests/bad_percentify (stderr)
! exp-bbv/tests/x86/complex_rep (stderr)
! exp-bbv/tests/x86/fldcw_check (stderr)
! exp-bbv/tests/x86/million (stderr)
! exp-bbv/tests/x86/rep_prefix (stderr)
! exp-bbv/tests/x86-linux/clone_test (stderr)
! exp-bbv/tests/x86-linux/clone_test (post)
! exp-bbv/tests/x86-linux/ll (stdout)
! exp-bbv/tests/x86-linux/ll (stderr)
=================================================
./valgrind-new/cachegrind/tests/x86/fpu-28-108.stderr.diff
=================================================
--- fpu-28-108.stderr.exp 2011-06-16 21:32:55.847033548 -0500
+++ fpu-28-108.stderr.out 2011-06-16 21:38:32.606624632 -0500
@@ -1,17 +1 @@
-
-
-I refs:
-I1 misses:
-LLi misses:
-I1 miss rate:
-LLi miss rate:
-
-D refs:
-D1 misses:
-LLd misses:
-D1 miss rate:
-LLd miss rate:
-
-LL refs:
-LL misses:
-LL miss rate:
+valgrind: ./fpu-28-108: No such file or directory
=================================================
./valgrind-new/exp-bbv/tests/x86-linux/clone_test.post.diff
=================================================
--- clone_test.post.exp 2011-06-16 21:32:46.449602922 -0500
+++ clone_test.post.out 2011-06-16 21:43:03.975168120 -0500
@@ -1,58 +0,0 @@
-T 4 996 5 2 3 98991
-T 100000
-T 100000
-T 100000
-T 100000
-T 100000
-T 100000
-T 100000
-T 100000
-T 100000
-T 1001 2 3 98994
-T 100000
-T 100000
-T 100000
-T 100000
-
-
-# Thread 1
-# Total intervals: 15 (Interval Size 100000)
-# Total instructions: 1501007
-# Total reps: 0
-# Unique reps: 0
-# Total fldcw instructions: 0
-
-T 2 3 99996
-T 100000
-T 100000
-T 100000
-T 100000
-T 100000
-T 100000
-T 100000
-T 100000
-T 100000
-T 100000
-T 100000
-T 100000
-T 100000
-T 100000
-T 100000
-T 100000
-T 100000
-T 100000
-T 99996 4
-T 100000
-T 100000
-T 100000
-T 100000
-T 99998 2
-
-
-# Thread 2
-# Total intervals: 25 (Interval Size 100000)
-# Total instructions: 2500001
-# Total reps: 0
-# Unique reps: 0
-# Total fldcw instructions: 0
-
=================================================
./valgrind-new/exp-bbv/tests/x86-linux/clone_test.stderr.diff
=================================================
--- clone_test.stderr.exp 2011-06-16 21:32:46.449602922 -0500
+++ clone_test.stderr.out 2011-06-16 21:43:03.957169211 -0500
@@ -1,12 +0,0 @@
-# Thread 1
-# Total intervals: 15 (Interval Size 100000)
-# Total instructions: 1501007
-# Total reps: 0
-# Unique reps: 0
-# Total fldcw instructions: 0
-# Thread 2
-# Total intervals: 25 (Interval Size 100000)
-# Total instructions: 2500001
-# Total reps: 0
-# Unique reps: 0
-# Total fldcw instructions: 0
=================================================
./valgrind-new/exp-bbv/tests/x86-linux/ll.stderr.diff
=================================================
--- ll.stderr.exp 2011-06-16 21:32:46.448602983 -0500
+++ ll.stderr.out 2011-06-16 21:43:03.997166785 -0500
@@ -1,6 +0,0 @@
-# Thread 1
-# Total intervals: 39 (Interval Size 1000)
-# Total instructions: 39439
-# Total reps: 0
-# Unique reps: 0
-# Total fldcw instructions: 0
=================================================
./valgrind-new/exp-bbv/tests/x86-linux/ll.stdout.diff
=================================================
--- ll.stdout.exp 2011-06-16 21:32:46.448602983 -0500
+++ ll.stdout.out 2011-06-16 21:43:03.992167088 -0500
@@ -1,17 +0,0 @@
-[0;1;37;47m#################################################################[0;30;47m#####[1;37m#########[1;37;40m
-[0;1;37;47m################################################################[0;30;47m#######[1;37m########[1;37;40m
-[0;1;37;47m###################[31m#[37m############################################[0;30;47m##[1;37mO[0;30;47m#[1;37mO[0;30;47m##[1;37m########[1;37;40m
-[0;1;37;47m##[0;30;47m######[1;37m##########[31m##[0;30;47m#[1;37m###########################################[0;30;47m#[1;33m#####[0;30;47m#[1;37m########[1;37;40m
-[0;1;37;47m####[0;30;47m##[1;37m#############[0;30;47m#[1;37m##########################################[0;30;47m##[1;37m##[33m###[37m##[0;30;47m##[1;37m######[1;37;40m
-[0;1;37;47m####[0;30;47m##[1;37m#########[31m###[37m###[0;30;47m###[1;37m#[0;30;47m####[1;37m###[0;30;47m###[1;37m####[0;30;47m###[1;37m##[0;30;47m#####[1;37m#[0;30;47m######[1;37m#####[0;30;47m#[1;37m##########[0;30;47m##[1;37m#####[1;37;40m
-[0;1;37;47m####[0;30;47m##[1;37m########[31m#[37m##[31m#[0;30;47m#[1;37m###[0;30;47m###[1;37m####[0;30;47m##[1;37m##[0;30;47m##[1;37m#####[0;30;47m##[1;37m####[0;30;47m##[1;37m###[0;30;47m##[1;37m#######[0;30;47m#[1;37m############[0;30;47m##[1;37m####[1;37;40m
-[0;1;37;47m####[0;30;47m##[1;37m#######[31m#[37m###[31m#[0;30;47m#[1;37m###[0;30;47m##[1;37m#####[0;30;47m##[1;37m##[0;30;47m##[1;37m#####[0;30;47m##[1;37m######[0;30;47m###[1;37m#########[0;30;47m#[1;37m############[0;30;47m###[1;37m###[1;37;40m
-[0;1;37;47m####[0;30;47m##[1;37m##########[31m##[0;30;47m#[1;37m###[0;30;47m##[1;37m#####[0;30;47m##[1;37m##[0;30;47m##[1;37m#####[0;30;47m##[1;37m######[0;30;47m###[1;37m########[33m##[0;30;47m#[1;37m###########[0;30;47m##[1;33m#[37m###[1;37;40m
-[0;1;37;47m####[0;30;47m##[1;37m#######[0;30;47m#[1;37m#[31m##[0;30;47m#[1;37m####[0;30;47m##[1;37m#####[0;30;47m##[1;37m##[0;30;47m##[1;37m#####[0;30;47m##[1;37m#####[0;30;47m##[1;37m#[0;30;47m##[1;37m#####[33m######[0;30;47m#[1;37m#######[30m#[33m######[37m#[1;37;40m
-[0;1;37;47m####[0;30;47m##[1;37m######[0;30;47m##[1;37m#[31m##[0;30;47m#[1;37m#[0;30;47m#[1;37m##[0;30;47m##[1;37m#####[0;30;47m##[1;37m##[0;30;47m###[1;37m###[0;30;47m###[1;37m####[0;30;47m##[1;37m###[0;30;47m##[1;37m####[33m#######[0;30;47m#[1;37m#####[0;30;47m#[1;33m#######[37m#[1;37;40m
-[0;1;37;47m##[0;30;47m############[1;37m##[0;30;47m###[1;37m##[0;30;47m####[1;37m###[0;30;47m####[1;37m###[0;30;47m####[1;37m#[0;30;47m###[1;37m#[0;30;47m#####[1;37m#[0;30;47m######[1;37m###[33m#####[30m#[0;30;47m#####[1m#[33m#####[37m###[1;37;40m
-
-[7CLinux Version 2.6.29, Compiled #1 SMP Mon May 4 09:51:54 EDT 2009
-[5COne 1665MHz AMD Athlon(tm) Processor, 512M RAM, 3330.53 Bogomips Total
-[37Ctobler[0m
-
=================================================
./valgrind-new/exp-bbv/tests/x86/complex_rep.stderr.diff
=================================================
--- complex_rep.stderr.exp 2011-06-16 21:32:46.563596018 -0500
+++ complex_rep.stderr.out 2011-06-16 21:43:03.859175155 -0500
@@ -1,6 +0,0 @@
-# Thread 1
-# Total intervals: 0 (Interval Size 100000)
-# Total instructions: 8206
-# Total reps: 2100228
-# Unique reps: 2052
-# Total fldcw instructions: 0
=================================================
./valgrind-new/exp-bbv/tests/x86/fldcw_check.stderr.diff
=================================================
--- fldcw_check.stderr.exp 2011-06-16 21:32:46.563596018 -0500
+++ fldcw_check.stderr.out 2011-06-16 21:43:03.882173760 -0500
@@ -1,6 +0,0 @@
-# Thread 1
-# Total intervals: 0 (Interval Size 10000)
-# Total instructions: 9261
-# Total reps: 0
-# Unique reps: 0
-# Total fldcw instructions: 2061
=================================================
./valgrind-new/exp-bbv/tests/x86/million.stderr.diff
=================================================
--- million.stderr.exp 2011-06-16 21:32:46.562596078 -0500
+++ million.stderr.out 2011-06-16 21:43:03.906172304 -0500
@@ -1,6 +0,0 @@
-# Thread 1
-# Total intervals: 10 (Interval Size 100000)
-# Total instructions: 1000000
-# Total reps: 0
-# Unique reps: 0
-# Total fldcw instructions: 0
=================================================
./valgrind-new/exp-bbv/tests/x86/rep_prefix.stderr.diff
=================================================
--- rep_prefix.stderr.exp 2011-06-16 21:32:46.562596078 -0500
+++ rep_prefix.stderr.out 2011-06-16 21:43:03.930170851 -0500
@@ -1,6 +0,0 @@
-# Thread 1
-# Total intervals: 0 (Interval Size 100000)
-# Total instructions: 124
-# Total reps: 229402
-# Unique reps: 26
-# Total fldcw instructions: 0
=================================================
./valgrind-new/exp-sgcheck/tests/bad_percentify.stderr.diff-glibc28-amd64
=================================================
--- bad_percentify.stderr.exp-glibc28-amd64 2011-06-16 21:33:05.248464067 -0500
+++ bad_percentify.stderr.out 2011-06-16 21:42:55.025710980 -0500
@@ -16,7 +16,7 @@
by 0x........: myvprintf_str (bad_percentify.c:187)
by 0x........: VG_debugLog_vprintf (bad_percentify.c:479)
by 0x........: vprintf_to_buf (bad_percentify.c:89)
- by 0x........: vprintf_WRK (bad_percentify.c:102)
+ by 0x........: vprintf_WRK (bad_percentify.c:101)
by 0x........: VG_vprintf (bad_percentify.c:115)
by 0x........: VG_printf (bad_percentify.c:124)
by 0x........: VG_print_translation_stats (bad_percentify.c:622)
=================================================
./valgrind-new/gdbserver_tests/mssnapshot.stderrB.diff
=================================================
--- mssnapshot.stderrB.exp 2011-06-16 21:32:47.231555554 -0500
+++ mssnapshot.stderrB.out 2011-06-16 21:36:52.539690642 -0500
@@ -1,5 +1,11 @@
relaying data between gdb and process ....
+Missing separate debuginfo for /lib64/ld-linux-x86-64.so.2
+Try: zypper install -C "debuginfo(build-id)=b1d398a5cb1609e7ac1c51a26588e87fc20f753c"
vgdb-error value changed from 0 to 999999
+Missing separate debuginfo for /lib64/libpthread.so.0
+Try: zypper install -C "debuginfo(build-id)=e23cbc772e670af00bea9874f925e2e61afda713"
+Missing separate debuginfo for /lib64/libc.so.6
+Try: zypper install -C "debuginfo(build-id)=1493bf69b1d671cbad9be1d1b0284fbd9138444b"
general valgrind monitor commands:
help [debug] : monitor command help. With debug: + debugging commands
vg.wait [<ms>] : sleep <ms> (default 0) then continue
=================================================
./valgrind-new/helgrind/tests/tc06_two_races_xml.stderr.diff
=================================================
--- tc06_two_races_xml.stderr.exp 2011-06-16 21:32:43.557778110 -0500
+++ tc06_two_races_xml.stderr.out 2011-06-16 21:40:24.175859868 -0500
@@ -44,7 +44,7 @@
<frame>
<ip>0x........</ip>
<obj>...</obj>
- <fn>do_clone</fn>
+ <fn>do_clone.clone.0</fn>
</frame>
<frame>
<ip>0x........</ip>
@@ -122,11 +122,6 @@
<obj>...</obj>
<fn>start_thread</fn>
</frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>clone</fn>
- </frame>
</stack>
<auxwhat>Location 0x........ is 0 bytes inside global var "unprot1"</auxwhat>
<xauxwhat><text>declared at tc06_two_races.c:9</text> <file>tc06_two_races.c</file> <line>...</line> </xauxwhat>
@@ -176,11 +171,6 @@
<obj>...</obj>
<fn>start_thread</fn>
</frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>clone</fn>
- </frame>
</stack>
<auxwhat>Location 0x........ is 0 bytes inside global var "unprot1"</auxwhat>
<xauxwhat><text>declared at tc06_two_races.c:9</text> <file>tc06_two_races.c</file> <line>...</line> </xauxwhat>
@@ -230,11 +220,6 @@
<obj>...</obj>
<fn>start_thread</fn>
</frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>clone</fn>
- </frame>
</stack>
<auxwhat>Location 0x........ is 0 bytes inside global var "unprot2"</auxwhat>
<xauxwhat><text>declared at tc06_two_races.c:9</text> <file>tc06_two_races.c</file> <line>...</line> </xauxwhat>
@@ -284,11 +269,6 @@
<obj>...</obj>
<fn>start_thread</fn>
</frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>clone</fn>
- </frame>
</stack>
<auxwhat>Location 0x........ is 0 bytes inside global var "unprot2"</auxwhat>
<xauxwhat><text>declared at tc06_two_races.c:9</text> <file>tc06_two_races.c</file> <line>...</line> </xauxwhat>
=================================================
./valgrind-new/memcheck/tests/linux/stack_switch.stderr.diff
=================================================
--- stack_switch.stderr.exp 2011-06-16 21:32:51.771280535 -0500
+++ stack_switch.stderr.out 2011-06-16 21:37:32.247283739 -0500
@@ -0,0 +1,3 @@
+Syscall param clone(child_tidptr) contains uninitialised byte(s)
+ ...
+
=================================================
./valgrind-new/memcheck/tests/origin5-bz2.stderr.diff-glibc212-s390x
=================================================
--- origin5-bz2.stderr.exp-glibc212-s390x 2011-06-16 21:32:52.676225710 -0500
+++ origin5-bz2.stderr.out 2011-06-16 21:37:52.492056513 -0500
@@ -72,17 +72,6 @@
at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
- at 0x........: mainSort (origin5-bz2.c:2859)
- by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
- by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
- by 0x........: handle_compress (origin5-bz2.c:4753)
- by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
- by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
- by 0x........: main (origin5-bz2.c:6484)
- Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6479)
-
-Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2963)
by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
@@ -128,6 +117,12 @@
Conditional jump or move depends on uninitialised value(s)
at 0x........: main (origin5-bz2.c:6512)
- Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6479)
+ Uninitialised value was created by a heap allocation
+ at 0x........: malloc (vg_replace_malloc.c:...)
+ by 0x........: g_serviceFn (origin5-bz2.c:6429)
+ by 0x........: default_bzalloc (origin5-bz2.c:4470)
+ by 0x........: BZ2_decompress (origin5-bz2.c:1578)
+ by 0x........: BZ2_bzDecompress (origin5-bz2.c:5192)
+ by 0x........: BZ2_bzBuffToBuffDecompress (origin5-bz2.c:5678)
+ by 0x........: main (origin5-bz2.c:6498)
=================================================
./valgrind-new/memcheck/tests/origin5-bz2.stderr.diff-glibc25-amd64
=================================================
--- origin5-bz2.stderr.exp-glibc25-amd64 2011-06-16 21:32:52.631228436 -0500
+++ origin5-bz2.stderr.out 2011-06-16 21:37:52.492056513 -0500
@@ -117,6 +117,12 @@
Conditional jump or move depends on uninitialised value(s)
at 0x........: main (origin5-bz2.c:6512)
- Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6479)
+ Uninitialised value was created by a heap allocation
+ at 0x........: malloc (vg_replace_malloc.c:...)
+ by 0x........: g_serviceFn (origin5-bz2.c:6429)
+ by 0x........: default_bzalloc (origin5-bz2.c:4470)
+ by 0x........: BZ2_decompress (origin5-bz2.c:1578)
+ by 0x........: BZ2_bzDecompress (origin5-bz2.c:5192)
+ by 0x........: BZ2_bzBuffToBuffDecompress (origin5-bz2.c:5678)
+ by 0x........: main (origin5-bz2.c:6498)
=================================================
./valgrind-new/memcheck/tests/origin5-bz2.stderr.diff-glibc25-x86
=================================================
--- origin5-bz2.stderr.exp-glibc25-x86 2011-06-16 21:32:52.688224982 -0500
+++ origin5-bz2.stderr.out 2011-06-16 21:37:52.492056513 -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 4
+Use of uninitialised value of size 8
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 4
+Use of uninitialised value of size 8
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,8 +27,9 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2820)
+Use of uninitialised value of size 8
+ at 0x........: mainSort (origin5-bz2.c:2820)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
by 0x........: handle_compress (origin5-bz2.c:4753)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
@@ -37,8 +38,9 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2823)
+Use of uninitialised value of size 8
+ at 0x........: mainSort (origin5-bz2.c:2823)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
by 0x........: handle_compress (origin5-bz2.c:4753)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
@@ -47,8 +49,9 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2855)
+Use of uninitialised value of size 8
+ at 0x........: mainSort (origin5-bz2.c:2854)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
by 0x........: handle_compress (origin5-bz2.c:4753)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
@@ -57,8 +60,9 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2859)
+Use of uninitialised value of size 8
+ at 0x........: mainSort (origin5-bz2.c:2858)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
by 0x........: handle_compress (origin5-bz2.c:4753)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
@@ -67,8 +71,9 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2963)
+Use of uninitialised value of size 8
+ at 0x........: mainSort (origin5-bz2.c:2963)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
by 0x........: handle_compress (origin5-bz2.c:4753)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
@@ -77,8 +82,9 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 4
- at 0x........: BZ2_blockSort (origin5-bz2.c:2964)
+Use of uninitialised value of size 8
+ at 0x........: mainSort (origin5-bz2.c:2964)
+ by 0x........: BZ2_blockSort (origin5-bz2.c:3105)
by 0x........: BZ2_compressBlock (origin5-bz2.c:4034)
by 0x........: handle_compress (origin5-bz2.c:4753)
by 0x........: BZ2_bzCompress (origin5-bz2.c:4822)
@@ -87,7 +93,7 @@
Uninitialised value was created by a client request
at 0x........: main (origin5-bz2.c:6479)
-Use of uninitialised value of size 4
+Use of uninitialised value of size 8
at 0x........: fallbackSort (origin5-bz2.c:2269)
by 0x........: BZ2_blockSort (origin5-bz2.c:3116)
<truncated beyond 100 lines>
=================================================
./valgrind-new/memcheck/tests/origin5-bz2.stderr.diff-glibc27-ppc64
=================================================
--- origin5-bz2.stderr.exp-glibc27-ppc64 2011-06-16 21:32:52.628228618 -0500
+++ origin5-bz2.stderr.out 2011-06-16 21:37:52.492056513 -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,7 +9,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
at 0x........: handle_compress (origin5-bz2.c:4686)
@@ -17,7 +17,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
at 0x........: handle_compress (origin5-bz2.c:4686)
@@ -25,7 +25,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2820)
@@ -36,7 +36,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2823)
@@ -47,7 +47,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2854)
@@ -58,7 +58,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2858)
@@ -69,7 +69,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2963)
@@ -80,7 +80,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
at 0x........: mainSort (origin5-bz2.c:2964)
@@ -91,7 +91,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
at 0x........: fallbackSort (origin5-bz2.c:2269)
@@ -102,7 +102,7 @@
by 0x........: BZ2_bzBuffToBuffCompress (origin5-bz2.c:5630)
by 0x........: main (origin5-bz2.c:6484)
Uninitialised value was created by a client request
- at 0x........: main (origin5-bz2.c:6481)
+ at 0x........: main (origin5-bz2.c:6479)
Use of uninitialised value of size 8
<truncated beyond 100 lines>
=================================================
./valgrind-new/memcheck/tests/x86-linux/bug133694.stderr.diff
=================================================
--- bug133694.stderr.exp 2011-06-16 21:32:48.174498428 -0500
+++ bug133694.stderr.out 2011-06-16 21:38:30.952724902 -0500
@@ -0,0 +1 @@
+valgrind: ./bug133694: No such file or directory
=================================================
./valgrind-new/memcheck/tests/x86-linux/bug133694.stdout.diff
=================================================
--- bug133694.stdout.exp 2011-06-16 21:32:48.168498792 -0500
+++ bug133694.stdout.out 2011-06-16 21:38:30.930726235 -0500
@@ -1 +0,0 @@
-success
=================================================
./valgrind-new/memcheck/tests/x86-linux/int3-x86.stderr.diff
=================================================
--- int3-x86.stderr.exp 2011-06-16 21:32:48.171498610 -0500
+++ int3-x86.stderr.out 2011-06-16 21:38:30.976723446 -0500
@@ -0,0 +1 @@
+valgrind: ./int3-x86: No such file or directory
=================================================
./valgrind-new/memcheck/tests/x86-linux/int3-x86.stdout.diff
=================================================
--- int3-x86.stdout.exp 2011-06-16 21:32:48.175498368 -0500
+++ int3-x86.stdout.out 2011-06-16 21:38:30.958724538 -0500
@@ -1,3 +0,0 @@
-main
-in int_handler, EIP is ...
-PASS
=================================================
./valgrind-new/memcheck/tests/x86-linux/scalar.stderr.diff
=================================================
--- scalar.stderr.exp 2011-06-16 21:32:48.173498488 -0500
+++ scalar.stderr.out 2011-06-16 21:38:31.004721749 -0500
@@ -1,3275 +1 @@
------------------------------------------------------
- 0:__NR_restart_syscall n/a
------------------------------------------------------
------------------------------------------------------
- 1: __NR_exit below
------------------------------------------------------
------------------------------------------------------
- 2: __NR_fork other
------------------------------------------------------
------------------------------------------------------
- 3: __NR_read 1+3s 1m
------------------------------------------------------
-Syscall param (syscallno) contains uninitialised byte(s)
- ...
-
-Syscall param read(fd) contains uninitialised byte(s)
- ...
-
-Syscall param read(buf) contains uninitialised byte(s)
- ...
-
-Syscall param read(count) contains uninitialised byte(s)
- ...
-
-Syscall param read(buf) points to unaddressable byte(s)
- ...
- Address 0x........ is not stack'd, malloc'd or (recently) free'd
-
------------------------------------------------------
- 4: __NR_write 3s 1m
------------------------------------------------------
-Syscall param write(fd) contains uninitialised byte(s)
- ...
-
-Syscall param write(buf) contains uninitialised byte(s)
- ...
-
-Syscall param write(count) contains uninitialised byte(s)
- ...
-
-Syscall param write(buf) points to unaddressable byte(s)
- ...
- Address 0x........ is not stack'd, malloc'd or (recently) free'd
-
------------------------------------------------------
- 5: __NR_open (2-args) 2s 1m
------------------------------------------------------
-Syscall param open(filename) contains uninitialised byte(s)
- ...
-
-Syscall param open(flags) contains uninitialised byte(s)
- ...
-
-Syscall param open(filename) points to unaddressable byte(s)
- ...
- Address 0x........ is not stack'd, malloc'd or (recently) free'd
-
------------------------------------------------------
- 5: __NR_open (3-args) 1s 0m
------------------------------------------------------
-Syscall param open(mode) contains uninitialised byte(s)
- ...
-
------------------------------------------------------
- 6: __NR_close 1s 0m
------------------------------------------------------
-Syscall param close(fd) contains uninitialised byte(s)
- ...
-
------------------------------------------------------
- 7: __NR_waitpid 3s 1m
------------------------------------------------------
-Syscall param waitpid(pid) contains uninitialised byte(s)
- ...
-
-Syscall param waitpid(status) contains uninitialised byte(s)
- ...
-
-Syscall param waitpid(options) contains uninitialised byte(s)
- ...
-
-Syscall param waitpid(status) points to unaddressable byte(s)
- ...
- Address 0x........ is not stack'd, malloc'd or (recently) free'd
-
------------------------------------------------------
- 8: __NR_creat 2s 1m
------------------------------------------------------
-Syscall param creat(pathname) contains uninitialised byte(s)
- ...
-
-Syscall param creat(mode) contains uninitialised byte(s)
- ...
-
-Syscall param creat(pathname) points to unaddressable byte(s)
- ...
- Address 0x........ is not stack'd, malloc'd or (recently) free'd
<truncated beyond 100 lines>
=================================================
./valgrind-new/memcheck/tests/x86-linux/scalar_exit_group.stderr.diff
=================================================
--- scalar_exit_group.stderr.exp 2011-06-16 21:32:48.174498428 -0500
+++ scalar_exit_group.stderr.out 2011-06-16 21:38:31.033719992 -0500
@@ -1,6 +1 @@
------------------------------------------------------
-252: __NR_exit_group 1s 0m
------------------------------------------------------
-Syscall param exit_group(status) contains uninitialised byte(s)
- ...
-
+valgrind: ./scalar_exit_group: No such file or directory
=================================================
./valgrind-new/memcheck/tests/x86-linux/scalar_fork.stderr.diff
=================================================
--- scalar_fork.stderr.exp 2011-06-16 21:32:48.169498732 -0500
+++ scalar_fork.stderr.out 2011-06-16 21:38:31.059718414 -0500
@@ -1,3 +1 @@
------------------------------------------------------
- 2: __NR_fork 0e
------------------------------------------------------
+valgrind: ./scalar_fork: No such file or directory
=================================================
./valgrind-new/memcheck/tests/x86-linux/scalar_supp.stderr.diff
=================================================
--- scalar_supp.stderr.exp 2011-06-16 21:32:48.174498428 -0500
+++ scalar_supp.stderr.out 2011-06-16 21:38:31.089716596 -0500
@@ -1,9 +1 @@
-Syscall param (syscallno) contains uninitialised byte(s)
- ...
-
-Syscall param write(fd) contains uninitialised byte(s)
- ...
-
-Syscall param write(count) contains uninitialised byte(s)
- ...
-
+valgrind: ./scalar_supp: No such file or directory
=================================================
./valgrind-new/memcheck/tests/x86-linux/scalar_vfork.stderr.diff
=================================================
--- scalar_vfork.stderr.exp 2011-06-16 21:32:48.175498368 -0500
+++ scalar_vfork.stderr.out 2011-06-16 21:38:31.114715081 -0500
@@ -1,3 +1 @@
------------------------------------------------------
-190: __NR_vfork 0e
------------------------------------------------------
+valgrind: ./scalar_vfork: No such file or directory
=================================================
./valgrind-new/memcheck/tests/x86/bug152022.stderr.diff
=================================================
--- bug152022.stderr.exp 2011-06-16 21:32:52.507235948 -0500
+++ bug152022.stderr.out 2011-06-16 21:38:30.441755879 -0500
@@ -0,0 +1 @@
+valgrind: ./bug152022: No such file or directory
=================================================
./valgrind-new/memcheck/tests/x86/espindola2.stderr.diff
=================================================
--- espindola2.stderr.exp 2011-06-16 21:32:52.513235585 -0500
+++ espindola2.stderr.out 2011-06-16 21:38:30.467754303 -0500
@@ -0,0 +1 @@
+valgrind: ./espindola2: No such file or directory
=================================================
./valgrind-new/memcheck/tests/x86/fpeflags.stderr.diff
=================================================
--- fpeflags.stderr.exp 2011-06-16 21:32:52.515235463 -0500
+++ fpeflags.stderr.out 2011-06-16 21:38:30.492752787 -0500
@@ -0,0 +1 @@
+valgrind: ./fpeflags: No such file or directory
=================================================
./valgrind-new/memcheck/tests/x86/fprem.stderr.diff
=================================================
--- fprem.stderr.exp 2011-06-16 21:32:52.508235887 -0500
+++ fprem.stderr.out 2011-06-16 21:38:30.517751273 -0500
@@ -0,0 +1 @@
+valgrind: ./fprem: No such file or directory
=================================================
./valgrind-new/memcheck/tests/x86/fprem.stdout.diff
=================================================
--- fprem.stdout.exp 2011-06-16 21:32:52.507235948 -0500
+++ fprem.stdout.out 2011-06-16 21:38:30.498752424 -0500
@@ -1,3 +0,0 @@
-fprem 0.693147
-fprem1 0.693147
-fsincos 0.130278
=================================================
./valgrind-new/memcheck/tests/x86/fxsave.stderr.diff
=================================================
--- fxsave.stderr.exp 2011-06-16 21:32:52.516235402 -0500
+++ fxsave.stderr.out 2011-06-16 21:38:30.543749696 -0500
@@ -0,0 +1 @@
+valgrind: ./fxsave: No such file or directory
=================================================
./valgrind-new/memcheck/tests/x86/fxsave.stdout.diff
=================================================
--- fxsave.stdout.exp 2011-06-16 21:32:52.514235524 -0500
+++ fxsave.stdout.out 2011-06-16 21:38:30.524750848 -0500
@@ -1,104 +0,0 @@
-Re-run with any arg to suppress least-significant
- 16 bits of FP numbers
-
-BEFORE
- 0 7f 03 00 10 fc 00 00 00 00 00 00 00 00 00 00 00
- 16 00 00 00 00 00 00 00 00 80 1f 00 00 ff ff ff ff
- 32 xx xx 00 00 00 00 00 80 ff 3f 00 00 00 00 00 00
- 48 xx xx 68 21 a2 da 0f c9 00 40 00 00 00 00 00 00
- 64 xx xx cf fb 84 9a 20 9a fd 3f 00 00 00 00 00 00
- 80 xx xx cf d1 f7 17 72 b1 fe 3f 00 00 00 00 00 00
- 96 xx xx 00 00 00 00 00 80 ff 3f 00 00 00 00 00 00
-112 xx xx 68 21 a2 da 0f c9 00 40 00 00 00 00 00 00
-128 xx xx 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-144 xx xx 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-160 78 56 34 12 44 33 22 11 88 77 66 55 21 43 65 87
-176 01 ef cd ab dd cc bb aa 11 00 ff ee ba dc fe 10
-192 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-208 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-224 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-256 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-272 79 b9 f9 b9 99 ff 99 bb 99 77 99 bb 9b 9f 9b 97
-288 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-304 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-320 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-336 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-352 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-368 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-384 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-400 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-416 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-432 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-448 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-464 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-480 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-496 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-
-ZEROED
- 0 7f 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00
- 16 00 00 00 00 00 00 00 00 80 1f 00 00 ff ff ff ff
- 32 xx xx 00 00 00 00 00 00 00 00 00 00 00 00 00 00
- 48 xx xx 00 00 00 00 00 00 00 00 00 00 00 00 00 00
- 64 xx xx 00 00 00 00 00 00 00 00 00 00 00 00 00 00
- 80 xx xx 00 00 00 00 00 00 00 00 00 00 00 00 00 00
- 96 xx xx 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-112 xx xx 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-128 xx xx 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-144 xx xx 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-176 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-192 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-208 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-224 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-256 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-272 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-288 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-304 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-320 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-336 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-352 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-368 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-384 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-400 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-416 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-432 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-448 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-464 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-480 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-496 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-
-RESTORED
- 0 7f 03 00 10 fc 00 00 00 00 00 00 00 00 00 00 00
- 16 00 00 00 00 00 00 00 00 80 1f 00 00 ff ff ff ff
- 32 xx xx 00 00 00 00 00 80 ff 3f 00 00 00 00 00 00
- 48 xx xx 68 21 a2 da 0f c9 00 40 00 00 00 00 00 00
- 64 xx xx cf fb 84 9a 20 9a fd 3f 00 00 00 00 00 00
- 80 xx xx cf d1 f7 17 72 b1 fe 3f 00 00 00 00 00 00
- 96 xx xx 00 00 00 00 00 80 ff 3f 00 00 00 00 00 00
-112 xx xx 68 21 a2 da 0f c9 00 40 00 00 00 00 00 00
-128 xx xx 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-144 xx xx 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-160 78 56 34 12 44 33 22 11 88 77 66 55 21 43 65 87
-176 01 ef cd ab dd cc bb aa 11 00 ff ee ba dc fe 10
-192 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-208 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-224 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-256 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-272 79 b9 f9 b9 99 ff 99 bb 99 77 99 bb 9b 9f 9b 97
-288 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-304 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-320 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-336 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-352 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-368 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
-384 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
<truncated beyond 100 lines>
=================================================
./valgrind-new/memcheck/tests/x86/insn_basic.stderr.diff
=================================================
--- insn_basic.stderr.exp 2011-06-16 21:33:04.758493743 -0500
+++ insn_basic.stderr.out 2011-06-16 21:38:30.569748120 -0500
@@ -0,0 +1 @@
+valgrind: ./../../../none/tests/x86/insn_basic: No such file or directory
=================================================
./valgrind-new/memcheck/tests/x86/insn_basic.stdout.diff
=================================================
--- insn_basic.stdout.exp 2011-06-16 21:33:04.772492894 -0500
+++ insn_basic.stdout.out 2011-06-16 21:38:30.549749332 -0500
@@ -1,1056 +0,0 @@
-adcb_1 ... ok
-adcb_2 ... ok
-adcb_3 ... ok
-adcb_4 ... ok
-adcb_5 ... ok
-adcb_6 ... ok
-adcb_7 ... ok
-adcb_8 ... ok
-adcb_9 ... ok
-adcb_10 ... ok
-adcb_11 ... ok
-adcb_12 ... ok
-adcw_1 ... ok
-adcw_2 ... ok
-adcw_3 ... ok
-adcw_4 ... ok
-adcw_5 ... ok
-adcw_6 ... ok
-adcw_7 ... ok
-adcw_8 ... ok
-adcw_9 ... ok
-adcw_10 ... ok
-adcw_11 ... ok
-adcw_12 ... ok
-adcw_13 ... ok
-adcw_14 ... ok
-adcl_1 ... ok
-adcl_2 ... ok
-adcl_3 ... ok
-adcl_4 ... ok
-adcl_5 ... ok
-adcl_6 ... ok
-adcl_7 ... ok
-adcl_8 ... ok
-adcl_9 ... ok
-adcl_10 ... ok
-adcl_11 ... ok
-adcl_12 ... ok
-adcl_13 ... ok
-adcl_14 ... ok
-addb_1 ... ok
-addb_2 ... ok
-addb_3 ... ok
-addb_4 ... ok
-addb_5 ... ok
-addb_6 ... ok
-addw_1 ... ok
-addw_2 ... ok
-addw_3 ... ok
-addw_4 ... ok
-addw_5 ... ok
-addw_6 ... ok
-addw_7 ... ok
-addl_1 ... ok
-addl_2 ... ok
-addl_3 ... ok
-addl_4 ... ok
-addl_5 ... ok
-addl_6 ... ok
-addl_7 ... ok
-andb_1 ... ok
-andb_2 ... ok
-andb_3 ... ok
-andb_4 ... ok
-andb_5 ... ok
-andb_6 ... ok
-andw_1 ... ok
-andw_2 ... ok
-andw_3 ... ok
-andw_4 ... ok
-andw_5 ... ok
-andw_6 ... ok
-andw_7 ... ok
-andl_1 ... ok
-andl_2 ... ok
-andl_3 ... ok
-andl_4 ... ok
-andl_5 ... ok
-andl_6 ... ok
-andl_7 ... ok
-bsfw_1 ... ok
-bsfw_2 ... ok
-bsfl_1 ... ok
-bsfl_2 ... ok
-bsrw_1 ... ok
-bsrw_2 ... ok
-bsrl_1 ... ok
-bsrl_2 ... ok
-bswapl_1 ... ok
-btw_1 ... ok
-btw_2 ... ok
-btw_3 ... ok
-btw_4 ... ok
-btw_5 ... ok
-btw_6 ... ok
-btw_7 ... ok
-btw_8 ... ok
<truncated beyond 100 lines>
=================================================
./valgrind-new/memcheck/tests/x86/insn_cmov.stderr.diff
=================================================
--- insn_cmov.stderr.exp 2011-06-16 21:33:04.757493804 -0500
+++ insn_cmov.stderr.out 2011-06-16 21:38:30.595746543 -0500
@@ -0,0 +1 @@
+valgrind: ./../../../none/tests/x86/insn_cmov: No such file or directory
=================================================
./valgrind-new/memcheck/tests/x86/insn_cmov.stdout.diff
=================================================
--- insn_cmov.stdout.exp 2011-06-16 21:33:04.770493016 -0500
+++ insn_cmov.stdout.out 2011-06-16 21:38:30.575747755 -0500
@@ -1,384 +0,0 @@
-cmova_1 ... ok
-cmova_2 ... ok
-cmova_3 ... ok
-cmova_4 ... ok
-cmova_5 ... ok
-cmova_6 ... ok
-cmova_7 ... ok
-cmova_8 ... ok
-cmovae_1 ... ok
-cmovae_2 ... ok
-cmovae_3 ... ok
-cmovae_4 ... ok
-cmovb_1 ... ok
-cmovb_2 ... ok
-cmovb_3 ... ok
-cmovb_4 ... ok
-cmovbe_1 ... ok
-cmovbe_2 ... ok
-cmovbe_3 ... ok
-cmovbe_4 ... ok
-cmovbe_5 ... ok
-cmovbe_6 ... ok
-cmovbe_7 ... ok
-cmovbe_8 ... ok
-cmovc_1 ... ok
-cmovc_2 ... ok
-cmovc_3 ... ok
-cmovc_4 ... ok
-cmove_1 ... ok
-cmove_2 ... ok
-cmove_3 ... ok
-cmove_4 ... ok
-cmovg_1 ... ok
-cmovg_2 ... ok
-cmovg_3 ... ok
-cmovg_4 ... ok
-cmovg_5 ... ok
-cmovg_6 ... ok
-cmovg_7 ... ok
-cmovg_8 ... ok
-cmovg_9 ... ok
-cmovg_10 ... ok
-cmovg_11 ... ok
-cmovg_12 ... ok
-cmovg_13 ... ok
-cmovg_14 ... ok
-cmovg_15 ... ok
-cmovg_16 ... ok
-cmovge_1 ... ok
-cmovge_2 ... ok
-cmovge_3 ... ok
-cmovge_4 ... ok
-cmovge_5 ... ok
-cmovge_6 ... ok
-cmovge_7 ... ok
-cmovge_8 ... ok
-cmovl_1 ... ok
-cmovl_2 ... ok
-cmovl_3 ... ok
-cmovl_4 ... ok
-cmovl_5 ... ok
-cmovl_6 ... ok
-cmovl_7 ... ok
-cmovl_8 ... ok
-cmovle_1 ... ok
-cmovle_2 ... ok
-cmovle_3 ... ok
-cmovle_4 ... ok
-cmovle_5 ... ok
-cmovle_6 ... ok
-cmovle_7 ... ok
-cmovle_8 ... ok
-cmovle_9 ... ok
-cmovle_10 ... ok
-cmovle_11 ... ok
-cmovle_12 ... ok
-cmovle_13 ... ok
-cmovle_14 ... ok
-cmovle_15 ... ok
-cmovle_16 ... ok
-cmovna_1 ... ok
-cmovna_2 ... ok
-cmovna_3 ... ok
-cmovna_4 ... ok
-cmovna_5 ....
[truncated message content] |
|
From: Tom H. <th...@cy...> - 2011-06-17 02:33:50
|
Nightly build on bristol ( x86_64, Fedora 13 )
Started at 2011-06-17 03:20:58 BST
Ended at 2011-06-17 03:33:35 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
== 561 tests, 20 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
memcheck/tests/linux/stack_switch (stderr)
cachegrind/tests/chdir (stderr)
cachegrind/tests/clreq (stderr)
cachegrind/tests/dlclose (stderr)
cachegrind/tests/notpower2 (stderr)
cachegrind/tests/wrap5 (stderr)
cachegrind/tests/x86/fpu-28-108 (stderr)
callgrind/tests/notpower2-hwpref (stderr)
callgrind/tests/notpower2-use (stderr)
callgrind/tests/notpower2-wb (stderr)
callgrind/tests/notpower2 (stderr)
callgrind/tests/simwork-both (stderr)
callgrind/tests/simwork-cache (stderr)
callgrind/tests/simwork1 (stderr)
callgrind/tests/simwork2 (stderr)
callgrind/tests/simwork3 (stderr)
callgrind/tests/threads-use (stderr)
helgrind/tests/pth_barrier3 (stderr)
helgrind/tests/tc06_two_races_xml (stderr)
drd/tests/pth_barrier3 (stderr)
=================================================
== Results from 24 hours ago ==
=================================================
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... failed
Last 20 lines of verbose log follow echo
mc_translate.c:3418: error: 'Iop_QShortenU16Ux8' undeclared (first use in this function)
mc_translate.c:3419: error: 'Iop_QShortenS32Sx4' undeclared (first use in this function)
mc_translate.c:3420: error: 'Iop_QShortenU32Sx4' undeclared (first use in this function)
mc_translate.c:3421: error: 'Iop_QShortenU32Ux4' undeclared (first use in this function)
mc_translate.c:3422: error: 'Iop_QShortenS64Sx2' undeclared (first use in this function)
mc_translate.c:3423: error: 'Iop_QShortenU64Sx2' undeclared (first use in this function)
mc_translate.c:3424: error: 'Iop_QShortenU64Ux2' undeclared (first use in this function)
mc_translate.c:3427: error: 'Iop_Longen8Sx8' undeclared (first use in this function)
mc_translate.c:3428: error: 'Iop_Longen8Ux8' undeclared (first use in this function)
mc_translate.c:3429: error: 'Iop_Longen16Sx4' undeclared (first use in this function)
mc_translate.c:3430: error: 'Iop_Longen16Ux4' undeclared (first use in this function)
mc_translate.c:3431: error: 'Iop_Longen32Sx2' undeclared (first use in this function)
mc_translate.c:3432: error: 'Iop_Longen32Ux2' undeclared (first use in this function)
make[3]: *** [memcheck_amd64_linux-mc_translate.o] Error 1
make[3]: Leaving directory `/tmp/vgtest-17573/2011-06-17/valgrind-old/memcheck'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/tmp/vgtest-17573/2011-06-17/valgrind-old/memcheck'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/vgtest-17573/2011-06-17/valgrind-old'
make: *** [all] Error 2
=================================================
== Difference between 24 hours ago and now ==
=================================================
*** old.short Fri Jun 17 03:23:17 2011
--- new.short Fri Jun 17 03:33:35 2011
***************
*** 3,26 ****
Configuring valgrind ... done
! Building valgrind ... failed
- Last 20 lines of verbose log follow echo
- mc_translate.c:3418: error: 'Iop_QShortenU16Ux8' undeclared (first use in this function)
- mc_translate.c:3419: error: 'Iop_QShortenS32Sx4' undeclared (first use in this function)
- mc_translate.c:3420: error: 'Iop_QShortenU32Sx4' undeclared (first use in this function)
- mc_translate.c:3421: error: 'Iop_QShortenU32Ux4' undeclared (first use in this function)
- mc_translate.c:3422: error: 'Iop_QShortenS64Sx2' undeclared (first use in this function)
- mc_translate.c:3423: error: 'Iop_QShortenU64Sx2' undeclared (first use in this function)
- mc_translate.c:3424: error: 'Iop_QShortenU64Ux2' undeclared (first use in this function)
- mc_translate.c:3427: error: 'Iop_Longen8Sx8' undeclared (first use in this function)
- mc_translate.c:3428: error: 'Iop_Longen8Ux8' undeclared (first use in this function)
- mc_translate.c:3429: error: 'Iop_Longen16Sx4' undeclared (first use in this function)
- mc_translate.c:3430: error: 'Iop_Longen16Ux4' undeclared (first use in this function)
- mc_translate.c:3431: error: 'Iop_Longen32Sx2' undeclared (first use in this function)
- mc_translate.c:3432: error: 'Iop_Longen32Ux2' undeclared (first use in this function)
- make[3]: *** [memcheck_amd64_linux-mc_translate.o] Error 1
- make[3]: Leaving directory `/tmp/vgtest-17573/2011-06-17/valgrind-old/memcheck'
- make[2]: *** [all-recursive] Error 1
- make[2]: Leaving directory `/tmp/vgtest-17573/2011-06-17/valgrind-old/memcheck'
- make[1]: *** [all-recursive] Error 1
- make[1]: Leaving directory `/tmp/vgtest-17573/2011-06-17/valgrind-old'
- make: *** [all] Error 2
--- 3,30 ----
Configuring valgrind ... done
! Building valgrind ... done
! Running regression tests ... failed
!
! Regression test results follow
!
! == 561 tests, 20 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
! memcheck/tests/linux/stack_switch (stderr)
! cachegrind/tests/chdir (stderr)
! cachegrind/tests/clreq (stderr)
! cachegrind/tests/dlclose (stderr)
! cachegrind/tests/notpower2 (stderr)
! cachegrind/tests/wrap5 (stderr)
! cachegrind/tests/x86/fpu-28-108 (stderr)
! callgrind/tests/notpower2-hwpref (stderr)
! callgrind/tests/notpower2-use (stderr)
! callgrind/tests/notpower2-wb (stderr)
! callgrind/tests/notpower2 (stderr)
! callgrind/tests/simwork-both (stderr)
! callgrind/tests/simwork-cache (stderr)
! callgrind/tests/simwork1 (stderr)
! callgrind/tests/simwork2 (stderr)
! callgrind/tests/simwork3 (stderr)
! callgrind/tests/threads-use (stderr)
! helgrind/tests/pth_barrier3 (stderr)
! helgrind/tests/tc06_two_races_xml (stderr)
! drd/tests/pth_barrier3 (stderr)
|
|
From: Tom H. <th...@cy...> - 2011-06-17 02:24:03
|
Nightly build on bristol ( x86_64, Fedora 14 )
Started at 2011-06-17 03:10:51 BST
Ended at 2011-06-17 03:23:40 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
== 571 tests, 20 stderr failures, 0 stdout failures, 5 stderrB failures, 0 stdoutB failures, 0 post failures ==
gdbserver_tests/mcbreak (stderrB)
gdbserver_tests/mcclean_after_fork (stderrB)
gdbserver_tests/mcinfcallWSRU (stderrB)
gdbserver_tests/mcvabits (stderrB)
gdbserver_tests/mssnapshot (stderrB)
memcheck/tests/linux/stack_switch (stderr)
memcheck/tests/origin5-bz2 (stderr)
cachegrind/tests/chdir (stderr)
cachegrind/tests/clreq (stderr)
cachegrind/tests/dlclose (stderr)
cachegrind/tests/notpower2 (stderr)
cachegrind/tests/wrap5 (stderr)
cachegrind/tests/x86/fpu-28-108 (stderr)
callgrind/tests/notpower2-hwpref (stderr)
callgrind/tests/notpower2-use (stderr)
callgrind/tests/notpower2-wb (stderr)
callgrind/tests/notpower2 (stderr)
callgrind/tests/simwork-both (stderr)
callgrind/tests/simwork-cache (stderr)
callgrind/tests/simwork1 (stderr)
callgrind/tests/simwork2 (stderr)
callgrind/tests/simwork3 (stderr)
callgrind/tests/threads-use (stderr)
helgrind/tests/tc06_two_races_xml (stderr)
exp-sgcheck/tests/bad_percentify (stderr)
=================================================
== Results from 24 hours ago ==
=================================================
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... failed
Last 20 lines of verbose log follow echo
mc_translate.c:3418:12: error: 'Iop_QShortenU16Ux8' undeclared (first use in this function)
mc_translate.c:3419:12: error: 'Iop_QShortenS32Sx4' undeclared (first use in this function)
mc_translate.c:3420:12: error: 'Iop_QShortenU32Sx4' undeclared (first use in this function)
mc_translate.c:3421:12: error: 'Iop_QShortenU32Ux4' undeclared (first use in this function)
mc_translate.c:3422:12: error: 'Iop_QShortenS64Sx2' undeclared (first use in this function)
mc_translate.c:3423:12: error: 'Iop_QShortenU64Sx2' undeclared (first use in this function)
mc_translate.c:3424:12: error: 'Iop_QShortenU64Ux2' undeclared (first use in this function)
mc_translate.c:3427:12: error: 'Iop_Longen8Sx8' undeclared (first use in this function)
mc_translate.c:3428:12: error: 'Iop_Longen8Ux8' undeclared (first use in this function)
mc_translate.c:3429:12: error: 'Iop_Longen16Sx4' undeclared (first use in this function)
mc_translate.c:3430:12: error: 'Iop_Longen16Ux4' undeclared (first use in this function)
mc_translate.c:3431:12: error: 'Iop_Longen32Sx2' undeclared (first use in this function)
mc_translate.c:3432:12: error: 'Iop_Longen32Ux2' undeclared (first use in this function)
make[3]: *** [memcheck_amd64_linux-mc_translate.o] Error 1
make[3]: Leaving directory `/tmp/vgtest-4169/2011-06-17/valgrind-old/memcheck'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/tmp/vgtest-4169/2011-06-17/valgrind-old/memcheck'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/vgtest-4169/2011-06-17/valgrind-old'
make: *** [all] Error 2
=================================================
== Difference between 24 hours ago and now ==
=================================================
*** old.short Fri Jun 17 03:13:04 2011
--- new.short Fri Jun 17 03:23:40 2011
***************
*** 3,26 ****
Configuring valgrind ... done
! Building valgrind ... failed
- Last 20 lines of verbose log follow echo
- mc_translate.c:3418:12: error: 'Iop_QShortenU16Ux8' undeclared (first use in this function)
- mc_translate.c:3419:12: error: 'Iop_QShortenS32Sx4' undeclared (first use in this function)
- mc_translate.c:3420:12: error: 'Iop_QShortenU32Sx4' undeclared (first use in this function)
- mc_translate.c:3421:12: error: 'Iop_QShortenU32Ux4' undeclared (first use in this function)
- mc_translate.c:3422:12: error: 'Iop_QShortenS64Sx2' undeclared (first use in this function)
- mc_translate.c:3423:12: error: 'Iop_QShortenU64Sx2' undeclared (first use in this function)
- mc_translate.c:3424:12: error: 'Iop_QShortenU64Ux2' undeclared (first use in this function)
- mc_translate.c:3427:12: error: 'Iop_Longen8Sx8' undeclared (first use in this function)
- mc_translate.c:3428:12: error: 'Iop_Longen8Ux8' undeclared (first use in this function)
- mc_translate.c:3429:12: error: 'Iop_Longen16Sx4' undeclared (first use in this function)
- mc_translate.c:3430:12: error: 'Iop_Longen16Ux4' undeclared (first use in this function)
- mc_translate.c:3431:12: error: 'Iop_Longen32Sx2' undeclared (first use in this function)
- mc_translate.c:3432:12: error: 'Iop_Longen32Ux2' undeclared (first use in this function)
- make[3]: *** [memcheck_amd64_linux-mc_translate.o] Error 1
- make[3]: Leaving directory `/tmp/vgtest-4169/2011-06-17/valgrind-old/memcheck'
- make[2]: *** [all-recursive] Error 1
- make[2]: Leaving directory `/tmp/vgtest-4169/2011-06-17/valgrind-old/memcheck'
- make[1]: *** [all-recursive] Error 1
- make[1]: Leaving directory `/tmp/vgtest-4169/2011-06-17/valgrind-old'
- make: *** [all] Error 2
--- 3,35 ----
Configuring valgrind ... done
! Building valgrind ... done
! Running regression tests ... failed
!
! Regression test results follow
!
! == 571 tests, 20 stderr failures, 0 stdout failures, 5 stderrB failures, 0 stdoutB failures, 0 post failures ==
! gdbserver_tests/mcbreak (stderrB)
! gdbserver_tests/mcclean_after_fork (stderrB)
! gdbserver_tests/mcinfcallWSRU (stderrB)
! gdbserver_tests/mcvabits (stderrB)
! gdbserver_tests/mssnapshot (stderrB)
! memcheck/tests/linux/stack_switch (stderr)
! memcheck/tests/origin5-bz2 (stderr)
! cachegrind/tests/chdir (stderr)
! cachegrind/tests/clreq (stderr)
! cachegrind/tests/dlclose (stderr)
! cachegrind/tests/notpower2 (stderr)
! cachegrind/tests/wrap5 (stderr)
! cachegrind/tests/x86/fpu-28-108 (stderr)
! callgrind/tests/notpower2-hwpref (stderr)
! callgrind/tests/notpower2-use (stderr)
! callgrind/tests/notpower2-wb (stderr)
! callgrind/tests/notpower2 (stderr)
! callgrind/tests/simwork-both (stderr)
! callgrind/tests/simwork-cache (stderr)
! callgrind/tests/simwork1 (stderr)
! callgrind/tests/simwork2 (stderr)
! callgrind/tests/simwork3 (stderr)
! callgrind/tests/threads-use (stderr)
! helgrind/tests/tc06_two_races_xml (stderr)
! exp-sgcheck/tests/bad_percentify (stderr)
|
|
From: Tom H. <th...@cy...> - 2011-06-17 02:14:54
|
Nightly build on bristol ( x86_64, Fedora 15 )
Started at 2011-06-17 03:02:07 BST
Ended at 2011-06-17 03:14:37 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
== 571 tests, 23 stderr failures, 1 stdout failure, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
memcheck/tests/origin5-bz2 (stderr)
memcheck/tests/overlap (stderr)
cachegrind/tests/chdir (stderr)
cachegrind/tests/clreq (stderr)
cachegrind/tests/dlclose (stderr)
cachegrind/tests/notpower2 (stderr)
cachegrind/tests/wrap5 (stderr)
cachegrind/tests/x86/fpu-28-108 (stderr)
callgrind/tests/notpower2-hwpref (stderr)
callgrind/tests/notpower2-use (stderr)
callgrind/tests/notpower2-wb (stderr)
callgrind/tests/notpower2 (stderr)
callgrind/tests/simwork-both (stderr)
callgrind/tests/simwork-cache (stderr)
callgrind/tests/simwork1 (stderr)
callgrind/tests/simwork2 (stderr)
callgrind/tests/simwork3 (stderr)
callgrind/tests/threads-use (stderr)
none/tests/amd64/bug127521-64 (stdout)
none/tests/amd64/bug127521-64 (stderr)
none/tests/shell (stderr)
helgrind/tests/hg05_race2 (stderr)
helgrind/tests/tc06_two_races_xml (stderr)
exp-sgcheck/tests/bad_percentify (stderr)
=================================================
== Results from 24 hours ago ==
=================================================
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... failed
Last 20 lines of verbose log follow echo
mc_translate.c:3418:12: error: 'Iop_QShortenU16Ux8' undeclared (first use in this function)
mc_translate.c:3419:12: error: 'Iop_QShortenS32Sx4' undeclared (first use in this function)
mc_translate.c:3420:12: error: 'Iop_QShortenU32Sx4' undeclared (first use in this function)
mc_translate.c:3421:12: error: 'Iop_QShortenU32Ux4' undeclared (first use in this function)
mc_translate.c:3422:12: error: 'Iop_QShortenS64Sx2' undeclared (first use in this function)
mc_translate.c:3423:12: error: 'Iop_QShortenU64Sx2' undeclared (first use in this function)
mc_translate.c:3424:12: error: 'Iop_QShortenU64Ux2' undeclared (first use in this function)
mc_translate.c:3427:12: error: 'Iop_Longen8Sx8' undeclared (first use in this function)
mc_translate.c:3428:12: error: 'Iop_Longen8Ux8' undeclared (first use in this function)
mc_translate.c:3429:12: error: 'Iop_Longen16Sx4' undeclared (first use in this function)
mc_translate.c:3430:12: error: 'Iop_Longen16Ux4' undeclared (first use in this function)
mc_translate.c:3431:12: error: 'Iop_Longen32Sx2' undeclared (first use in this function)
mc_translate.c:3432:12: error: 'Iop_Longen32Ux2' undeclared (first use in this function)
make[3]: *** [memcheck_amd64_linux-mc_translate.o] Error 1
make[3]: Leaving directory `/tmp/vgtest-32593/2011-06-17/valgrind-old/memcheck'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/tmp/vgtest-32593/2011-06-17/valgrind-old/memcheck'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/vgtest-32593/2011-06-17/valgrind-old'
make: *** [all] Error 2
=================================================
== Difference between 24 hours ago and now ==
=================================================
*** old.short Fri Jun 17 03:04:18 2011
--- new.short Fri Jun 17 03:14:37 2011
***************
*** 3,26 ****
Configuring valgrind ... done
! Building valgrind ... failed
- Last 20 lines of verbose log follow echo
- mc_translate.c:3418:12: error: 'Iop_QShortenU16Ux8' undeclared (first use in this function)
- mc_translate.c:3419:12: error: 'Iop_QShortenS32Sx4' undeclared (first use in this function)
- mc_translate.c:3420:12: error: 'Iop_QShortenU32Sx4' undeclared (first use in this function)
- mc_translate.c:3421:12: error: 'Iop_QShortenU32Ux4' undeclared (first use in this function)
- mc_translate.c:3422:12: error: 'Iop_QShortenS64Sx2' undeclared (first use in this function)
- mc_translate.c:3423:12: error: 'Iop_QShortenU64Sx2' undeclared (first use in this function)
- mc_translate.c:3424:12: error: 'Iop_QShortenU64Ux2' undeclared (first use in this function)
- mc_translate.c:3427:12: error: 'Iop_Longen8Sx8' undeclared (first use in this function)
- mc_translate.c:3428:12: error: 'Iop_Longen8Ux8' undeclared (first use in this function)
- mc_translate.c:3429:12: error: 'Iop_Longen16Sx4' undeclared (first use in this function)
- mc_translate.c:3430:12: error: 'Iop_Longen16Ux4' undeclared (first use in this function)
- mc_translate.c:3431:12: error: 'Iop_Longen32Sx2' undeclared (first use in this function)
- mc_translate.c:3432:12: error: 'Iop_Longen32Ux2' undeclared (first use in this function)
- make[3]: *** [memcheck_amd64_linux-mc_translate.o] Error 1
- make[3]: Leaving directory `/tmp/vgtest-32593/2011-06-17/valgrind-old/memcheck'
- make[2]: *** [all-recursive] Error 1
- make[2]: Leaving directory `/tmp/vgtest-32593/2011-06-17/valgrind-old/memcheck'
- make[1]: *** [all-recursive] Error 1
- make[1]: Leaving directory `/tmp/vgtest-32593/2011-06-17/valgrind-old'
- make: *** [all] Error 2
--- 3,34 ----
Configuring valgrind ... done
! Building valgrind ... done
! Running regression tests ... failed
!
! Regression test results follow
!
! == 571 tests, 23 stderr failures, 1 stdout failure, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
! memcheck/tests/origin5-bz2 (stderr)
! memcheck/tests/overlap (stderr)
! cachegrind/tests/chdir (stderr)
! cachegrind/tests/clreq (stderr)
! cachegrind/tests/dlclose (stderr)
! cachegrind/tests/notpower2 (stderr)
! cachegrind/tests/wrap5 (stderr)
! cachegrind/tests/x86/fpu-28-108 (stderr)
! callgrind/tests/notpower2-hwpref (stderr)
! callgrind/tests/notpower2-use (stderr)
! callgrind/tests/notpower2-wb (stderr)
! callgrind/tests/notpower2 (stderr)
! callgrind/tests/simwork-both (stderr)
! callgrind/tests/simwork-cache (stderr)
! callgrind/tests/simwork1 (stderr)
! callgrind/tests/simwork2 (stderr)
! callgrind/tests/simwork3 (stderr)
! callgrind/tests/threads-use (stderr)
! none/tests/amd64/bug127521-64 (stdout)
! none/tests/amd64/bug127521-64 (stderr)
! none/tests/shell (stderr)
! helgrind/tests/hg05_race2 (stderr)
! helgrind/tests/tc06_two_races_xml (stderr)
! exp-sgcheck/tests/bad_percentify (stderr)
|
|
From: wangyang <wan...@cn...> - 2011-06-17 01:23:36
|
Hi Sir: There is bionic c library ,not GNU c library in android OS, so if I want to use valgrind for middleware of android, what should I do about valgrind? I know a very little part of Valgrind uses GNU c library, which is launcher-linux.c file.but if I want that valgrind can detect errors of bionic c library ,what should I do? Thanks. |