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? 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 -- Tom Hughes (t...@compton.nu) http://compton.nu/ ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
