Merge (from 3.2 branch) r6743 (Edit the manual to bring it up to date
and make some of the wording a bit more professional sounding.)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6745 a5019735-40e9-0310-863c-91ae7b9d1cf9
diff --git a/docs/xml/FAQ.xml b/docs/xml/FAQ.xml
index 720b647..9ff0626 100644
--- a/docs/xml/FAQ.xml
+++ b/docs/xml/FAQ.xml
@@ -131,9 +131,9 @@
<para>Problem is that running <literal>__libc_freeres()</literal> in
older glibc versions causes this crash.</para>
- <para>WORKAROUND FOR 1.1.X and later versions of Valgrind: use the
+ <para>Workaround for 1.1.X and later versions of Valgrind: use the
<option>--run-libc-freeres=no</option> flag. You may then get space
- leak reports for glibc-allocations (please _don't_ report these to
+ leak reports for glibc allocations (please don't report these to
the glibc people, since they are not real leaks), but at least the
program runs.</para>
</answer>
@@ -142,14 +142,14 @@
<qandaentry id="faq.bugdeath">
<question id="q-bugdeath">
<para>My (buggy) program dies like this:</para>
-<screen>% valgrind: vg_malloc2.c:442 (bszW_to_pszW): Assertion 'pszW >= 0' failed.</screen>
+<screen>valgrind: m_mallocfree.c:442 (bszW_to_pszW): Assertion 'pszW >= 0' failed.</screen>
</question>
<answer id="a-bugdeath">
<para>If Memcheck (the memory checker) shows any invalid reads,
- invalid writes and invalid frees in your program, the above may
+ invalid writes or invalid frees in your program, the above may
happen. Reason is that your program may trash Valgrind's low-level
memory manager, which then dies with the above assertion, or
- something like this. The cure is to fix your program so that it
+ something similar. The cure is to fix your program so that it
doesn't do any illegal memory accesses. The above failure will
hopefully go away after that.</para>
</answer>
@@ -159,21 +159,18 @@
<question id="q-msgdeath">
<para>My program dies, printing a message like this along the
way:</para>
-<screen>% disInstr: unhandled instruction bytes: 0x66 0xF 0x2E 0x5</screen>
+<screen>vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x2E 0x5</screen>
</question>
<answer id="a-msgdeath">
- <para>Older versions did not support some x86 instructions,
- particularly SSE/SSE2 instructions. Try a newer Valgrind; we now
- support almost all instructions. If it still happens with newer
- versions, if the failing instruction is an SSE/SSE2 instruction, you
- might be able to recompile your program without it by using the flag
- <option>-march</option> to gcc. Either way, let us know and we'll
- try to fix it.</para>
+ <para>Older versions did not support some x86 and amd64 instructions,
+ particularly SSE/SSE2/SSE3 instructions. Try a newer Valgrind; we now
+ support almost all instructions. If it still breaks, file a bug
+ report.</para>
<para>Another possibility is that your program has a bug and
erroneously jumps to a non-code address, in which case you'll get a
SIGILL signal. Memcheck may issue a warning just before
- this happens, but they might not if the jump happens to land in
+ this happens, but it might not if the jump happens to land in
addressable memory.</para>
</answer>
</qandaentry>
@@ -189,9 +186,10 @@
none of the generated code is later overwritten by other generated
code. If this happens, though, things will go wrong as Valgrind
will continue running its translations of the old code (this is true
- on x86 and AMD64, on PPC32 there are explicit cache flush
- instructions which Valgrind detects). You should try running with
- <option>--smc-check=all</option> in this case; Valgrind will run
+ on x86 and amd64, on PowerPC there are explicit cache flush
+ instructions which Valgrind detects and honours).
+ You should try running with
+ <option>--smc-check=all</option> in this case. Valgrind will run
much more slowly, but should detect the use of the out-of-date
code.</para>
@@ -243,7 +241,7 @@
<itemizedlist>
<listitem>
<para>With gcc 2.91, 2.95, 3.0 and 3.1, compile all source using
- the STL with <literal>-D__USE_MALLOC</literal>. Beware! This is
+ the STL with <literal>-D__USE_MALLOC</literal>. Beware! This was
removed from gcc starting with version 3.3.</para>
</listitem>
<listitem>
@@ -262,22 +260,14 @@
portable, but should work for gcc) or even writing your own memory
allocators. But all this goes beyond the scope of this FAQ. Start
by reading
- <ulink url="http://gcc.gnu.org/onlinedocs/libstdc++/ext/howto.html#3">
- http://gcc.gnu.org/onlinedocs/libstdc++/ext/howto.html#3</ulink> if
- you absolutely want to do that. But beware:</para>
-
- <orderedlist>
- <listitem>
- <para>there are currently changes underway for gcc which are not
- totally reflected in the docs right now ("now" == 26 Apr 03)</para>
- </listitem>
- <listitem>
- <para>allocators belong to the more messy parts of the STL and
- people went to great lengths to make it portable across
- platforms. Chances are good that your solution will work on your
- platform, but not on others.</para>
- </listitem>
- </orderedlist>
+ <ulink
+ url="http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#4_4_leak">
+ http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#4_4_leak</ulink> if
+ you absolutely want to do that. But beware:
+ allocators belong to the more messy parts of the STL and
+ people went to great lengths to make the STL portable across
+ platforms. Chances are good that your solution will work on your
+ platform, but not on others.</para>
</answer>
</qandaentry>
@@ -407,7 +397,7 @@
<para>If you are tracing large trees of processes, it can be less
disruptive to have the output sent over the network. Give Valgrind
the flag <option>--log-socket=127.0.0.1:12345</option> (if you want
- logging output sent to <literal>port 12345</literal> on
+ logging output sent to port <literal>12345</literal> on
<literal>localhost</literal>). You can use the valgrind-listener
program to listen on that port:</para>
<programlisting>
@@ -476,7 +466,7 @@
<para>If you really want to write suppressions by hand, read the
manual carefully. Note particularly that C++ function names must be
- <literal>_mangled_</literal>.</para>
+ mangled (that is, not demangled).</para>
</answer>
</qandaentry>