On 13/12/2018 07:53, Chris Teague wrote:
> For some
> reason, valgrind produces errors on this code with -O0, but not with any
> other settings (-O1, -O2, -O3, -Os, -Ofast).
It might just be the case that gcc is clever enough to know that the memset
has no visible effect on the program state, sin
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
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
prob
Strange. I only have an Ubuntu 18.04 machine and the latest valgrind is
3.13. I downloaded the Fedora 28 docker image and built in there, and it
definitely complains. Output below:
[root@4fe07db648b4 home]# gcc p.c -lpthread -o p
[root@4fe07db648b4 home]# ./p
start
thread created
thread running
d
- I have reproduced this on valgrind 3.10 and 3.13
It works correctly (no complaints) on x86_64 under valgrind 3.14 as distributed
by Fedora 28 in valgrind-3.14.0-1.fc28.x86_64.rpm .
$ rpm -q valgrind
valgrind-3.14.0-1.fc28.x86_64
$ type valgrind
valgrind is hashed (/usr/bin/valgrind)
$ valgrin
