Document Helgrind limitation that old access stack traces have maximum 8 entries

#define N_FRAMES 8
(defined in libhb_core.c:3888)

implies that 'other thread' stack traces are limited to 8,
even with a bigger --num-callers.

=> document this in the manual to avoid that a user believes this is a
bug in the stack trace logic of Valgrind.

git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12767

diff --git a/helgrind/docs/hg-manual.xml b/helgrind/docs/hg-manual.xml
index 043e26c56ce07d3a32ed45acbfa008590cf2b894..a2c58a92fc1d29f63f67793537e1362b55ed411c 100644 (file)
--- a/helgrind/docs/hg-manual.xml
+++ b/helgrind/docs/hg-manual.xml
@@ -656,7 +656,9 @@ the point it was detected.</para>
 "<computeroutput>This conflicts with a previous
 write</computeroutput>".  This shows a previous access which also
 accessed the stated address, and which is believed to be racing
-against the access in the first call stack.</para>
+against the access in the first call stack. Note that this second
+call stack is limited to a maximum of 8 entries to limit the
+memory usage.</para>
 
 <para>Finally, Helgrind may attempt to give a description of the
 raced-on address in source level terms.  In this example, it
@@ -1099,7 +1101,9 @@ unlock(mx)                             unlock(mx)
         Helgrind collects enough information about "old" accesses that
         it can produce two stack traces in a race report -- both the
         stack trace for the current access, and the trace for the
-        older, conflicting access.</para>
+        older, conflicting access. To limit memory usage, "old" accesses
+        stack traces are limited to a maximum of 8 entries, even if
+        <option>--num-callers</option> value is bigger.</para>
       <para>Collecting such information is expensive in both speed and
         memory, particularly for programs that do many inter-thread
         synchronisation events (locks, unlocks, etc).  Without such