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 a5019735-40e9-0310-863c-91ae7b9d1cf9
diff --git a/helgrind/docs/hg-manual.xml b/helgrind/docs/hg-manual.xml
index 043e26c..a2c58a9 100644
--- a/helgrind/docs/hg-manual.xml
+++ b/helgrind/docs/hg-manual.xml
@@ -656,7 +656,9 @@
"<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 @@
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