After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 337868 - Minimizing windows causes havoc, but to certains apps only
Minimizing windows causes havoc, but to certains apps only
Status: RESOLVED FIXED
Product: metacity
Classification: Other
Component: general
2.14.x
Other All
: High critical
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
: 337869 337870 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-04-09 23:08 UTC by cruiseoveride
Modified: 2006-04-13 04:11 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14



Description cruiseoveride 2006-04-09 23:08:50 UTC
Please describe the problem:
This was not a problem with 2.12x
I am running two screens, as seperate desktops.
When trying to minimize a window, from either screen, metacity looses control of
all window borders and desktops, bringing all applications together in one
desktop, for a few seconds, then returns control to apps, without minimizing the
original app.
This happens while trying to minimize kde apps, xmms, valknut,
This does not happen to gaim, evolution, nautilus etc...

Steps to reproduce:
1. Open xmms for example.
2. Click minimize button on xmms
3. BAM, all windows flash together on one screen, without any borders, then
returns back to normal in a few seconds.


Actual results:


Expected results:


Does this happen every time?
Yes

Other information:
 rpm -q xmms
xmms-1.2.10-22.fc5
 cat /etc/redhat-release
Fedora Core release 5 (Bordeaux)
NOTE; This is not an issue with gnome-2.12x
Comment 1 Elijah Newren 2006-04-09 23:25:15 UTC
*** Bug 337869 has been marked as a duplicate of this bug. ***
Comment 2 Elijah Newren 2006-04-09 23:34:52 UTC
Sounds like you're triggering a metacity crash somehow (gnome-session automatically restarts metacity when it detects it crashing, thus the reason it recovers).  Can you get us a stack trace with debugging symbols (or, assuming I can get my dual-screen machine fixed, provide exact steps to duplicate)?
Comment 3 cruiseoveride 2006-04-09 23:58:25 UTC
how do i produce a stack trace for metacity, wont i need to run it manually, but gnome runs it when it starts up? If u can give me the steps on how to get the strace, then i will gladly oblidge.
Comment 4 Elijah Newren 2006-04-10 00:19:46 UTC
To prevent confusion, I do *not* want an strace (which is the name of a command that provides a system trace).  I want a stack trace, which is also known as a backtrace.

First, install the metacity debuginfo package (more directions at http://live.gnome.org/GettingTraces/DistroSpecificInstructions).  That's the easier half.

The second half is a bit harder because metacity is a special case.  There's two basic alternatives:

Method 1 (what I usually do):
  1) ssh in from another remote machine (e.g. a laptop)
  2) run 'ps -ef | grep metacity' to find the PID (process ID) of Metacity (it's the number in the second column; your username should be in the first column)
  3) run 'gdb /usr/bin/metacity <PID>' where <PID> is the number from step 2
  4) type 'cont' at the '(gdb)' prompt
  5) Go back to the dual-screen system and make it crash
  6) Go back to the remote machine and run 'bt' at the '(gdb)' prompt.

  Note: After getting the backtrace, you can type "quit" at the gdb prompt to
  get out.  If for some reason metacity isn't restarted by gnome-session, just
  use ctrl-alt-backspace to kill the graphical session and start a new one)

Method 2: This is basically the same as method 1, you just use a virtual terminal instead of ssh'ing in remotely.  You can use Ctrl+Alt+F1 to get to a virtual terminal (and use Ctrl+Alt+F7 to switch back).

Note: I wouldn't suggest running gdb from a terminal that is being managed by metacity; it's usually a bad idea though it may work if you're lucky.


Now, if the second half sounds too scary, let me know because there is an easier alternative for gathering info -- it's just that the alternative provides information that isn't quite as useful as well as being overly verbose.
Comment 5 cruiseoveride 2006-04-10 00:42:23 UTC
Due to another bug issue with gnome i cannot switch to tty1 (Ctrl+Alt+F1), my only method of doing this is to use ssh from another machine. i will get the trace and post back as soon as i can.
Comment 6 Luca Cavalli 2006-04-10 08:40:19 UTC
*** Bug 337870 has been marked as a duplicate of this bug. ***
Comment 7 cruiseoveride 2006-04-10 15:09:43 UTC
Sorry about the duplicates, i think, when i refresh firefox, it creates duplicated entries.
Comment 8 Elijah Newren 2006-04-11 02:27:10 UTC
Might be the same crash found in bug 337954 since this is a minimization problem and it's on the same distro (and thus has the same patch applied)...
Comment 9 Ray Strode [halfline] 2006-04-11 03:02:24 UTC
Hi,

I've pushed updated metacity packages into FC5 updates-testing with a fix for the problem mentioned in bug 337954.  Can you try them and report whether the problem is still present?

If not, then that probably confirms the theory in comment 8.
Comment 10 cruiseoveride 2006-04-11 16:40:18 UTC
after updating metacity from the fedora-updates-testing tree 
metacity-2.14.0-1.fc5.1
xmms is playing nice, but valknut is causing a lot of disturbance to metacity, not killing it though this time. the gnome panel disappears when i minimize valknut, and all my gdesklets disappear, this could be an application specific problem though, let me try some other kde apps. but its looking good so far.
Comment 11 Elijah Newren 2006-04-13 02:47:52 UTC
cruiseoveride: Find out anything useful?  Were you able to duplicate any crashes?  Or get any problems with any app other than valknut?
Comment 12 cruiseoveride 2006-04-13 04:11:45 UTC
after the update everything looks good, i think the version of valknut i have has some issues, but otherwise metacity is working well! Great job people!