[SR-Users] valgrind errors from 3.1-stable (git 2fe4d633e4ac)

[marius zbihlei]

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