Created attachment 110733 [details]
Menu not responding

Created attachment 110739 [details]
Using 100% of the resources of one core, and almost 350 MB of ram

Here is a screenshot, when main-menu takes 30 seconds to open.  Current solution is to end process with gnome-system-monitor, and reload.

I noticed similar issues. The menu doesn't open and uses 100% of the cpu.

I wasn't able to reproduce the huge memory usage however.

Also, there are smaller bugs. The Close button in the About dialog doesn't work.

Any clue on this bug. It really makes the new menu unusable on 10.2 due to its high cpu usage and ram requests.

I hope a solution will come soon, considering it's the default in GNOME.

Created attachment 115786 [details]
main-menu consuming over 200Mb of RAM

main-menu regularly consumes abnormal amounts of processor and memory resources, even when I am not actively using it.  On a single core computer this can bring things to a near stand still.

I didn't notice the problem of huge memory usage on my laptop because of the high quantity for RAM I have on it. I just checked and it uses in this moment 69.4 MB.

I had to disable the main-menu on my desktop, which has 512 MB of RAM, because it was able to saturate it making the PC slow and unusable.

"I just checked and it uses in this moment 69.4 MB."

~70 MB for just a Menu? That is just way too much! It also eats all cpu time here. Just switched back to the old gnome menu, because this one is just unusable atm. It also needs too much time on startup.

BTW: This behavior appeared for me somewhere between revision 35 to 40 of svn version, with introducing the new "recent-apps" routine...

This sounds suspiciously like the hal leak.  Scott, do you know if this was plugged in 10.2?

I'm aware of 3 that heavily impacted g-m-m and they all appear in the changelog on 10.2

The first one you entered 177427 appears on May 22
The two I entered 187108 and 185032 appear in June and July

same error here

 2137 sdz       25   0  362m 332m  14m R   98 32.9  20:16.08 main-menu          

This happens every day! I hate openSuse for that, because the menu is the central place of my daily computer life.

same problem here...  10.2 / x86_64

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                               
 5161 kbryant   25   0  231m  25m  13m R  101  0.3  53:10.69 main-menu 


goes to 100% CPU every single day.  

Got the same problem, running openSUSE 10.2 on a hp nc6220. Tried with and without XGL/Compiz. 
1) It takes very long time, over 1 minute after logging in before the button "Computer" even appears.
2) After it appears it sometimes you can click on it and it will pop up the main menu directly and sometimes it takes over 1 minute. After the menu has apperead I can click on a application and it will load. Trying to open the menu after that fails, have to wait another minute or two before it appears.
3) This has started to happen just recently in the last week or so, first after a couple of hours of using the computer.
4) Sometimes the menu will be all white and it seems as of the windowing system has hanged, I may or may not be able to use the application currently in focus. The only thing that helps is ctrl-alt-backspace and a reboot.
5) Tried to remove all of my Gnome configuration folders from ~ without luck.

I'm having similar issues here. main-menu seems to be randomly having CPU spikes. If I open a .c file in gedit, make some changes to the file then re-save it main-menu's CPU usage jumps way up (upon re-saving).

Take a look at Bug #221143 . Cleaning '~/.recently-used.xbel' solved my problems in this regard.

*** Bug 228129 has been marked as a duplicate of this bug. ***

Created attachment 121137 [details]
new gnome-main-menu rpm

Fixed several memory leaks and checked them into svn trunk and rebuilt rpm. Could you try this one and see if it solves the memory issues.

Depending on your theme you may see a change in the application browser background. Official rollout will also include a new gtkrc

I think a memory leak still exists. Every time you open an application from main-menu memory in system-monitor increases by 0.2 - 0.4MB. Closing the application doesn't lower the memory footprint. I'm not too familiar with memory management so sorry I can't be more of a help.

Other than that the menu is a lot more responsive than before.

Created attachment 121165 [details]
Memory usage of the patched menu

I think some problem is still there:

- The menu takes a lot of time to load.
- It starts using ~8.5MB of RAM and before the button appears it's already at ~30MB.
- After the button appears, the menu doesn't react to the click, and it uses an increasing amount of memory (~40MB after 5 minutes: see attachment) and it's increasing while I write.

I did some experimentation with the proposed patch, and I noticed the behaviour of the menu is very different from what I reported in comment #19 if the applet is loaded at login time.

The memory used by the menu still slightly increases as reported in #18, but a lot less than before (while I write the menu uses ~ 3.8MB).

I tried to reproduce the problems I reported in #19, and I noticed some processes of my user weren't killed when I logout. Maybe this is the cause.

With the patched rpm I get 400mb resident memory used by main-menu after working activly for 6 hours...

Created attachment 121940 [details]
main-menu after being open for a day.

I'm on 10.3 Alpha1Plus.

mboman@mblxws01:~> rpm -qa|grep main-menu
gnome-main-menu-0.6.3-65

I did a little experiment after JPR said that the memory leak is believed to be caused by a big .recently-used.xbel file.

-rw-r--r-- 1 mboman users  2847 2007-03-02 18:18 .recently-used
-rw-r--r-- 1 mboman users 66193 2007-03-03 16:54 .recently-used.xbel

mboman@mblxws01:~/tmp/main-menu> grep "bookmark href" .recently-used.xbel|wc -l
105

Not sure if that considered big or not.

Anyway, so I did an experiment. I performed a few operations both with the above mentioned .recently-used* and then again after deleting the files.
After each operation, I did the following;
mboman@mblxws01:~/tmp/main-menu> ps aux|grep main-menu

I then recorded the VSZ and RSS values and put them in the attached spreadsheet.

It does not seem to make a difference at all. Slab is still leaking the same amount of memory.

Created attachment 122171 [details]
Spreadsheet showing memory usage

Most memory issues seems to have been fixed in gnome-main-menu-0.6.3-66 that's in Factory today.

It still leaks a small amount of memory for each app you start, and also everytime you save something in your home directory. But we are talking bytes, rather then kb/mb.

Will we have an "automatic" update for all users of 10.2 soon ?
I can't install the factory patch version, because lack of Gconf-tool2.

We will do an update once we're convinced that all problems are solved.

Created attachment 123327 [details]
New RPM

version-2 of gnome-main-menu has several fixes and improvements and we have done another round of memory leak checking.  If you could try this new rpm and let me know how it works.

IMPORTANT – after installing you need to restart all the g-m-m processes.  The easiest way to do this is simply reboot.  But you can also do a killall on “main-menu”, “application-browser” and “control-center”.  If you don't get all the main-menu processes restarted after you install the new rpm it will still be using the old library.

Just tried the new RPM, and the results are not positive:

- It takes a lot of time to show the button.
- After showing the button, it takes a lot to show the menu when clicked.
- It freezes often blocking all the activities (nothing responds for some time, only keyboard to switch to text console).

Moreover there are some steps back in the choices done:

- The Hard Drive button doesn't show the resources, but opens Nautilus in /home. 

- More places opens /home. I expected it to open Computer, where all places are shown. Opening /home is just redundant: it's in other two places plus the above one.

Is it really necessary to have 2 (1 in favourite + 1 in places) + 2 (Hard drive + More places) ways to open /home in a menu? I really don't think this improves usability.

Created attachment 123345 [details]
recently-used.xbel

My experience so far:

- I like the look (This is the one in the the sle service pack isn't it?)
- Not sure why the Hard drive icon is even still there since it reports only one of my drives, and generally I could really care less if I have 400 gb free

Sorry, a bit off topic there...  Anyways the menu still does not seem to be freeing memory properly after I launch an application.

Each app launch increases the memory footprint by ~400kb

Overall I find that the speed/reaction time of the menu is much better

After 48h of average desktop usage the memory footprint of the last attached main-menu is 237 Resident and 276 Virtual memory. A new thing is that the bottom part of the Computer and icon are cut off as shown on the attached screenshot. The height of my panel is 24 and this seems not to be theme specific.

Created attachment 123655 [details]
icon and label cut off at the bottom screenshot

I get the following error:

The panel encountered a problem while loading "OAFIID:GNOME_MainMenu".
Do you want to delete the applet from your configuration?

Any idea what the problem could be?

Also deleting .recently-used and .recently-used.xbel causes maxed out cpu for a minute or so.

There is a usability problem with the new version:

The menu grows to to display all Nautilus-bookmarks that are present in the new 'Places' view.

The consequence of this vertical growth for the 'Applications'-view is that it also displays (for me) 10(!) recently-used applications below my favorite applications.

Meaning I have to hover the mouse from the lower left corner of the screen up to the middle in order to reach the favorite apps.

Possible solutions: 
- Menu grows only in the 'Places' view. Would be very useful for the menu to grow only when needed anyway (--> embedded 'more applications')
- Scrollbars
- Put favorit apps at the bottom and recently-usedd at the top
- Put favorit apps at the _left_ side of the menu and recently-used at the right


Some more oddities: 
-The 'logout' enty has vanished from the left system area of the menu
- The 'hard-drive' entry from the status area now links to Nautilus instead of gnome-system-monitor

About comment #36 see: https://bugzilla.novell.com/show_bug.cgi?id=252806

Performance has indeed greatly approved with the new RPM! :)
Memory-leakage also is almost nill. 

My only complaint in this respect is that the menu often doesn't open on first click.

I went back to the main-menu in the openSUSE 10.2 repositories and noticed that memory isn't being leaked when opening applications, but in the two new RPMs posted here every time a new application is open the size of main-menu grows by 400kb as stated in comment #31.

I updated to last rpm and I don't have "Add to favourites" and "Remove ..." in the right click menu in the main-menu and application-browser for programs. I can no longer manage the programs displayed in the menu.

I confirm what reported in comment #40.

Regards

It has been over a month since the last test rpm was released.

Please report on the status for this fix.

The menu (second version) takes quite a lot of time to load after the login, and after some time of use it still leaks a lot of MB.

I have backported the latest main-menu from factory to 10.2. I hope I won't get blamed for that, but I am going to attach the rpms I hacked up together. They are *not* official and come with no warranty. They works fine for me. Hope they fix your troubles with the main-menu too.

Regards.

Created attachment 136243 [details]
new main-menu rpm

Created attachment 136244 [details]
nautilus plugin - right click add to favourites action

Created attachment 136245 [details]
-devel rpm

Created attachment 136246 [details]
-debuginfo rpm

Created attachment 136247 [details]
-src rpm

Thanks ! And can you make the same for x86_64 packages ?

I don't have the hardware for that. I suppose you can do it yourself via
rpmbuild --rebuild --target x86_64 src.rpm

*** Bug 266493 has been marked as a duplicate of this bug. ***

Created attachment 136736 [details]
Menu theme - old and new

In the new rpm, the menu is no longer blue-themed. I'm not sure whether this was intended or not in Factory development. 

This is a screenshot for clarification:

Also the control center lost the sidebar on the left.

However, at least, it seems that the menu is not leaking crazily as the past versions.

According to the changelog the color scheme has changed to match GNOME's better. Also the control-center has been dropped (at least from compilation). I think it would be better if not make this an all-in-one main-menu problems bug, rather stick to the "hanging"/leaks problem here.

Can we get this backport in the update repository, please?

Andreas,

I had submitted an update package which addresses this bug a while ago to autobuild, but it has not been accepted.  I've been told that this is because it does not have a swamp id.  Can you provide me with one?

Thanks,
Jim

Anja,

Please read Comment #56.

Thanks,
Jim

Hi Jim,

the SWAMPID is 9773.
Please be so kind to submit fix and patchinfo file.
thx :-)

This has been submitted to autobuild manually with a SWAMPID and the PATCHINFO was created and submitted with WebSWAMP.  I hope I did everything correctly this time.

Please do not reopen this bug unless you find hangs using openSUSE-10.2 and gnome-main-menu v0.9.7 or above.  The above usability concerns and 10.3 performance problems should be opened in separate individual bugs.

Thanks!
Jim

*** Bug 273576 has been marked as a duplicate of this bug. ***

While using the new menu (the version available in attach to this bug report), main-menu still hang at start, about 30s.

Is the official update available somewhere ?

I'm using OpenSuse 10.2 x86_64

released

Good. The leak seems gone. However after the installation of the patch, beagle went crazy and beagle-helper continuously works using the whole CPU.

There seems to be a relation with the delay in menu loading too and beagle. If you just remove the menu from the panel and add it again, you'll notice that beagle-helper uses 100% of the cpu and the menu button won't appear. Killing beagle-helper makes the button appear.

Regards,
Alberto

Main-menu is now faster to use but always take about 20-30 seconds to start after the others software when booting.

Is there any file to delete to make it faster ?

Accidentally marked as closed

See antecedent

Fixed.