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

[Timo Teräs]

On 04/01/2011 01:33 PM, marius zbihlei wrote:
> On 04/01/2011 12:53 PM, Timo Teräs wrote:
>> 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.

What if that byte is actually pkg memory pool management data?
That breaks memory allocation which is done when doing deep copy?

But yes, the re.subst fix alone seems to have removed all the valgrind
reported issues.

- Timo