Useless memory consumption

Bug #238183 reported by Linard Verstraete
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GST
Fix Released
Undecided
Unassigned
system-tools-backends
Confirmed
Undecided
Unassigned
system-tools-backends (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

Binary package hint: system-tools-backends

*** Platform ***
Xubuntu Hardy 8.04
system-tools-backend 2.6.0-0ubuntu7

Xubuntu Jaunty 9.04
gnome-system-tools 2.22.2-0ubuntu4
system-tools-backend 2.6.0-2ubuntu8

*** Description Problem ***
When you use the "Shared Folders" menu-entry for the first time and do nothing but hit every close button you see, your memory usage will be increased for about 3 minutes by 90 MiB, and for 10 MiB untill the next reboot.

*** Reproduction Problem ***
Step 1. Open "Shared Folders" through the drop-down menu "Applications", or run the "shares-admin"-command in terminal.
Step 2. You get a pop-up window where you are asked to Install Services, click on the "Close"-button.
Step 3. Then you see the remaining window titled "Shared Folders". Click on the "Close"-button.
Step 4. Your memory has now increased with around 90 MiB. Details: 8x SystemToolsBack 10MiB ~ 13 MiB
SystemToolsBack: /usr/bin/perl /usr/share//system-tools-backends-2.0/scripts/SystemToolsBackends.pl -m "AllWithDifferentOptions"
Step 5. After a while, around 3 minutes, they all are all cleared, expect 1 SystemToolsBack remains (/usr/bin/perl /usr/share//system-tools-backends-2.0/scripts/SystemToolsBackends.pl -m Platform) This "SystemToolsBack -m Platfrom" also survives a log-out / log-in. You have to reboot before it's cleared.

*** Expected behavior ***
Step 1 through step 3 the same.
Step 4. Immediate clearance of memory usage.
Step 5. Immediate clearance of memory usage.

*** Additional note ***
I have found bug #64560 describing the problem for Step 5. Nevertheless, this bug isn't a duplicate of bug #64560 because the bug described here puts bug #64560 in a bigger picture and the origin of problem for Step 4 can easily be totally different for bug #64560.
I shall also reopen bug #64560 since it happened again and will add a reference to this bug.

Revision history for this message
Charlie Kravetz (cjkgeek) wrote :

I can confirm that this bug still exists in Intrepid_Ibex 8.10. The information give appears to be accurate.

Thanks for reporting this bug and any supporting documentation. Since this bug has enough information provided for a developer to begin work, I'm going to mark it as confirmed and let them handle it from here. Thanks for taking the time to make Ubuntu better!

Changed in system-tools-backends:
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Linard Verstraete (linardv) wrote :

This is still present in Jaunty_Jackalope 9.04.

Added the GST-project (gnome-system-tools) since this bug occurs when invoking the "shares-admin"-command. So maybe there's an issue with the front-end (shares-admin, part of gnome-system-tools) instead of a problem with the back-end (system-tools-backends).

Also updated the bug description with newer info.

description: updated
description: updated
Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

In Karmic, I can confirm that the -m Platform script does not die after 3 minutes, consuming 10MB until reboot. I'll give a look at this problem.

Though, you mention in the description that there's a 90MB usage on first launch. I guess this comes from the package installation, isn't it? If that usage disappears after it's done, then that part is not a bug.

Changed in system-tools-backends (Ubuntu):
status: Confirmed → Triaged
Changed in gst:
status: New → Confirmed
Revision history for this message
Linard Verstraete (linardv) wrote :

I don't think I completely understand you. Forgive me, English is not my native language...

You say that due to package installation there is an increase of 90MB in memory usage. But
1) I decline the request to install any packages upon request, by clicking on the close button. (see Step 2)
2) I never typed in any administration password and I didn't invoke the command while being root.
So there aren't any packages being installed, ergo it can't be the cause of the increased memory usage. Correct?

Thanks for looking into this issue and your quick reply.
Happy holidays!

Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

So by "first time" you mean first time from fresh boot; there's no package installation involved then. I think you're slightly wrong about memory usage, because the fact that every SystemToolsBackends perl process uses 10MB doesn't mean you can sum up those values to get the total: there's shared memory (reported as SHR in top) for about 2MB each, which explains why a quick test reports that 70MB are used.

There's something I don't get here, because the scripts in themselves only represent a few KB, so I'd expect the total memory usage to be about 15MB. Maybe there's something we're doing wrong in the way we manage memory.

Anyway, the best approach for now would be to stop starting all modules, and instead start the one we use. We could divide the footprint by 5 or so.

Revision history for this message
Linard Verstraete (linardv) wrote :

Ah, now I see. By "first time", I meant, indeed, as long as you didn't install any packages as requested, since the install of the OS, and close the application. Basically doing nothing from the point of view of the shares-admin command.

You can be right about counting memory usage. I don't now very much about it and I didn't take the shared memory into account. So I won't disagree that, while the issue is still present, it can be less then 90MB, that's perfectly possible.

Starting only the modules you use, and preventing unnecessarily load to the system, would be my chose of preference as well. Unless this form of "pre-loading" has some tremendous performance benefits. But I doubt that.

Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

At least with the gnome-system-tools 2.29.90 I've removed IfacesConfig since it wasn't used, which should gain something like 10MB. The main problem is still here, though, it's that perl doesn't share memory among modules.

Changed in system-tools-backends:
status: New → Confirmed
Changed in gst:
status: Confirmed → Fix Released
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.