Am 29.03.2011 18:15, schrieb Tom Hughes:
> On 29/03/11 15:25, Stefan Kost wrote:
>> Am 26.03.2011 08:52, schrieb Julian Seward:
>>>
>>>> I get this behaviour on various distributions and several people
>>>> confirmed. I now wonder if there is a bug in udev or something is wrong
>>>> in valgrind? Any idea from the valgrind perspective?
>>>
>>> Yes: the program is buggy (reads freed memory) and therefore its
>>> behaviour after that point is of course dependent on what free()
>>> does.  I expect that if you link with a debugging malloc library
>>> that (eg) memset-0xAA's freed memory then you will also see it
>>> behaving differently, even when not run on Valgrind.
>>
>> For the sake of having the correct answer in the list archives - "the 
>> program is
>> buggy" is not neccesarily true. In this case there is no free function for 
>> the
>> returned memory and the application is not freeing memory. It is the library
>> which is buggy if it promisses static memory and then reallocating it.
> 
> From the point of view of valgrind, the definition of the program
> includes all the libraries it uses.
> 
>> Wonder if there could be a client request to annotate that...
> 
> What do you imagine it would do?

I mean annotate that a POINTER is constant, then the memory must not be freed.
Now that I think about it, I could have just used a watch-point in gdb ...

> 
> The solution here is for you to report the bug in the library to the
> author of that library, and in the meantime to work around it in your
> code if you wish now that valgrind has shown you where the problem lies.
> 
> Tom
> 

I had tried that, but the developers could not reproduce it (as they all use
bleeding edge). Now I upgraded my distro and it is gone indeed.

I have added a version dependent work-around in my code.

Stefan

------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Reply via email to