diff --git a/FAQ.txt b/FAQ.txt
index 818ae6f..1e06288 100644
--- a/FAQ.txt
+++ b/FAQ.txt
@@ -1,13 +1,71 @@
+Valgrind FAQ, version 2.1.2
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Last revised 6 April 2004
+~~~~~~~~~~~~~~~~~~~~~~~~~
 
-A mini-FAQ for valgrind, version 1.9.6
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Last revised 5 May 2003
-~~~~~~~~~~~~~~~~~~~~~~~
+1. Background
+2. Compiling, installing and configuring
+3. Valgrind aborts unexpectedly
+4. Valgrind behaves unexpectedly
+5. Memcheck doesn't find my bug
+6. Miscellaneous
+
+
+-----------------------------------------------------------------
+1. Background
+-----------------------------------------------------------------
+
+1.1. How do you pronounce "Valgrind"?
+
+The "Val" as in the world "value".  The "grind" is pronounced with a
+short 'i' -- ie. "grinned" (rhymes with "tinned") rather than "grined"
+(rhymes with "find").
+
+Don't feel bad:  almost everyone gets it wrong at first.
 
 -----------------------------------------------------------------
 
-Q1. Programs run OK on valgrind, but at exit produce a bunch
-    of errors a bit like this
+1.2. Where does the name "Valgrind" come from?
+
+From Nordic mythology.  Originally (before release) the project was
+named Heimdall, after the watchman of the Nordic gods.  He could "see a
+hundred miles by day or night, hear the grass growing, see the wool
+growing on a sheep's back" (etc).  This would have been a great name,
+but it was already taken by a security package "Heimdal".
+
+Keeping with the Nordic theme, Valgrind was chosen.  Valgrind is the
+name of the main entrance to Valhalla (the Hall of the Chosen Slain in
+Asgard).  Over this entrance there resides a wolf and over it there is
+the head of a boar and on it perches a huge eagle, whose eyes can see to
+the far regions of the nine worlds.  Only those judged worthy by the
+guardians are allowed to pass through Valgrind.  All others are refused
+entrance.
+
+It's not short for "value grinder", although that's not a bad guess.
+
+
+-----------------------------------------------------------------
+2. Compiling, installing and configuring
+-----------------------------------------------------------------
+
+2.1. When I trying building Valgrind, 'make' dies partway with an
+     assertion failure, something like this: make: expand.c:489:
+      
+        allocated_variable_append: Assertion 
+        `current_variable_set_list->next != 0' failed.
+      
+It's probably a bug in 'make'.  Some, but not all, instances of version 3.79.1
+have this bug, see www.mail-archive.com/bug-make@gnu.org/msg01658.html.  Try
+upgrading to a more recent version of 'make'.  Alternatively, we have heard
+that unsetting the CFLAGS environment variable avoids the problem.
+
+
+-----------------------------------------------------------------
+3. Valgrind aborts unexpectedly
+-----------------------------------------------------------------
+
+3.1. Programs run OK on Valgrind, but at exit produce a bunch of errors a bit
+     like this
 
     ==20755== Invalid read of size 4
     ==20755==    at 0x40281C8A: _nl_unload_locale (loadlocale.c:238)
@@ -23,338 +81,351 @@
 
     and then die with a segmentation fault.
 
-A1. When the program exits, valgrind runs the procedure
-    __libc_freeres() in glibc.  This is a hook for memory debuggers,
-    so they can ask glibc to free up any memory it has used.  Doing
-    that is needed to ensure that valgrind doesn't incorrectly
-    report space leaks in glibc.
+When the program exits, Valgrind runs the procedure __libc_freeres() in
+glibc.  This is a hook for memory debuggers, so they can ask glibc to
+free up any memory it has used.  Doing that is needed to ensure that
+Valgrind doesn't incorrectly report space leaks in glibc.
 
-    Problem is that running __libc_freeres() in older glibc versions
-    causes this crash.  
+Problem is that running __libc_freeres() in older glibc versions causes
+this crash.  
 
-    WORKAROUND FOR 1.1.X and later versions of valgrind: use the
-    --run-libc-freeres=no flag.  You may then get space 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.
+WORKAROUND FOR 1.1.X and later versions of Valgrind: use the
+--run-libc-freeres=no flag.  You may then get space 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.
 
 -----------------------------------------------------------------
 
-Q2. [Question erased, as it is no longer relevant]
-
------------------------------------------------------------------
-
-Q3. My (buggy) program dies like this:
+3.2. My (buggy) program dies like this:
       valgrind: vg_malloc2.c:442 (bszW_to_pszW): 
                 Assertion `pszW >= 0' failed.
-    And/or my (buggy) program runs OK on valgrind, but dies like 
-    this on cachegrind.
 
-A3. If valgrind shows any invalid reads, invalid writes and 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 doesn't do any illegal memory
-    accesses.  The above failure will hopefully go away after that.
+If Memcheck (the memory checker) shows any invalid reads, invalid writes
+and 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 doesn't do any illegal memory accesses.  The
+above failure will hopefully go away after that.
 
 -----------------------------------------------------------------
 
-Q4. I'm running Red Hat Advanced Server.  Valgrind always segfaults at
-    startup.  
-
-A4. Known issue with RHAS 2.1, due to funny stack permissions at
-    startup.  However, valgrind-1.9.4 and later automatically handle
-    this correctly, and should not segfault.
-
------------------------------------------------------------------
-
-Q5. I try running "valgrind my_program", but my_program runs normally,
-    and Valgrind doesn't emit any output at all.
-
-A5. Valgrind doesn't work out-of-the-box with programs that are entirely
-    statically linked.  It does a quick test at startup, and if it detects
-    that the program is statically linked, it aborts with an explanation.
-    
-    This test may fail in some obscure cases, eg. if you run a script
-    under Valgrind and the script interpreter is statically linked.
-
-    If you still want static linking, you can ask gcc to link certain
-    libraries statically.  Try the following options:
-
-        -Wl,-Bstatic -lmyLibrary1 -lotherLibrary -Wl,-Bdynamic
-
-    Just make sure you end with -Wl,-Bdynamic so that libc is dynamically
-    linked.
-
-    If you absolutely cannot use dynamic libraries, you can try statically
-    linking together all the .o files in coregrind/, all the .o files of the
-    tool of your choice (eg. those in memcheck/), and the .o files of your
-    program.  You'll end up with a statically linked binary that runs
-    permanently under Valgrind's control.  Note that we haven't tested this
-    procedure thoroughly.
-
------------------------------------------------------------------
-
-Q6. I try running "valgrind my_program" and get Valgrind's startup message,
-    but I don't get any errors and I know my program has errors.
-   
-A6. By default, Valgrind only traces the top-level process.  So if your
-    program spawns children, they won't be traced by Valgrind by default.
-    Also, if your program is started by a shell script, Perl script, or
-    something similar, Valgrind will trace the shell, or the Perl 
-    interpreter, or equivalent.
-
-    To trace child processes, use the --trace-children=yes option.
-
-    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 --logsocket=127.0.0.1:12345 (if you want 
-    logging output sent to port 12345 on localhost).  You can
-    use the valgrind-listener program to listen on that port:
-       valgrind-listener 12345
-    Obviously you have to start the listener process first.
-    See the documentation for more details.
-
------------------------------------------------------------------
-
-Q7. My threaded server process runs unbelievably slowly on
-    valgrind.  So slowly, in fact, that at first I thought it
-    had completely locked up.
-
-A7. We are not completely sure about this, but one possibility
-    is that laptops with power management fool valgrind's 
-    timekeeping mechanism, which is (somewhat in error) based
-    on the x86 RDTSC instruction.  A "fix" which is claimed to
-    work is to run some other cpu-intensive process at the same
-    time, so that the laptop's power-management clock-slowing
-    does not kick in.  We would be interested in hearing more
-    feedback on this.
-
-    Another possible cause is that versions prior to 1.9.6
-    did not support threading on glibc 2.3.X systems well.
-    Hopefully the situation is much improved with 1.9.6.
-
------------------------------------------------------------------
-
-Q8. My program dies, printing a message like this along the way: 
+3.3. My program dies, printing a message like this along the way: 
 
       disInstr: unhandled instruction bytes: 0x66 0xF 0x2E 0x5
 
-A8. Valgrind doesn't support the full x86 instruction set, although
-    it now supports many SSE and SSE2 instructions.  If you know
-    the failing instruction is an SSE/SSE2 instruction, you might
-    be able to recompile your progrma without it by using the flag
-    -march to gcc.  Either way, let us know and we'll try to fix it.
+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 progrma without it by using the flag -march to gcc.  Either way,
+let us know and we'll try to fix it.
 
 -----------------------------------------------------------------
 
-Q9. My program dies complaining that __libc_current_sigrtmin
-    is unimplemented.
-
-A9. Should be fixed in 1.9.6.  I would appreciate confirmation 
-    of that.
-
------------------------------------------------------------------
-
-Q10. I upgraded to Red Hat 9 and threaded programs now act
-     strange / deadlock when they didn't before.
-
-A10. Thread support on glibc 2.3.2+ with NPTL is not as 
-     good as on older LinuxThreads-based systems.  We have
-     this under consideration.  Avoid Red Hat >= 8.1 for
-     the time being, if you can.
-
-     5 May 03: 1.9.6 should be significantly improved on 
-     Red Hat 9, SuSE 8.2 and other glibc-2.3.2 systems.
-
------------------------------------------------------------------
-
-Q11. I really need to use the NVidia libGL.so in my app.
-     Help!
-
-A11. NVidia also noticed this it seems, and the "latest" drivers
-     (version 4349, apparently) come with this text
-
-        DISABLING CPU SPECIFIC FEATURES
-
-        Setting the environment variable __GL_FORCE_GENERIC_CPU to a
-        non-zero value will inhibit the use of CPU specific features
-        such as MMX, SSE, or 3DNOW!.  Use of this option may result in
-        performance loss.  This option may be useful in conjunction with
-        software such as the Valgrind memory debugger.
-
-     Set __GL_FORCE_GENERIC_CPU=1 and Valgrind should work.  This has
-     been confirmed by various people.  Thanks NVidia!
-
------------------------------------------------------------------
-
-Q12. My program dies like this (often at exit):
-
-     VG_(mash_LD_PRELOAD_and_LD_LIBRARY_PATH): internal error:
-     (loads of text)
-
-A12. One possible cause is that your program modifies its
-     environment variables, possibly including zeroing them
-     all.  Valgrind relies on the LD_PRELOAD, LD_LIBRARY_PATH and
-     VG_ARGS variables.  Zeroing them will break things.
-
-     As of 1.9.6, Valgrind only uses these variables with
-     --trace-children=no or when executing execve().  This should 
-     reduce the potential for problems.
-
------------------------------------------------------------------
-
-Q13.  My program dies like this:
+3.4. My program dies like this:
 
       error: /lib/librt.so.1: symbol __pthread_clock_settime, version
       GLIBC_PRIVATE not defined in file libpthread.so.0 with link time
       reference
 
-A13.  This is a total swamp.  Nevertheless there is a way out.
-      It's a problem which is not easy to fix.  Really the problem is
-      that /lib/librt.so.1 refers to some symbols
-      __pthread_clock_settime and __pthread_clock_gettime in
-      /lib/libpthread.so which are not intended to be exported, ie
-      they are private.
+This is a total swamp.  Nevertheless there is a way out.  It's a problem
+which is not easy to fix.  Really the problem is that /lib/librt.so.1
+refers to some symbols __pthread_clock_settime and
+__pthread_clock_gettime in /lib/libpthread.so which are not intended to
+be exported, ie they are private.
 
-      Best solution is to ensure your program does not use
-      /lib/librt.so.1.
+Best solution is to ensure your program does not use /lib/librt.so.1.
 
-      However .. since you're probably not using it directly, or even
-      knowingly, that's hard to do.  You might instead be able to fix
-      it by playing around with coregrind/vg_libpthread.vs.  Things to
-      try:
+However .. since you're probably not using it directly, or even
+knowingly, that's hard to do.  You might instead be able to fix it by
+playing around with coregrind/vg_libpthread.vs.  Things to try:
 
-      Remove this
+Remove this
 
-         GLIBC_PRIVATE {
-            __pthread_clock_gettime;
-            __pthread_clock_settime;
-         };
+  GLIBC_PRIVATE {
+     __pthread_clock_gettime;
+     __pthread_clock_settime;
+  };
 
-      or maybe remove this
+or maybe remove this
 
-         GLIBC_2.2.3 {
-            __pthread_clock_gettime;
-            __pthread_clock_settime;
-         } GLIBC_2.2;
+  GLIBC_2.2.3 {
+     __pthread_clock_gettime;
+    __pthread_clock_settime;
+  }  GLIBC_2.2;
 
-      or maybe add this
+or maybe add this
 
-         GLIBC_2.2.4 {
-            __pthread_clock_gettime;
-            __pthread_clock_settime;
-         } GLIBC_2.2;
+  GLIBC_2.2.4 {
+     __pthread_clock_gettime;
+     __pthread_clock_settime;
+  } GLIBC_2.2;
 
-         GLIBC_2.2.5 {
-            __pthread_clock_gettime;
-            __pthread_clock_settime;
-         } GLIBC_2.2;
+  GLIBC_2.2.5 {
+     __pthread_clock_gettime;
+     __pthread_clock_settime;
+  } GLIBC_2.2;
 
-      or some combination of the above.  After each change you need to
-      delete coregrind/libpthread.so and do make && make install.
+or some combination of the above.  After each change you need to delete
+coregrind/libpthread.so and do make && make install.
 
-      I just don't know if any of the above will work.  If you can
-      find a solution which works, I would be interested to hear it.
+I just don't know if any of the above will work.  If you can find a
+solution which works, I would be interested to hear it.
 
-      To which someone replied:
+To which someone replied:
 
-      I deleted this:
+  I deleted this:
 
-          GLIBC_2.2.3 { 
-             __pthread_clock_gettime; 
-             __pthread_clock_settime; 
-          } GLIBC_2.2; 
+  GLIBC_2.2.3 { 
+     __pthread_clock_gettime; 
+     __pthread_clock_settime; 
+  } GLIBC_2.2; 
 
-      and it worked.
+  and it worked.
+
+
+-----------------------------------------------------------------
+4. Valgrind behaves unexpectedly
+-----------------------------------------------------------------
+
+4.1. I try running "valgrind my_program", but my_program runs normally,
+     and Valgrind doesn't emit any output at all.
+
+For versions prior to 2.1.1:
+
+Valgrind doesn't work out-of-the-box with programs that are entirely
+statically linked.  It does a quick test at startup, and if it detects
+that the program is statically linked, it aborts with an explanation.
+    
+This test may fail in some obscure cases, eg. if you run a script under
+Valgrind and the script interpreter is statically linked.
+
+If you still want static linking, you can ask gcc to link certain
+libraries statically.  Try the following options:
+
+        -Wl,-Bstatic -lmyLibrary1 -lotherLibrary -Wl,-Bdynamic
+
+Just make sure you end with -Wl,-Bdynamic so that libc is dynamically
+linked.
+
+If you absolutely cannot use dynamic libraries, you can try statically
+linking together all the .o files in coregrind/, all the .o files of the
+tool of your choice (eg. those in memcheck/), and the .o files of your
+program.  You'll end up with a statically linked binary that runs
+permanently under Valgrind's control.  Note that we haven't tested this
+procedure thoroughly.
+
+
+For versions 2.1.1 and later:
+
+Valgrind does now work with static binaries, although beware that some
+of the tools won't operate as well as normal, because they have access
+to less information about how the program runs.  Eg. Memcheck will miss
+some errors that it would otherwise find.  This is because Valgrind
+doesn't replace malloc() and friends with its own versions.  It's best
+if your program is dynamically linked with glibc.
 
 -----------------------------------------------------------------
 
-Q14.  My program uses the C++ STL and string classes.  Valgrind
-      reports 'still reachable' memory leaks involving these classes
-      at the exit of the program, but there should be none.
+4.2. My threaded server process runs unbelievably slowly on Valgrind.
+     So slowly, in fact, that at first I thought it had completely
+     locked up.
 
-A14.  First of all: relax, it's probably not a bug, but a feature.
-      Many implementations of the C++ standard libraries use their own
-      memory pool allocators.  Memory for quite a number of destructed
-      objects is not immediately freed and given back to the OS, but
-      kept in the pool(s) for later re-use.  The fact that the pools
-      are not freed at the exit() of the program cause valgrind to
-      report this memory as still reachable.  The behaviour not to
-      free pools at the exit() could be called a bug of the library
-      though.
+We are not completely sure about this, but one possibility is that
+laptops with power management fool Valgrind's timekeeping mechanism,
+which is (somewhat in error) based on the x86 RDTSC instruction.  A
+"fix" which is claimed to work is to run some other cpu-intensive
+process at the same time, so that the laptop's power-management
+clock-slowing does not kick in.  We would be interested in hearing more
+feedback on this.
 
-      Using gcc, you can force the STL to use malloc and to free
-      memory as soon as possible by globally disabling memory caching.
-      Beware!  Doing so will probably slow down your program,
-      sometimes drastically.
-
-      - With gcc 2.91, 2.95, 3.0 and 3.1, compile all source using the
-        STL with -D__USE_MALLOC. Beware! This is removed from gcc
-        starting with version 3.3.
-
-      - With 3.2.2 and later, you should export the environment
-        variable GLIBCPP_FORCE_NEW before running your program.
-
-      There are other ways to disable memory pooling: using the
-      malloc_alloc template with your objects (not 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
-         http://gcc.gnu.org/onlinedocs/libstdc++/ext/howto.html#3
-      if you absolutely want to do that. But beware:
-
-         1) there are currently changes underway for gcc which are not
-            totally reflected in the docs right now 
-            ("now" == 26 Apr 03)
-
-         2) allocators belong to the more messy parts of the STL and
-            people went at great lengths to make it portable across
-            platforms. Chances are good that your solution will work
-            on your platform, but not on others.
+Another possible cause is that versions prior to 1.9.6 did not support
+threading on glibc 2.3.X systems well.  Hopefully the situation is much
+improved with 1.9.6 and later versions.
 
 -----------------------------------------------------------------
 
-Q15.  My program dies with a segmentation fault, but Valgrind doesn't give
-      any error messages before it, or none that look related.
+4.3. My program uses the C++ STL and string classes.  Valgrind
+     reports 'still reachable' memory leaks involving these classes
+     at the exit of the program, but there should be none.
 
-A15.  The one kind of segmentation fault that Valgrind won't give any
-      warnings about is writes to read-only memory.  Maybe your program is
-      writing to a static string like this:
+First of all: relax, it's probably not a bug, but a feature.  Many
+implementations of the C++ standard libraries use their own memory pool
+allocators.  Memory for quite a number of destructed objects is not
+immediately freed and given back to the OS, but kept in the pool(s) for
+later re-use.  The fact that the pools are not freed at the exit() of
+the program cause Valgrind to report this memory as still reachable.
+The behaviour not to free pools at the exit() could be called a bug of
+the library though.
 
-        char* s = "hello";
-        s[0] = 'j';
+Using gcc, you can force the STL to use malloc and to free memory as
+soon as possible by globally disabling memory caching.  Beware!  Doing
+so will probably slow down your program, sometimes drastically.
 
-      or something similar.  Writing to read-only memory can also apparently
-      make LinuxThreads behave strangely.
+- With gcc 2.91, 2.95, 3.0 and 3.1, compile all source using the STL
+  with -D__USE_MALLOC. Beware! This is removed from gcc starting with
+  version 3.3.
+
+- With 3.2.2 and later, you should export the environment variable
+  GLIBCPP_FORCE_NEW before running your program.
+
+There are other ways to disable memory pooling: using the malloc_alloc
+template with your objects (not 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
+http://gcc.gnu.org/onlinedocs/libstdc++/ext/howto.html#3 if you
+absolutely want to do that. But beware:
+
+1) there are currently changes underway for gcc which are not totally
+   reflected in the docs right now ("now" == 26 Apr 03)
+
+2) allocators belong to the more messy parts of the STL and people went
+   at great lengths to make it portable across platforms. Chances are
+   good that your solution will work on your platform, but not on
+   others.
+
+-----------------------------------------------------------------------------
+4.4. The stack traces given by Memcheck (or another tool) aren't helpful.
+     How can I improve them?
+
+If they're not long enough, use --num-callers to make them longer.
+
+If they're not detailed enough, make sure you are compiling with -g to add
+debug information.  And don't strip symbol tables (programs should be
+unstripped unless you run 'strip' on them;  some libraries ship stripped).
+
+Also, -fomit-frame-pointer and -fstack-check can make stack traces worse.
+
+Some example sub-traces:
+
+ With debug information and unstripped (best):
+
+    Invalid write of size 1
+       at 0x80483BF: really (malloc1.c:20)
+       by 0x8048370: main (malloc1.c:9)
+
+ With no debug information, unstripped:
+
+    Invalid write of size 1
+       at 0x80483BF: really (in /auto/homes/njn25/grind/head5/a.out)
+       by 0x8048370: main (in /auto/homes/njn25/grind/head5/a.out)
+
+ With no debug information, stripped:
+
+    Invalid write of size 1
+       at 0x80483BF: (within /auto/homes/njn25/grind/head5/a.out)
+       by 0x8048370: (within /auto/homes/njn25/grind/head5/a.out)
+       by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so)
+       by 0x80482CC: (within /auto/homes/njn25/grind/head5/a.out)
+
+ With debug information and -fomit-frame-pointer:
+
+    Invalid write of size 1
+       at 0x80483C4: really (malloc1.c:20)
+       by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so)
+       by 0x80482CC: ??? (start.S:81)
+
+-----------------------------------------------------------------
+5. Memcheck doesn't find my bug
+-----------------------------------------------------------------
+
+5.1. I try running "valgrind --tool=memcheck my_program" and get
+     Valgrind's startup message, but I don't get any errors and I know
+     my program has errors.
+   
+By default, Valgrind only traces the top-level process.  So if your
+program spawns children, they won't be traced by Valgrind by default.
+Also, if your program is started by a shell script, Perl script, or
+something similar, Valgrind will trace the shell, or the Perl
+interpreter, or equivalent.
+
+To trace child processes, use the --trace-children=yes option.
+
+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
+--logsocket=127.0.0.1:12345 (if you want logging output sent to port
+12345 on localhost).  You can use the valgrind-listener program to
+listen on that port:
+
+  valgrind-listener 12345 
+  
+Obviously you have to start the listener process first.  See the
+documentation for more details.
 
 -----------------------------------------------------------------
 
-Q16.  When I trying building Valgrind, 'make' dies partway with an
-      assertion failure, something like this: make: expand.c:489:
-      
-        allocated_variable_append: Assertion 
-        `current_variable_set_list->next != 0' failed.
-      
-A16.  It's probably a bug in 'make'.  Some, but not all, instances of
-      version 3.79.1 have this bug, see 
-      www.mail-archive.com/bug-make@gnu.org/msg01658.html.  Try upgrading to a
-      more recent version of 'make'.  Alternatively, we have heard that
-      unsetting the CFLAGS environment variable avoids the problem.
+5.2. Why doesn't Memcheck find the array overruns in this program?
+
+       int static[5];
+
+       int main(void)
+       {
+          int stack[5];
+
+          static[5] = 0;
+          stack [5] = 0;
+          
+          return 0;
+       }
+
+Unfortunately, Memcheck doesn't do bounds checking on static or stack
+arrays.  We'd like to, but it's just not possible to do in a reasonable
+way that fits with how Memcheck works.  Sorry.
 
 -----------------------------------------------------------------
 
-Q17.  I tried writing a suppression but it didn't work.  Can you 
-      write my suppression for me?
+5.3. My program dies with a segmentation fault, but Memcheck doesn't give
+     any error messages before it, or none that look related.
 
-A17.  Yes!  Use the --gen-suppressions=yes feature to spit out
-      suppressions automatically for you.  You can then edit them
-      if you like, eg. combining similar automatically generated
-      suppressions using wildcards like '*'.
+One possibility is that your program accesses to memory with
+inappropriate permissions set, such as writing to read-only memory.
+Maybe your program is writing to a static string like this:
 
-      If you really want to write suppressions by hand, read the 
-      manual carefully.  Note particularly that C++ function names
-      must be _mangled_.
+    char* s = "hello";
+    s[0] = 'j';
+
+or something similar.  Writing to read-only memory can also apparently
+make LinuxThreads behave strangely.
+
+
+-----------------------------------------------------------------
+6. Miscellaneous
+-----------------------------------------------------------------
+
+6.1. I tried writing a suppression but it didn't work.  Can you 
+     write my suppression for me?
+
+Yes!  Use the --gen-suppressions=yes feature to spit out suppressions
+automatically for you.  You can then edit them if you like, eg.
+combining similar automatically generated suppressions using wildcards
+like '*'.
+
+If you really want to write suppressions by hand, read the manual
+carefully.  Note particularly that C++ function names must be _mangled_.
+
+-----------------------------------------------------------------
+
+6.2. With Memcheck/Addrcheck's memory leak detector, what's the
+     difference between "definitely lost", "possibly lost", "still
+     reachable", and "suppressed"?
+
+The details are in section 3.6 of the manual.
+
+In short:
+
+  - "definitely lost" means your program is leaking memory -- fix it!
+
+  - "possibly lost" means your program is probably leaking memory,
+    unless you're doing funny things with pointers.
+
+  - "still reachable" means your program is probably ok -- it didn't
+    free some memory it could have.  This is quite common and often
+    reasonable.  Don't use --show-reachable=yes if you don't want to see
+    these reports.
+
+  - "suppressed" means that a leak error has been suppressed.  There are
+    some suppressions in the default suppression files.  You can ignore
+    suppressed errors.
 
 -----------------------------------------------------------------