Created attachment 363671 [details] F11 valgrind logfile (GOOD) Description of problem: [This is a followup to bug #518247] After upgrading from F11 to F12-rawhide valgrind starts to report false positives for memory leaks. Version-Release number of selected component (if applicable): valgrind-3.5.0-2.i686 How reproducible: always Additional info: Program under test: pidgin + pidgin-sipe plugin Command line: /usr/bin/valgrind --leak-check=yes /usr/bin/pidgin --debug F11 versions: pidgin-2.6.2-1.fc11.i586 pidgin-sipe-1.6.3-4.20091005gita44562d.fc11.i586 valgrind-3.4.1-3.i586
More complete list of F11 components: pidgin-2.6.2-1.fc11.i586 pidgin-sipe-1.6.3-4.20091005gita44562d.fc11.i586 glib2-2.20.5-1.fc11.i586 glibc-2.10.1-5.i686 valgrind-3.4.1-3.i586
Created attachment 363672 [details] Rawhide valgrind logfile (BAD) Rawhide components: pidgin-2.6.2-2.fc12.i686 pidgin-sipe-1.6.3-4.20091005gita44562d.fc12.i686 glib2-2.22.1-1.fc12.i686 glibc-2.10.90-24.i686 valgrind-3.5.0-2.i686
Test procedure: start pidgin, press CTRL-Q when the buddy window appears. Now that I think of it, you probably don't need pidgin-sipe at all, because it that test scenario only the library is loaded but no code from it is ever executed.
Created attachment 363930 [details] F11 valgrind 3.5.0 logfile (BAD) I rebuilt the rawhide valgrind-3.5.0 SRPM for F11. This version also reports false positives. So glibc/glib2 changes can't be the root cause for the problem. Maybe we should yank valgrin 3.5.0 from F12 and fall back to 3.4.1 until this problem can be fixed?
Created attachment 364074 [details] valgrind-3.5.0-ifunc.patch back-ported to 3.4.1 I back-ported the valgrind 3.5.0 patch for bug #518247 to the latest valgrind-3.4.1-7 package on koji <http://koji.fedoraproject.org/koji/buildinfo?buildID=122737> and compiled the package on F12 rawhide. The false positives are gone with this version. So until valgrind 3.5.0 is fixed I have at least a workaround for F12.
Created attachment 364238 [details] hack Please read http://valgrind.org/docs/manual/dist.news.html If you want, you can just ignore possibly lost blocks, apparently pidgin (or is it glib2, libpurple or whatever, haven't figured out yet) uses huge number of interior pointers (malloced blocks where you don't keep any pointer to the start of the block, but instead have pointer into the middle of the block). With this hack patch I've counted over 260 blocks directly reachable from the root segments or normal reachable blocks only only through interior pointers. The output now looks like: ... block: 49 at 0x4c3ae00 -> Loss state 1 interior ptr 0x4c3aec0 from -1 at 0x0 0x3e42ea9dd0 block: 50 at 0x4c3b040 -> Loss state 1 block: 51 at 0x4c3b190 -> Loss state 1 block: 52 at 0x4c3b200 -> Loss state 1 block: 53 at 0x4c3b730 -> Loss state 0 block: 54 at 0x4c3b780 -> Loss state 0 block: 55 at 0x4c3b800 -> Loss state 1 interior ptr 0x4c3b890 from -1 at 0x0 0x3e42ea9e68 block: 56 at 0x4c3ba00 -> Loss state 1 interior ptr 0x4c3ba90 from -1 at 0x0 0x3e42ea9b00 block: 57 at 0x4c3bc10 -> Loss state 0 block: 58 at 0x4c3bc60 -> Loss state 0 block: 59 at 0x4c3bd00 -> Loss state 1 interior ptr 0x4c3bd50 from -1 at 0x0 0x3e3b6dd2d0 block: 60 at 0x4c3be80 -> Loss state 0 block: 61 at 0x4c3bf00 -> Loss state 1 interior ptr 0x4c3bf20 from -1 at 0x0 0x3e42ea9e50 ... Don't know if it would be helpful to map it better to where that block has been allocated from.
I tried the same test with finch: same result. So at least GTK2 can be taken out of the picture, as it isn't used by finch. Thanks for the documentation links they were enlightening. If I understand the NEWS section correctly then the difference between 3.4.1 and 3.5.0 is that the latter now considers case (7) [user manual section 4.2.7] to be a memory leak error. I think the correct solution to this "problem" would be to add valgrind awareness (section 4.7) to glib2's memory allocation routines (e.g. gslice.c). Then valgrind should understand that the interior pointers are actually start pointers to memory blocks handled by glib2. That should also refine the memory leak detection for glib2 clients. Google found this: <http://www.linuxprogrammingblog.com/using-valgrind-to-debug-memory-leaks>, i.e. the glib2 authors have already considered this case. Tried this: G_DEBUG="gc-friendly" G_SLICE="always-malloc" valgrind --leak-check=yes /usr/bin/pidgin While the log is still huge it now no longer contains fake warnings from the plugin I'm testing, i.e. valgrind is usable again. Actually it seems I just found a new memory leak in the code :-)