From: Philippe Waroquiers Date: Fri, 20 Jul 2012 23:40:35 +0000 (+0000) Subject: Document Helgrind limitation that old access stack traces have maximum 8 entries X-Git-Tag: svn/VALGRIND_3_8_0~101 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=9f4932eeeceaffc5fe97f2b85fd996cec423c7b8;p=thirdparty%2Fvalgrind.git 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 043e26c56c..a2c58a92fc 100644 --- a/helgrind/docs/hg-manual.xml +++ b/helgrind/docs/hg-manual.xml @@ -656,7 +656,9 @@ the point it was detected. "This conflicts with a previous write". 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. +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. 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. + older, conflicting access. To limit memory usage, "old" accesses + stack traces are limited to a maximum of 8 entries, even if + value is bigger. 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