Synaptic has memory leaks

Bug #35232 reported by Germán Poo-Caamaño
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
synaptic (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

When I start synaptic it doesn't eat so much memory:

total: 37m
Virt: 29m
Shr: 20m

But, it start to download packages the memory consumption is increased. It is only stop when the download is finished. I just noticed that my computer got slower while I was upgrading previous days, but today I was updating openoffice and other big packages. Synaptic, at the end, was using 292m (total) and 188m (virtual). My machine got too slow because of the memory.

It seems the process of download has leaks. It is easy to confirm. Just follow the memory consumption before update the list of packages, then list of packages and then, downloading big packages. The memory is freed only when the application ends.

Ubuntu Dapper updated to March 16, 2006.
synaptic 0.57.8ubuntu4

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote : Are they really leaks

Can you confirm that the memory being gobbled wasn't shared memory? What does valgrind have to say about the leaks? Is the word leak being used where the word bloat might be better (a leak is actually where memory is lost in such a way that there is no way for it to be freed even if you wanted to free it)?

Revision history for this message
Germán Poo-Caamaño (gpoo) wrote :

I will try again with valgring next time (I'm in a hurry now).

The last run (almost finishing), start with the same I said before:

total: 37m Virt: 29m Shr: 20m

After reload the list of packages:
total: 46m Virt: 39m Shr: 20m

After downloading almost 69 MB of packages (it remains a couple of minutes and its almost done):
total: 216m Virt: 158m Shr: 8m

I know (because previously I saw) when the upgrade ends, the memory will still in use. The only way to have that memory back is finish the program. Probably is bloat, but I can't imagine why the application would need that amount of data in memory even when it has nothing to do.

Revision history for this message
Germán Poo-Caamaño (gpoo) wrote :

# valgrind --leak-check=full synaptic

[...]

==7394== ERROR SUMMARY: 84967 errors from 71 contexts (suppressed: 101 from 7)
==7394== malloc/free: in use at exit: 17,285,739 bytes in 351,785 blocks.
==7394== malloc/free: 12,445,177 allocs, 12,093,392 frees, 762,605,034 bytes allocated.
==7394== For counts of detected errors, rerun with: -v
==7394== searching for pointers to 351,785 not-freed blocks.
==7394== checked 13,973,532 bytes.

[...]

==7394== LEAK SUMMARY:
==7394== definitely lost: 2,302,699 bytes in 61,222 blocks.
==7394== indirectly lost: 3,046,821 bytes in 96,927 blocks.
==7394== possibly lost: 1,741,251 bytes in 42,100 blocks.
==7394== still reachable: 10,186,808 bytes in 151,535 blocks.
==7394== suppressed: 8,160 bytes in 1 blocks.
==7394== Reachable blocks (those to which a pointer was found) are not shown.
==7394== To see them, rerun with: --show-reachable=yes

Matt Zimmerman (mdz)
Changed in synaptic:
assignee: nobody → mvo
Revision history for this message
Michael Vogt (mvo) wrote :

Could you please attach the full valgrind trace as a file? I'm unable to reproduce the amount of memory leakage here so I would be interessted in your log.

Thanks,
 Michael

Revision history for this message
Germán Poo-Caamaño (gpoo) wrote : Full log of synaptic ran using valgrind

The amount of memory used depends directly of the size and amount of packages to be upgraded. Today evolution was updated between other packages.

I hope it helps.

Revision history for this message
Germán Poo-Caamaño (gpoo) wrote :

I didn't see the log because I was busy in other stuffs. It seems that there is no such leaks nowadays. Synapctics has been upgraded a couple of time since I reported this bug.

Revision history for this message
Michael Vogt (mvo) wrote :

Thanks for the new log. Is it correct that you can't reproduce the problem anymore as well? If so, I still would like to keep the bug open for a bit, maybe someone else can and we can get a valgrind trace then.

Thanks,
 Michael

Michael Vogt (mvo)
Changed in synaptic:
status: Unconfirmed → Confirmed
Revision history for this message
tsg1zzn (tsg1zzn) wrote :

==10394==
==10394== LEAK SUMMARY:
==10394== definitely lost: 66,637 bytes in 336 blocks.
==10394== indirectly lost: 155,679 bytes in 7,654 blocks.
==10394== possibly lost: 1,850,932 bytes in 46,891 blocks.
==10394== still reachable: 7,616,677 bytes in 99,501 blocks.
==10394== suppressed: 0 bytes in 0 blocks.
==10394== Reachable blocks (those to which a pointer was found) are not shown.

This was after doing only a small download (1 mb). I don't know how to get the whole log, when I try to redirect stdout to a file it redirects synaptic instead of valgrind.

Revision history for this message
Vish (vish) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

Changed in synaptic (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Vish (vish) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better.
We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future.
To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New".

Changed in synaptic (Ubuntu):
assignee: Michael Vogt (mvo) → nobody
status: Incomplete → Invalid
Revision history for this message
tsg1zzn (tsg1zzn) wrote :

Simply starting and quitting synaptics gives me a report of leaked memory.
==2330== LEAK SUMMARY:
==2330== definitely lost: 8,345 bytes in 33 blocks
==2330== indirectly lost: 22,112 bytes in 690 blocks
==2330== possibly lost: 6,731,607 bytes in 80,015 blocks
==2330== still reachable: 10,248,124 bytes in 102,796 blocks
==2330== suppressed: 0 bytes in 0 blocks

After installing a package:
==2372== LEAK SUMMARY:
==2372== definitely lost: 38,045 bytes in 113 blocks
==2372== indirectly lost: 73,792 bytes in 2,287 blocks
==2372== possibly lost: 11,236,569 bytes in 124,741 blocks
==2372== still reachable: 5,218,655 bytes in 57,609 blocks
==2372== suppressed: 0 bytes in 0 blocks

Changed in synaptic (Ubuntu):
status: Invalid → New
Revision history for this message
Phillip Susi (psusi) wrote :

Running valgrind on maverick shows plenty of leaks for me as well.

Changed in synaptic (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.