Bug 1027317

Summary: cups-browsed leaks a lot of memory
Product: [Fedora] Fedora Reporter: Zdenek Kabelac <zkabelac>
Component: cups-filtersAssignee: Jaromír Končický <jkoncick>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: jpopelka, ovasik, twaugh, zkabelac
Target Milestone: ---Keywords: Patch
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: cups-filters-1.0.41-4.fc20 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-24 03:54:32 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Valgrind log of cups-browsed
none
diff between 1.0.40 and 1.0.41
none
patch
none
New valgrind trace
none
new (hopefully final) patch
none
Valgring trace with fixed memleak none

Description Zdenek Kabelac 2013-11-06 14:38:12 UTC
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:

Comment 1 Jaromír Končický 2013-11-07 09:38:03 UTC
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.

Comment 2 Zdenek Kabelac 2013-11-07 10:25:11 UTC
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

Comment 4 Jaromír Končický 2013-11-12 15:04:15 UTC
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.

Comment 5 Tim Waugh 2013-11-12 15:16:36 UTC
The valgrind trace can usually pinpoint that sort of thing fairly precisely.

Comment 6 Jaromír Končický 2013-11-12 16:30:48 UTC
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.

Comment 7 Jiri Popelka 2013-11-12 16:45:30 UTC
(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

Comment 8 Zdenek Kabelac 2013-11-12 18:41:03 UTC
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.

Comment 9 Jaromír Končický 2013-11-14 09:26:59 UTC
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.

Comment 10 Fedora Update System 2013-11-14 11:43:21 UTC
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

Comment 11 Fedora Update System 2013-11-14 11:43:46 UTC
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

Comment 12 Zdenek Kabelac 2013-11-14 11:44:13 UTC
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?)

Comment 13 Fedora Update System 2013-11-14 19:14:50 UTC
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).

Comment 14 Fedora Update System 2013-11-24 03:54:32 UTC
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.

Comment 15 Fedora Update System 2013-12-07 07:04:38 UTC
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.