Re: [Valgrind-users] Wonkiness in the presence of stack switching

[John R. <jr...@Bi...>]

Michael Rosellini wrote:
> Both of the previous two problems I wrote about (valgrind crash while delivering a fatal signal and reports that things that were on the heap were on the stack) are eliminated when my program no longer switches stacks during startup.  I've confirmed that I'm calling VALGRIND_STACK_REGISTER correctly.  Has anyone else experienced a similar problem?

See my postings to [valgrind-developers] in 2008 regarding patches for
valgrind to work on UserModeLinux (UML) and WINE.  Some of them were related
to stacks.  In particular, if the current actual stack pointer is outside
the bounds where coregrind thinks it ought to be, then my experience was
that coregrind had difficulty.  This may not be the same as what you see,
but it helped me.

For instance, this message of 07/09/2008:  [There are others, too.]
    [Valgrind-developers] (14/14) vgsvn+wine-stacktrace.patch succeed when MSVC FramePointerOmitted
--- valgrind-svn/coregrind/m_stacktrace.c.orig	2008-07-06 13:44:21.000000000 -0700
+++ valgrind-svn/coregrind/m_stacktrace.c	2008-07-02 21:25:28.000000000 -0700
[snip]
@@ -439,6 +448,13 @@
     Addr stack_lowest_word  = 0;

  #  if defined(VGP_x86_linux)
+   if (VG_(threads)[tid].client_stack_szB <= (stack_highest_word - sp)) {
+      /* sp escaped its bounds.  The application did not tell us
+       * about switching stacks, and we did not notice until now.
+       * Use something plausible.
+       */
+      stack_highest_word = 200*1024 + sp;
+   }
     /* Nasty little hack to deal with syscalls - if libc is using its
        _dl_sysinfo_int80 function for syscalls (the TLS version does),
        then ip will always appear to be in that function when doing a

--