zenithsiz/ftmemsim-valgrind
1
0
Fork 0
mirror of https://github.com/Zenithsiz/ftmemsim-valgrind.git synced 2026-02-04 02:18:37 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Document that user level client stack switches might cause crashes

Browse Source 
and that these crahses might be avoided using VALGRIND_STACK_REGISTER
See bug 316613


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13327
This commit is contained in:
Philippe Waroquiers 2013-03-13 22:03:31 +00:00
parent 30275f300c
commit 52b0e470c3
2 changed files with 16 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
docs/xml/manual-core-adv.xml
View File

@ -247,11 +247,12 @@ tool-specific macros).</para>
between start and end is a unique stack. Returns a stack identifier
that can be used with other
<computeroutput>VALGRIND_STACK_*</computeroutput> calls.</para>
<para>Valgrind will use this information to determine if a change to
the stack pointer is an item pushed onto the stack or a change over
to a new stack. Use this if you're using a user-level thread package
and are noticing spurious errors from Valgrind about uninitialized
memory reads.</para>
<para>Valgrind will use this information to determine if a change
to the stack pointer is an item pushed onto the stack or a change
over to a new stack. Use this if you're using a user-level thread
package and are noticing crashes in stack trace recording or
spurious errors from Valgrind about uninitialized memory
reads.</para>
<para><command>Warning:</command> Unfortunately, this client request is
unreliable and best avoided.</para>

17
docs/xml/manual-core.xml
View File

@ -2609,13 +2609,16 @@ shipped.</para>
<para><computeroutput>Warning: client switching stacks?</computeroutput></para>
<para>Valgrind spotted such a large change in the stack pointer
that it guesses the client is switching to
a different stack. At this point it makes a kludgey guess where the
base of the new stack is, and sets memory permissions accordingly.
You may get many bogus error messages following this, if Valgrind
guesses wrong. At the moment "large change" is defined as a change
of more that 2000000 in the value of the
stack pointer register.</para>
that it guesses the client is switching to a different stack. At
this point it makes a kludgey guess where the base of the new
stack is, and sets memory permissions accordingly. At the moment
"large change" is defined as a change of more that 2000000 in the
value of the stack pointer register. If Valgrind guesses wrong,
you may get many bogus error messages following this and/or have
crashes in the stack trace recording code. You might avoid these
problems by informing Valgrind about the stack bounds using
VALGRIND_STACK_REGISTER client request. </para>
</listitem>
<listitem>