Thank you both for your insights, they are both helpful and much
appreciated.
I think Julian is correct, valgrind doesn't know how to deal with this user
allocated heap - and it isn't OK with the memset() past the end of the
stack pointer. Using the memcheck.h API to mark it as undefined will
probably work for me.
Based on John's comments, I noticed he was specifying optimization level 1
when compiling ("-O"). I had been using the default ("-O0"). For some
reason, valgrind produces errors on this code with -O0, but not with any
other settings (-O1, -O2, -O3, -Os, -Ofast). I wonder if the optimizations
make it harder for valgrind to detect and mark memory beyond the stack
pointer as no-access? Regardless, using anything other than -O0 results in
clean output in my test case, so I have a second viable workaround. Thank
you very much for your help!
On Wed, Dec 12, 2018 at 10:43 PM Julian Seward <jsew...@acm.org> wrote:
> On 13/12/2018 01:07, Chris Teague wrote:
>
> > 4. Clear out the threads stack via memset() to ensure I don't leave any
> > interesting data in the heap.
>
> If I had to guess, I'd say it was this. When the stack pointer moves up
> (to deallocate stuff stored on the stack), Memcheck marks the just-freed
> area as no-access, so it can detect mistaken attempts to access there
> later. So I imagine it has done this with your stack too. Result is that
> when you memset-zero your stack, you got the complaint you got.
>
> If you really want to do that, you can #include <valgrind/memcheck.h> and
> then use VALGRIND_MAKE_MEMORY_UNDEFINED(stack, length of stack) so as to
> mark it accessible but containing garbage, before you zero it out.
>
> J
>
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
