Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; T312461) Description of problem: Following a clean install of RedHat Linux 9, when logging into GNOME as a normal user, metacity starts spinning when a the 'start indexing' button is selected on the kdevelop-setup tool (step 8/9) Version-Release number of selected component (if applicable): metacity-2.4.34-3 How reproducible: Always Steps to Reproduce: 1. login a normal user (fresh install, fresh user, no changes etc) 2. run kdevelop (or kdevelop-setup) 3. at step 8/9, select 'start indexing' (IIRC), to start htdig indexing files 4. lean back as metacity starts spinning, calling syscalls Actual Results: metacity spins, calling syscalls (something like 40% sys time, 60% user time); desktop becomes unresponsive, but mouse cursor still works (ie X is working) Expected Results: no spinning, no desktop stop Additional info: - I did a Personal Desktop install with a few package tweaks (mostly adding packages) - uniproc P4 w/ 512MB memory, on IDE disk - nVidia NV28 GeForce2 4200 graphics hardware
I think the desktop probably feels unresponsive primarily due to all the disk access of the indexing process. The latest kernel errata may help a bit with that. My prediction is that metacity is using CPU because the progress indication of the index app involves changing the app's icon or title or some other thing that results in work for the window manager; not really a bug if so. But we can have a look.
No. There was no indexing taking place. As soon as the 'start indexing' button was pressed, metacity started to spin and the desktop became totally unresponsive, until I killed the session. The spin is a tight loop with syscall(s) and does not do anything useful, so the desktop hangs (ie totally unresponsive). There was *no* time spent in X, so there was no icon updating taking place. This is a bug.
What are the syscalls? How are you tracking that? One way to debug is to run metacity in verbose mode; from the console, DISPLAY=:0 METACITY_VERBOSE=1 METACITY_USE_LOGFILE=1 metacity --replace It prints the logfile name on startup. Hopefully there's a log message on each loop iteration which would make the problem clear.
I get the same problem when trying to run the k3bsetup tool or the CD Bake Oven setup tool. If you cancel out of CD Bake Oven's setup wizard, it locks up and the log (gotten by using the DISPLAY=:0 METACITY_VERBOSE=1 METACITY_USE_LOGFILE=1 metacity --replace mentioned earlier) is 59MB of almost nothing but this: ERRORS: 1 traps ERRORS: 2 traps remain ERRORS: 1 traps ERRORS: 2 traps remain ERRORS: 1 traps ERRORS: 2 traps remain ERRORS: 1 traps ERRORS: 2 traps remain ERRORS: 1 traps ERRORS: 2 traps remain ERRORS: 1 traps ERRORS: 2 traps remain ERRORS: 1 traps ERRORS: 2 traps remain ERRORS: 1 traps ERRORS: 2 traps remain ERRORS: 1 traps ERRORS: 2 traps remain ERRORS: 1 traps ERRORS: 2 traps remain ERRORS: 1 traps ERRORS: 2 traps remain ERRORS: 1 traps the text leading up to these lines is this: SHAPES: Frame 0x2000914 has shaped corners Window manager: Ungrabbing display, grab count now 1 SYNC: 190: Syncing on error_trap_push_with_return, traps = 1 I also found that by doing a 'killall -9 metacity' from a console will allow me to use either of the mentioned programs (tho' obviously w/o a window manager). Are there any patches out there? Both the programs mentioned work 100% flawlessly when running KDE or ANY windowmanager other than metacity. This is quite a nasty bug, IMHO.
Oh, thanks for the additional info. That makes it clear that you're probably seeing same as this stuff: http://bugzilla.gnome.org/show_bug.cgi?id=114828 http://bugzilla.gnome.org/show_bug.cgi?id=108108 http://bugzilla.gnome.org/show_bug.cgi?id=106217 Maybe one of you guys could verify that it's fixed in 2.4.55 in Rawhide.
Not reproducible in Severn with metacity-2.5.3-3. But that doesn't fix the ugly bug in Red Hat Linux 9's metacity version.
RHL9 bugfix updates are pretty rare, unfortunately. Something I hope the new project will change.