Created attachment 820421 [details] Valgrind log of cups-browsed Description of problem: Looking for some other problems in my system I've noticed large memory leaks in cups-browsed. Version-Release number of selected component (if applicable): cups-filters-libs-1.0.41-1.fc21.x86_64 cups-1.7.0-4.fc21.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Could you please provide more information about how to reproduce this Valgrind log? It would make it easier for me. Especially how you run cups-browsed (with valgrind) and how it is exited (the program exits itself or you use some signal). Thanks.
To get the valgrind trace use: valgrind --track-fds=yes --read-var-info=yes --leak-check=full --track-origins=yes --num-callers=40 --show-reachable=yes --time-stamp=yes /usr/sbin/cups-browsed -d Be sure you have as much -debuginfo packages for all needed libs - mainly cups-filters & cups, glib2, glibc. Focus on 'lost' elements in trace like i.e.: ==00:00:04:00.739 16973== 4,098 bytes in 69 blocks are definitely lost in loss record 335 of 349 ==00:00:04:00.731 16973== 656 (64 direct, 592 indirect) bytes in 1 blocks are definitely lost in loss record 297 of 349 ==00:00:04:00.741 16973== 502,016 bytes in 1,655 blocks are indirectly lost in loss record 348 of 349
Created attachment 823016 [details] diff between 1.0.40 and 1.0.41 I figured out that cups-browsed from version 1.0.40 does not leak but 1.0.41 does, so the bug was most probably introduced in 1.0.41. I will look deeper in the code and try to find the place where it leaks.
The valgrind trace can usually pinpoint that sort of thing fairly precisely.
Created attachment 823044 [details] patch Finally I managed to fix this problem, it was really very small negligence of freeing allocated memory and structures in newly added code, causing the infinite leaks.
(In reply to jkoncick from comment #6) > Created attachment 823044 [details] > patch great > Finally I managed to fix this problem /me would be cautious saying it after experience with bug #959682, comment #10 :-) Let's see what our leaks discoverer thinks about it. Zdenek, could you give it a try ? http://koji.fedoraproject.org/koji/taskinfo?taskID=6172388
Created attachment 823093 [details] New valgrind trace It has got certainly much better since the growth speed has been significantly lowered. However in the attached valgrind log there are still couple 'definitely lost' elements present. I guess the most important one is this: 8,303 bytes in 437 blocks are definitely lost in loss record 278 of 283 at 0x4C2945D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) by 0x762F1D9: strdup (strdup.c:42) by 0x10D787: generate_local_queue (cups-browsed.c:927) by 0x10E307: found_cups_printer (cups-browsed.c:1382) by 0x10EA95: browse_poll (cups-browsed.c:1915) by 0x6BF6F12: g_timeout_dispatch (gmain.c:4448) by 0x6BF6364: g_main_context_dispatch (gmain.c:3065) by 0x6BF66F7: g_main_context_iterate.isra.23 (gmain.c:3710) by 0x6BF6B09: g_main_loop_run (gmain.c:3904) by 0x10B7B8: main (cups-browsed.c:2612) Then there are some CRYPTO related things - unsure about their impact.
Created attachment 823828 [details] new (hopefully final) patch You're right, I overlooked that one leak. Now I eliminated all "definitely lost" leaks, you can test it here: http://koji.fedoraproject.org/koji/taskinfo?taskID=6178007 If everything is ok, then I can add this patch into repository.
cups-filters-1.0.41-3.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/cups-filters-1.0.41-3.fc20
cups-filters-1.0.41-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/cups-filters-1.0.41-3.fc19
Created attachment 823897 [details] Valgring trace with fixed memleak Here is my latest valgrind trace to confirm I'm not seeing any 'definitely lost' elements this time - though the shutdown logic in the code might be improved as well. Compared with the 1st. trace I've added more debuginfo packages for full traces of cryptolibs. Looks like certain buffers in-use are taken from stack and not fully aligned/cleared before its use ? Number of 'Conditional jump or move depends on uninitialized value(s)' looks a bit scary - but it seem this is a bug in other package (cups/crypto?)
Package cups-filters-1.0.41-3.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing cups-filters-1.0.41-3.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-21306/cups-filters-1.0.41-3.fc20 then log in and leave karma (feedback).
cups-filters-1.0.41-4.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
cups-filters-1.0.41-4.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.