[SR-Users] valgrind errors from 3.1-stable (git 2fe4d633e4ac)
marius zbihlei
marius.zbihlei at 1and1.ro
Fri Apr 1 12:33:46 CEST 2011
On 04/01/2011 12:53 PM, Timo Teräs wrote:
> On 04/01/2011 11:17 AM, marius zbihlei wrote:
>
>
> static buffers are not nice solution and can break depending on the call
> chain. However, since if it's going to be deep copied anyway, it'll
> probably work here. I was not sure about the deep copying part, so I
> hesitated to suggest it as possible fix.
>
>
Hello,
I pushed the patch to master and 3.1.
>
> Yes, I tried this actually earlier right after sending my previous mail.
> It seems that this cured all the remaining valgrind errors I was seeing.
>
> So yes, this should definitely pushed to all applicable git repos/branches.
> Yes. My argument was that it absolutely does not work in two cases:
> - the memory allocated for the string is exactly the strings length
> (you'd be overwriting random places with the string terminator)
> - the same memory area is used for two overlapping strings: changing
> one byte would change all string references using that area
>
> Though, in this instance the second item does not seem possible. I'm not
> sure if the first item can happen or not.
>
>
Well, I think the first case is what happens. it will not overwrite
random places, it will place a \0 at the end of the allocated
buffer(even the memory location is not part of that buffer). Because
buffer[length] points to some memory in pkg memory pool, accessing it
will not cause an access violation (it's not an address in .txt or .ro
segments) . The only problem I forsee is that during the set of \0 and
the revert to the original value, the address location would be accessed
in some other way, but I doubt it (keep in mind that locations have to
be properly aligned - so i presume in most cases a padding byte will be
overwritten). Not a good practice, but if no bugs are present I don't
recommend changing it.
Cheers,
Marius
More information about the sr-users
mailing list