desktop freeze when moving emacs in workspace switcher

Thanks for your bug report. Please try to obtain a backtrace of the hang http://wiki.ubuntu.com/DebuggingProgramCrash and attach the file to the bug report. This will greatly help us in tracking down your problem.

do you use the desktop effects option?

i do not use the desktop effects

how to get a backtrace. i installed everything as described on https://wiki.ubuntu.com/DebuggingProgramCrash
and gnome-panel-dbg.

how can i obtain a backtrace of the workspace switcher?

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!.

I also have this bug. But mine also "crashes" when I attempt to resize it. I tried to do a backtrace of the program doing this but it freezes up my x server whenever It happens, so i couldn't run a normal backtrace. What i did was I ran it normally, switched to tty5 and then attached gdb to it. However when i switched back to tty7, the resize happened and it wasn't frozen anymore. When i tried to move it to another workspace, my entire xserver froze again so I switched to another tty and back and it was unfrozen, but it didn't move the the workspace i wanted. I attached what logs there were but i don't know how helpfull it will be. I'de be happy to do something else to get this bug fixed if someone would tell me what to do.

Clarification****

I can maximize and unmaximize emacs fine, but when i try to resize with my mouse it freezes x.
When i unfreeze it, the window is resized how it should be.

Also, I can use my keyboard shortcuts to move emacs to another workspace, but when i try to drag and drop it to another workspace using my mouse it freezes.
when i unfreeze it, the window is in the original workspace, not the workspace it was dragged to.

To unfreeze emacs, all i do is switch to another tty and back.

On a side note, I can have rythmbox playing music and it will continue to play it even though i can't change songs or volume with my keyboard shortcuts.

the issue is not a gnome-panel bug

You're right, i didn't even notice where it said the bug was. I tried searching but I wasn't sure where to put it. Can someone fix it if its wrong?

this bug occurs only with the gtk version of emacs. i have no problem with GNU Emacs 22.1.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2008-05-03 on terranova, modified by Ubuntu.
maybe this is a bug belongs to gtk. but i have an other machine (with different hardware) with the same installation where i have no problems. is it possible that this bug blongs to a special modul of the Xserver?

I have the same problem in my Debian Sid.

It actually does not break anything, it just freeze the X. To unfreeze, I go to a tty or just toggle the "Caps Lock" status =/
It is hard to reproduce this bug and sometimes when I open emacs, it does not happen. All the information I can provide is:

 - It only happens with emacs-gtk
 - tests were made with .emacs file empty
 - emacs was started without comand line arguments
 - emacs/emacs-gtk version: 22.2+2-3
 - gtk version: 2.12.11-3
 - video card: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
 - I'm not using desktop effects (I don't have it installed)

is this perhaps a bug in metacity? Does this also happens with other window managers? can someone please check?

It is quite possibly an infelicity in the way Metacity and Emacs interact. There are not a few of these. GTK-Emacs is not your ordinary GTK application, since it has the Emacs event loop and GTK's event loop and possibly a few other things running at once.

I don't know whether it happens in other window managers, and if anyone feels like checking they should go ahead, but anyone who can reproduce the bug in Metacity should turn on logging as described at http://blogs.gnome.org/metacity/2008/03/07/logging/ , reproduce the bug, restart Metacity, and then attach the log here (or mail it to me or someone else who knows Metacity's guts) for analysis.

I've attached the debug file generated by metacity, I also tested emacs with openbox window manager and the problem didn't happen, so I think you're right. I had no time to read carrefuly the log generated by metacity, but I'll try to find some util info in that file and maybe any other information in my environment.

Bug confirmed. Until the problem is solved I've changed to X11.

https://bugs.launchpad.net/ubuntu/+source/emacs22/+bug/183245

I have the same problem. For me, it appeared when I upgraded Ubuntu to 8.10 about a week ago. I can move the window using the mouse. I can change focus using the mouse. I cannot resize the window, nor change focus using alt-TAB. If I do, the desktop freezes. After a while, it unfreezes. If desktop effects are used, there is no problem with Emacs, only when they are not used. No problem in KDE. (maybe because use desktop effects there, I don't know if I do). The ctrl-alt-F2, alt-F7 workaround works for me too.

The problem seems to be related to the user account. I created a separate test account on my laptop in order to test this bug. No problems on that account. My emacs is GNU Emacs 22.2.1 (i486-pc-linux-gnu, GTK+ Version 2.14.1)
 of 2008-09-05 on vernadsky, modified by Ubuntu. The package is emacs22-gtk version 22.2-0ubuntu2.

Same problem.
FYI it is working in Arch linux with emacs 22.3.1 and metacity 2.24.0. I have the same problem with the emacs-snapshot version.

Same here, ubuntu 8.04 Hp Pavilion dv 1000. ALT-TAB freeze X. To solve: CTR-ALT F1 and CTR-ALT F7.
It is noted that i installed xubuntu-desktop package, switched to an xfce session (it's still gtk) and there emacs doesn't hang. I tried again in gnome, but freeze.

Same here.

Actually, I think the same problem happens also when the effects of Compiz are on, but the period of freeze is much shorter.

Tried using another account and the problem did not happen. Seems to be a specific configuration of this one, but I am not sure.

I confirm what philipp said about the X version of Emacs. The freeze apparently happens with the GTK+ version, not the X one.

After working with some programs that needs the accessibility, I'm sure that this bug happens only when "Assistive Technologies" are enabled.

Lincoln: can you be a little bit more specific? If you disable the AT stuff in the Session manager, does that cause the problem to go away?

(System -> Preferences -> Sessions -> Startup Programs tab -- the ones which seem relevant are the AT-SPI Registry Wrapper [no idea what it does, but AT-SPI is the accessibility voodoo], and Visual Assistance. I would place my bets on the first one.)

I can confirm this. If I go to
System -> Preferences -> Assistive technologies
and uncheck the "Enabe assistive technologies" button, My Emacs (snapshot-gtk) starts to behave fine.

The window switch is still perceptibly slower than for other apps though.

I came across this issue on Ubuntu 8.10 (Intrepid Ibex) and reported it here

https://bugs.launchpad.net/ubuntu/+source/emacs22/+bug/299019

Hi!

I can confirm this bug on my system (Ubuntu 8.10 intrepid). Until now I always thought that Firefox was the "culprit", as it often froze when I switched from Emacs GTK to Firefox.

The interesting part is that this bug has so far *never* occurred during a switch from Emacs GTK to Konqueror, but very often during a switch from Emacs GTK to Firefox.

I'll try switching off "assistive technologies" and report back when I know whether it helped.

Hope I could help,

Martin

Are any of you using Xinerama with multiple monitors? There is a known
X.org bug (with a patch recently made available) with Xinerama that
makes the mouse and/or keyboard seem unresponsive just after using
Alt+TAB to raise a different application.

--
| Michael Olson | FSF Associate Member #652 |
| http://mwolson.org/ | Hobbies: Lisp, HCoop |
| Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner |
`-------------------------------------------------------'

I have the same problem:

  Ubuntu: 8.10
  Emacs: emacs22-gtk 22.2-0ubuntu2
  Metacity: 1:2.24.0-0ubuntu1
  Dual Monitors
  Assistive Technologies enabled

Symptoms:

  Cursor turns to window resize pointer and stays that way. Mouse will move around on the current screen but will not move to second screen and clicks do nothing. Switching to text terminal and back "fixes" the problem. Pressing Caps lock sometimes turns the direction of the resize pointer and eventually frees up the mouse.

Note also that the window does not actually resize until the mouse is released then it moves to wherever the mouse is at the time.

This happens at random but is pretty easy to reproduce by making attempts to resize gtk-emacs screen.

This may not be related but I also have a bug where gnome-panel crashes when I try to use a launch button on the second display. The gnome-panel used to lock up and use 100% CPU until I enabled assisitive technologies now it crashes and restarts instead. Since both problems involve metacity and assisitive technologies it could be related.

Hi!

As I said, I switched off "assistive technologies" - and from then on, everything ran smoothly. No more freezes, and even better, my X server has stopped crashing (it crashed about once per week). Thanks everybody!

Martin

Hello!
I got ubuntu jaunty (uname -a : Linux 2.6.28-8-generic #28-Ubuntu SMP Thu Mar 5 21:49:36 UTC 2009 i686 GNU/Linux)
emacs-22-gtk hangs metacity and X except for the cursor when trying to switch the windows by ALT+TAB or when resizing the emacs window. Just by switching to one of the virtual console/X servers metacity and X session wake up.

I have no 3d/compiz stuff now because of my video driver problem (damn ATI)
However in intrepid I did have compiz and remember the same problem with gtk+cpmpiz/metacity. It was not that bad though. Somehow , it did not happen all the time and after switching to tty's the problem was gone.

Tried turning off assistive technologies - to no avail so far

Yes, I can confirm that turning off "assistive technologies" fixed it. One has to log off and in though
Thanks, guys

How many more "nice" features like that one are there in Ubuntu turned on by default?

I can confirm that this occurs in Compiz, too. Switching to Compiz to fix what appeared to be a system-wide bug seemed to work, but then it cropped up again. Whoops.

Have disabled assistive technologies and seem to be going fine now.

Local situation: have dual-head (using nvidia glue instead of xinerama), with an emacs window open full-time with "always on visible workspace" enabled. Frequently have other emacs windows open as well.

Using emacs 22.2.1 GTK+ 2.14.1, started experiencing freezes when changing between workspaces, alt-tabbing between windows, or resizing (or title-bar-right-clicking) emacs, starting after upgrading to 8.10. System would sometimes reawaken after (a) three-eight seconds, (b) hitting numlock, or (c) ctrl-alt-F1 ctrl-alt-F7.

System was running fine for the duration: system monitor was ticking over (and not showing any additional load), remote ssh was fine, mouse was still active (though stuck on its last image). Would often come back with the alt key wedged down (according to emacs, at least) and needing to be tapped to bring the keyboard back to normal. (Have seen reports that caps lock has been left on. May be significant that I have ctrl and caps swapped.)

Nothing at all in any logs.

Suspected hardware, swapped a -lot- around before discovering that using Compiz (single-head) instead of Metacity (dual-head) seemed to have fixed it. Then went dual-head again, turned always-on-visible-workspace back on, and hit death. Realised that emacs seemed to be the common factor, found this thread, disabled assistive technologies, and voila.

Other data points: emacs22-x is fine, emacs-snapshot (23.0.60.1 GTK+ 2.14.3) is fine.

Thomas Thurman could well be on the money that the emacs event loop is throwing GTK for a spin. AT is obviously also monitoring events; is there perhaps a race condition between emacs22 and at-spi?

(have reconsidered blaming Compiz, so sorry for the mail traffic. this appears to be a duplicate of 287577; any objections to marking it so and adding at-spi to the packages?)

Maybe a duplicate of bug 287577 ?

Happens to me after updating from intrepid to jaunty. I'm on a thinkpad with intel 965GM chipset. The upgrade turned off "visual effects". When the bug is happening as soon as the focus is on emacs, clicking anywhere else hangs the desktop (can't change focus, can't click on things). Waiting a long enough usually releases the lock. switching to a VT and back does too. "Assistive Technologies" was on. I've turned it off (but it looks like I need to logout for the change to take effect).

Cannot replicate bug after turning off "assistive technologies".