|
From: Stefan K. <en...@ho...> - 2011-03-17 08:14:32
|
hi, I have this little standalone testprogram (compile and run instructions in comment at the top, no fancy dependencies): http://buzztard.svn.sourceforge.net/viewvc/buzztard/trunk/buzztard/design/udev/udevls.c?revision=3231&view=markup It behaves differently when run under valgrind: $ G_SLICE=always-malloc G_DEBUG=gc-friendly GLIBCPP_FORCE_NEW=1 GLIBCXX_FORCE_NEW=1 valgrind --tool=memcheck --leak-check=full --leak-resolution=high --trace-children=yes --num-callers=20 --log-file=./valgrind.log ./udevls | 0x43634b0,/dev/input/event2 | 0x43634b0,/dev/input/event2 | 0x4363f88,/dev/input/event4 | 0x4363f88,/dev/input/event4 <snip> | 0x436c7c0,/dev/input/event9 | 0x436c7c0,/dev/input/event9 | 0x436d0a8,/dev/input/mouse2 | 0x436d0a8,/dev/input/mouse2 | 0x436d9c0,/dev/input/event8 | 0x436d9c0,/dev/input/event8 ! | 0x436e388,/dev/input/mice | 0x436e520,/dev/input/mice What matters is the last line. When *not* run under valgrind the addresses are the same. When run under valgrind I get a couple of ==1989== Invalid read of size 1 ==1989== at 0x41C9B33: vfprintf (vfprintf.c:1614) ==1989== by 0x41D0ACF: printf (printf.c:35) ==1989== by 0x8048785: main (udevcls.c:57) ==1989== Address 0x4358b58 is 0 bytes inside a block of size 16 free'd ==1989== at 0x40267ED: free (vg_replace_malloc.c:366) ==1989== by 0x42EA335: ??? (in /lib/libudev.so.0.9.1) ==1989== by 0x42EB38E: ??? (in /lib/libudev.so.0.9.1) ==1989== by 0x42EB7A0: udev_device_get_devnode (in /lib/libudev.so.0.9.1) ==1989== by 0x404A965: g_udev_device_get_device_file (in /usr/lib/libgudev-1.0.so.0.0.1) ==1989== by 0x804873A: main (udevcls.c:56) full log: http://pastebin.com/4eBCtdxW The udev-source code can be looked at http://git.kernel.org/?p=linux/hotplug/udev.git;a=tree 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? thanks, Stefan |
|
From: Tom H. <to...@co...> - 2011-03-17 08:39:44
|
On 17/03/11 08:13, Stefan Kost wrote: > What matters is the last line. When *not* run under valgrind the > addresses are the same. When run under valgrind I get a couple of > ==1989== Invalid read of size 1 > ==1989== at 0x41C9B33: vfprintf (vfprintf.c:1614) > ==1989== by 0x41D0ACF: printf (printf.c:35) > ==1989== by 0x8048785: main (udevcls.c:57) > ==1989== Address 0x4358b58 is 0 bytes inside a block of size 16 free'd > ==1989== at 0x40267ED: free (vg_replace_malloc.c:366) > ==1989== by 0x42EA335: ??? (in /lib/libudev.so.0.9.1) > ==1989== by 0x42EB38E: ??? (in /lib/libudev.so.0.9.1) > ==1989== by 0x42EB7A0: udev_device_get_devnode (in /lib/libudev.so.0.9.1) > ==1989== by 0x404A965: g_udev_device_get_device_file (in > /usr/lib/libgudev-1.0.so.0.0.1) > ==1989== by 0x804873A: main (udevcls.c:56) In other words you have a printf that is printing data from a block of memory that has been freed - a bug in your code. Valgrind has told you exactly what is wrong - time to go and fix it ;-) Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Stefan K. <en...@ho...> - 2011-03-17 11:57:14
|
On 17.03.2011 10:38, Tom Hughes wrote: > On 17/03/11 08:13, Stefan Kost wrote: > >> What matters is the last line. When *not* run under valgrind the >> addresses are the same. When run under valgrind I get a couple of >> ==1989== Invalid read of size 1 >> ==1989== at 0x41C9B33: vfprintf (vfprintf.c:1614) >> ==1989== by 0x41D0ACF: printf (printf.c:35) >> ==1989== by 0x8048785: main (udevcls.c:57) >> ==1989== Address 0x4358b58 is 0 bytes inside a block of size 16 free'd >> ==1989== at 0x40267ED: free (vg_replace_malloc.c:366) >> ==1989== by 0x42EA335: ??? (in /lib/libudev.so.0.9.1) >> ==1989== by 0x42EB38E: ??? (in /lib/libudev.so.0.9.1) >> ==1989== by 0x42EB7A0: udev_device_get_devnode (in /lib/libudev.so.0.9.1) >> ==1989== by 0x404A965: g_udev_device_get_device_file (in >> /usr/lib/libgudev-1.0.so.0.0.1) >> ==1989== by 0x804873A: main (udevcls.c:56) > In other words you have a printf that is printing data from a block of > memory that has been freed - a bug in your code. > > Valgrind has told you exactly what is wrong - time to go and fix it ;-) > > Tom > Hi tom, there is no need for sarcasm. I am using valgrind for years. Just have a look at the code: http://buzztard.svn.sourceforge.net/viewvc/buzztard/trunk/buzztard/design/udev/udevls.c?revision=3231&view=markup#l40 There is no free. The data I am suppose to get from udev is static. Stefan |
|
From: Tom H. <to...@co...> - 2011-03-17 12:20:17
|
On 17/03/11 11:56, Stefan Kost wrote: > there is no need for sarcasm. I am using valgrind for years. Just have a > look at the code: > http://buzztard.svn.sourceforge.net/viewvc/buzztard/trunk/buzztard/design/udev/udevls.c?revision=3231&view=markup#l40 > There is no free. The data I am suppose to get from udev is static. I did try and look at the code, but I couldn't find udevcls.c in the git repository you mentioned. I hadn't noticed that you had also linked to another repository. That code is using %s format strings to print both devnode1 and devnode2 which are pointers returned from g_udev_device_get_device_file so my guess would be that freed memory is bring returned from that routine. Insert some VALGRIND_CHECK_MEM_IS_DEFINED calls before the printf to validate the arguments and see what is causing the problem. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Stefan K. <en...@ho...> - 2011-03-23 20:19:28
|
Am 17.03.2011 14:19, schrieb Tom Hughes: > On 17/03/11 11:56, Stefan Kost wrote: > >> there is no need for sarcasm. I am using valgrind for years. Just have a >> look at the code: >> http://buzztard.svn.sourceforge.net/viewvc/buzztard/trunk/buzztard/design/udev/udevls.c?revision=3231&view=markup#l40 >> There is no free. The data I am suppose to get from udev is static. > > I did try and look at the code, but I couldn't find udevcls.c in the git > repository you mentioned. I hadn't noticed that you had also linked to > another repository. Yes, that udevls is a small test to point out what I believe is a bug in udev. It is not part of udev. > > That code is using %s format strings to print both devnode1 and devnode2 > which are pointers returned from g_udev_device_get_device_file so my > guess would be that freed memory is bring returned from that routine. udev is saying that those pointer are static. I believe they are not under some circumstances (as shown in the test and unovered by valgrind). I will have to retest that with a newer udev, as udev deveopers seem to not be able to reproduce it. > > Insert some VALGRIND_CHECK_MEM_IS_DEFINED calls before the printf to > validate the arguments and see what is causing the problem. Thanks for the sugestions, the test is trivial and seems to be correct. Many people looked at it. The reason why I posted this to the valgrind list was that I was wondering why the test result is different when running it under valgrind. But I guess thats not easy to explain. Stefan > > Tom > |
|
From: Tom H. <to...@co...> - 2011-03-23 23:58:11
|
On 23/03/11 20:05, Stefan Kost wrote: > Thanks for the sugestions, the test is trivial and seems to be correct. Many > people looked at it. The reason why I posted this to the valgrind list was that > I was wondering why the test result is different when running it under valgrind. > > But I guess thats not easy to explain. No, it's very easy to explain if you accept that valgrind is telling the truth about printing values that are in a freed block. Under valgrind the freed block will be deliberately overwritten when it is freed. When valgrind is not in use it will probably still have the old values in if it has only just been freed. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Julian S. <js...@ac...> - 2011-03-26 06:58:07
|
> 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. J |
|
From: Stefan K. <en...@ho...> - 2011-03-29 14:23:23
|
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. Wonder if there could be a client request to annotate that... Stefan > > J > > ------------------------------------------------------------------------------ > 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 > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Tom H. <to...@co...> - 2011-03-29 15:15:40
|
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 (to...@co...) http://compton.nu/ |
|
From: Stefan K. <en...@ho...> - 2011-04-05 21:00:26
|
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 |