diff options
Diffstat (limited to 'docs/xml/FAQ.xml')
| -rw-r--r-- | docs/xml/FAQ.xml | 62 |
1 files changed, 26 insertions, 36 deletions
diff --git a/docs/xml/FAQ.xml b/docs/xml/FAQ.xml index 720b64702..9ff0626e9 100644 --- a/docs/xml/FAQ.xml +++ b/docs/xml/FAQ.xml @@ -131,9 +131,9 @@ collect2: ld returned 1 exit status <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 @@ collect2: ld returned 1 exit status <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 @@ collect2: ld returned 1 exit status <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 @@ collect2: ld returned 1 exit status 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 @@ collect2: ld returned 1 exit status <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 @@ collect2: ld returned 1 exit status 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 @@ Invalid write of size 1 <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 @@ int main(void) <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> |