Bug 91492 - Metacity spins, hanging desktop...
Summary: Metacity spins, hanging desktop...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: metacity
Version: 9
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: Havoc Pennington
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-05-23 08:42 UTC by Daniel J Blueman
Modified: 2007-04-18 16:53 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2003-09-21 16:15:00 UTC
Embargoed:


Attachments (Terms of Use)

Description Daniel J Blueman 2003-05-23 08:42:54 UTC
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

Comment 1 Havoc Pennington 2003-05-30 04:09:33 UTC
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.

Comment 2 Daniel J Blueman 2003-05-30 07:52:36 UTC
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.

Comment 3 Havoc Pennington 2003-05-30 14:39:43 UTC
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.

Comment 4 gLaNDix 2003-06-12 21:33:26 UTC
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.

Comment 5 Havoc Pennington 2003-06-12 21:44:05 UTC
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.

Comment 6 Michael Schwendt 2003-09-21 00:28:29 UTC
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.


Comment 7 Havoc Pennington 2003-09-21 16:15:00 UTC
RHL9 bugfix updates are pretty rare, unfortunately. Something I hope the new 
project will change.


Note You need to log in before you can comment on or make changes to this bug.