https://bugs.kde.org/show_bug.cgi?id=419230

Tom Hughes <t...@compton.nu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |NOT A BUG
             Status|REPORTED                    |RESOLVED

--- Comment #2 from Tom Hughes <t...@compton.nu> ---
I'm pretty sure that there's no bug here anyway, it's just you're expecting
more of valgrind than it is able to provide.

When stack is reused for different variables inside the same function there is
no guarantee that the compiler will actually move the stack pointer up at the
end of one scope and then back down at the start of the next one - more likely
it will just move it down once at the start of the function to reserve the
maximum amount of memory required and then move it back at the end.

Within the function it will just use whatever regions it wants within that
chunk of stack it has reserved and reuse things as and when it wants.

In fact you don't even need scopes - if you just stop using one variable and
start using another then the compiler might decide to overlay them in the same
way.

What all this means is that there is no way for valgrind to know when the
compiler has switched from using that piece of stack for one variable to using
it for another variable and hence no way for it to mark it as uninitialised
again. Only at the end of the function when the stack is released by moving the
stack pointer will valgrind mark it as uninitialised again.

In general you will find that something like address sanitiser can do a better
job finding stack related issues because it is able to instrument at compile
time - valgrind is better than nothing for sure but it can never do everything
that compile time instrumentation can do.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to