On 14/01/2020 19:15, Paul-Antoine Arras wrote:
Le 14/01/2020 à 20:01, Tom Hughes a écrit :
Using it as a thread stack could also do it, though it looks a
bit small for that, or some sort or whacky stack pointer stunts
that lead to valgrind thinking it's part of the stack.
That's interesting. The block in question is not a thread stack but a
regular struct. However, at other places the code does play with
manually-allocated thread stacks, hence stack pointer switches that
might confuse Valgrind.
Can you see a way to confirm this conjecture? In other words, how can I
ensure this is a legitimate false positive?
I wouldn't expect it to go wrong with straightforward use where
malloced blocks are passed to clone as a thread stack, at least
if the correct size is passed, but if you start doing some sort of
coroutines or green thread type stuff and doing context switching
in user space then that's another story.
Basically when valgrind thinks the stack pointer is moving upwards
on return from a function it will mark the memory between the old
and new pointers as invalid, but the problem is that there's no way
to be sure from a write to the stack pointer if that is it being
increased/decreased or if it's a switch to a new stack so valgrind
has to employ heuristics and assume that big changes (for some value
of big) are switches and small changes are moving up/down the stack.
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
