From: Tom H. <to...@co...> - 2020-01-14 19:22:09
|
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 (to...@co...) http://compton.nu/ |