Bug 224611 - emacs window practically not resizable
emacs window practically not resizable
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: emacs (Show other bugs)
11
All Linux
high Severity medium
: ---
: ---
Assigned To: Daniel Novotny
:
: 229137 431050 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-26 12:57 EST by Michal Jaegermann
Modified: 2010-06-07 20:06 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-01 10:39:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
File ~/.emacs from a test account (238 bytes, text/plain)
2007-01-26 18:25 EST, Michal Jaegermann
no flags Details
All files from /usr/share/emacs/site-lisp/site-start.d (10.00 KB, application/x-gzip)
2007-01-26 18:27 EST, Michal Jaegermann
no flags Details
"selective" strace from emacs run on a local display (1.33 KB, text/plain)
2007-01-30 13:44 EST, Michal Jaegermann
no flags Details
"selective" strace from emas after 'ssh -C2X localhost' (2.60 KB, text/plain)
2007-01-30 13:46 EST, Michal Jaegermann
no flags Details
a pmap output for emacs on rawhide (13.13 KB, text/plain)
2007-02-01 14:55 EST, Michal Jaegermann
no flags Details
an output from pmap for the same emacs version but on FC6 (10.11 KB, text/plain)
2007-02-01 18:47 EST, Michal Jaegermann
no flags Details
strace from emacs with its window "locked" - rt_sigprocmask filtered out (442.32 KB, text/plain)
2007-02-01 20:42 EST, Michal Jaegermann
no flags Details
output of strace -o emacs-strace.txt -f -F emacs (158.14 KB, text/plain)
2007-03-06 17:42 EST, Matěj Cepl
no flags Details
output of ltrace -r -o emacs-strace2.txt -f /usr/bin/emacs-22.0.93-x (777.82 KB, application/x-bzip)
2007-03-06 17:48 EST, Matěj Cepl
no flags Details
output of strace with -c (5.03 KB, text/plain)
2007-03-06 17:50 EST, Matěj Cepl
no flags Details
summary of ltrace (18.42 KB, text/plain)
2007-03-06 17:51 EST, Matěj Cepl
no flags Details

  None (edit)
Description Michal Jaegermann 2007-01-26 12:57:01 EST
Description of problem:

With new emacs-22 an attempt to resize a freshly opened window in
gnome-session, say by pulling on a side frame, results in a cursor
which changes its shape to "<->", or a vertical equivalent, and going
away for a long while.  This locks an access to anything else on
a desktop as a cursor is "busy".  After a long timeout all of sudden
a "pulled" edge jumps to some position, which is hard to predict,
and a normal operation is back.  On other occasions after a few
minute wait I got out of predicament by logging remotely and killing
emacs - which again solved the immediate trouble.  If I do not try
to manipulate emacs window then everything seems to be just fine.

To makes things more interesting while I got a behaviour described
above on all accounts using metacity this was not the same on an
account using sawfish (compiled properly for "rawhide") as
a window manager.  There after many resizes in various directions
I eventually hit a state when the next resize attempt got a very
lengthy, possibly interminate, timeout but on the next few tries
I was unable to repeat that again.  OTOH with metacity the first
resize attempt is already "jinxed".  Resizing windows other than
emacs I do not recall ever observing that problem.

No idea if the fact that my test system is x86_64 is relevant here.
I did not try window managers other than metacity and sawfish.
Changing things like an initial geometry, background and foreground
colours, does not influence the issue.

Version-Release number of selected component (if applicable):
emacs-22.0.93-3.fc7

How reproducible:
See above.
Comment 1 Michal Jaegermann 2007-01-26 13:11:10 EST
Just after I wrote the above I went into an account using sawfish, started
emacs and tried to resize its window while "splash screen" was still
displaying.  This had an effect of deselecting an emacs window and,
although a cursor looked normal, _nothing_ else was selectable.
A content of splash was changing from time to time very slowly.
After a longish while that splash went away and an emacs window got
itself into a "selected" state.  From that moment on everything looked
normal and I could resize that window at will, or at least I did not
managed to get into a funk even when I tried, and other things were
operational as well.

BTW - I did try under metacity to resize only when there was no more
emacs splash.  It did not make the slightest difference.
Comment 2 Chip Coldwell 2007-01-26 13:44:27 EST
Not reproduced on FC-5 nor FC-6.  
Comment 3 Michal Jaegermann 2007-01-26 14:03:49 EST
> Not reproduced on FC-5 nor FC-6.

Indeed, but FC-5 and FC6 are using emacs-21.  The problems was also
absent in rawhide before emacs-22 showed up there.  Or you mean
that emacs-22 recompiled on FC6 allows window resizing without
any surprises?

What is more - opening emacs-22 from rawhide window on a remote, even
if a remote is FC5 using metacity for a window manager, does not seem
to exhibit any troubles with resizing that window.  The issue appears
to be "a local metacity property" although I managed to perform a
difficult feat and hit it once with a sawfish on rawhide too.
Comment 4 Chip Coldwell 2007-01-26 14:14:41 EST
(In reply to comment #3)
> > Not reproduced on FC-5 nor FC-6.
> 
> Indeed, but FC-5 and FC6 are using emacs-21.  The problems was also
> absent in rawhide before emacs-22 showed up there.  Or you mean
> that emacs-22 recompiled on FC6 allows window resizing without
> any surprises?

Yes, that's what I meant.  If you have an FC-5/6 box set up, you can try it
yourself; there's a repo at

http://people.redhat.com/coldwell/emacs/fedora/

I don't have a rawhide box handy at the moment (I'll set one up if necessary),
so I tried FC-5/6 first.

Chip

Comment 5 Chip Coldwell 2007-01-26 15:59:58 EST
Date: Fri, 26 Jan 2007 15:32:31 -0500
From: Jeremy Katz <katzj@redhat.com>
To: Chip Coldwell <coldwell@redhat.com>
Subject: Re: rawhide/emacs bug

On Fri, 2007-01-26 at 13:47 -0500, Chip Coldwell wrote:
> If you have an FC-7 test1 box handy, could you throw up an emacs and
> try to resize the window just to verify BZ#224611 quickly?  I want to
> make sure this guy's not got a local problem before I set up an FC-7
> box.

Doesn't happen on my x86_64 workstation in a quick check.  Not 100%
current, but updated emacs before trying it

Jeremy
Comment 6 Chip Coldwell 2007-01-26 16:11:29 EST
I built an emacs-22 package --without-gtk that you can get from

http://people.redhat.com/coldwell/bugs/emacs/224611/

try that and let me know if the problem persists (I'm not proposing this as a
solution, just a test case).

Also, please attach your .emacs file and any site-start.d/*.el.

Chip
Comment 7 Michal Jaegermann 2007-01-26 18:26:00 EST
Created attachment 146732 [details]
File ~/.emacs from a test account

Well, the only non-commented line in ~/.emacs on a test account is
(global-font-lock-mode t)
I am attaching it anyway. :-)

In site-start.d I have at this moment the following packages
(trimmed some stuff but this had no influence on the issue):
focus-init.el
igrep-init.el
php-mode-init.el
po-mode-init.el
python-mode-init.el
rpm-spec-mode-init.el
gnuplot-init.el
psgml-init.el
w3m-init.el
ruby-mode-init.el

Those belong respectively to:
emacs-common-22.0.93-3.fc7
gnuplot-emacs-4.0.0-16.fc7
emacs-common-22.0.93-3.fc7
emacs-common-22.0.93-3.fc7
emacs-common-22.0.93-3.fc7
psgml-1.2.5-5.fc7
emacs-common-22.0.93-3.fc7
emacs-common-22.0.93-3.fc7
ruby-mode-1.8.5.2-1.fc7
w3m-el-1.4.4-6.fc7

Just for a reference I will attach those too.  I will get that
'--without-gtk' package as the next step.

This test installation is basically "vanilla", no x86 packages
at all, updated to the current rawhide and none of rawhide supplied
packages is modified in any way.  'package-cleanup --problems' for
today reports:

Missing dependencies:
Package 4Suite requires python(abi) = 2.4
Package 4Suite requires python-abi = 2.4

'4Suite' comes from extras and in principle could be deinstalled but
it is not really used by anything.  This is a full report.
Comment 8 Michal Jaegermann 2007-01-26 18:27:34 EST
Created attachment 146733 [details]
All files from /usr/share/emacs/site-lisp/site-start.d
Comment 9 Michal Jaegermann 2007-01-26 18:30:35 EST
Attaching strace to emacs after a window resize was attempted produces
a constant stream of messages which look in this way:
...........
select(5, [4], NULL, NULL, {0, 493000}) = 0 (Timeout)
write(4, ";\0\5\0T\1\0\4\0\0\0\0\37\0004\0h\2\r\0L\1\5\0\203\0\0"..., 56) = 56
select(5, [4], NULL, NULL, {0, 498464}) = 0 (Timeout)
write(4, ";\0\5\0\224\0\0\4\0\0\0\0\37\0004\0\7\0\r\0L\1\5\0\203"..., 56) = 56
select(5, [4], NULL, NULL, {0, 499683}) = 0 (Timeout)
write(4, ";\0\5\0T\1\0\4\0\0\0\0\37\0004\0h\2\r\0L\1\5\0\203\0\0"..., 56) = 56
select(5, [4], NULL, NULL, {0, 499705}) = 0 (Timeout)
write(4, ";\0\5\0\224\0\0\4\0\0\0\0\37\0004\0\7\0\r\0L\1\5\0\203"..., 56) = 56
select(5, [4], NULL, NULL, {0, 499763}) = 0 (Timeout)
write(4, ";\0\5\0T\1\0\4\0\0\0\0\37\0004\0h\2\r\0L\1\5\0\203\0\0"..., 56) = 56
select(5, [4], NULL, NULL, {0, 499673}) = 0 (Timeout)
select(5, [4], NULL, NULL, {0, 10})     = 0 (Timeout)
write(4, ";\0\5\0\224\0\0\4\0\0\0\0\37\0004\0\7\0\r\0L\1\5\0\203"..., 56) = 56
select(5, [4], NULL, NULL, {0, 498731}) = 0 (Timeout)
select(5, [4], NULL, NULL, {0, 54})     = 0 (Timeout)
...........
Comment 10 Michal Jaegermann 2007-01-26 19:07:55 EST
I installed emacs-22.0.93-5.1.fc7 and emacs-common-22.0.93-5.1.fc7,
those without Gtk, and not a whiff of a problem.  I can resize
emacs windows until cows come home and a response is immediate and
interactive.

BTW - even compiled that way emacs-22 does not seem to be able to
respond to 'editres' requests anymore and what worked from "always",
i.e. this resource setting:
.emacs.pane.menubar.font: -bitstream-*-bold-r-*-*-*-120-100-100-*-*-*-*
or its variants, is not accepted anymore.  This makes fonts on
menus, ahem, underwhelming and absolutely unacceptable for my wife
with a so-so sight.  That would be a bit less of a problem if I would
not bump into the issue described in this report; although I would
strongly prefer to have some way to set bigger fonts on emacs menus
than menu bar fonts for everything else.  Up to now this was doable.

Yes, that bitstream font I tried is available.
    xfd -fn '-bitstream-*-bold-r-*-*-*-120-100-100-*-*-*-*'
has no problems to show it.  Used to work very nicely on emacs menus.
 
Comment 11 dann 2007-01-27 03:39:54 EST
(In reply to comment #10)
> BTW - even compiled that way emacs-22 does not seem to be able to
> respond to 'editres' requests anymore and what worked from "always",
> i.e. this resource setting:
> .emacs.pane.menubar.font: -bitstream-*-bold-r-*-*-*-120-100-100-*-*-*-*
> or its variants, is not accepted anymore.  

Are you sure you tried this with an emacs compiled without gtk support?
It works just fine for me in that case. 
emacs-22 in rawhide is compiled with gtk, so the above should not be expected to
work. 

I am not sure what is the gtk way to set font sizes, but you can try that...
Comment 12 dann 2007-01-27 03:43:52 EST
(In reply to comment #10)
> I installed emacs-22.0.93-5.1.fc7 and emacs-common-22.0.93-5.1.fc7,
> those without Gtk, and not a whiff of a problem.  I can resize
> emacs windows until cows come home and a response is immediate and
> interactive.

Can you reproduce the problem when running 
 emacs -Q
?
Comment 13 Michal Jaegermann 2007-01-27 12:53:03 EST
Re comment #11: this was emacs from location given in a comment #6.
It says there "--without-gtk" and it surely looks different than
what was the last time in rawhide repositories.  Are you sure that
you are running emacs-22?  That was not the issue with emacs-21.
Comment 14 dann 2007-01-27 13:49:25 EST
(In reply to comment #13)
> Re comment #11: this was emacs from location given in a comment #6.
> It says there "--without-gtk" and it surely looks different than
> what was the last time in rawhide repositories.  Are you sure that
> you are running emacs-22?  
I am quite sure as I don't have it installed.
What is the output of
M-x emacs-version RET 
for you? 
It's: GNU Emacs 22.0.93.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) 
for me. 

How about using -Q? Have you reproduced your resizing problem using emacs -Q? 
Comment 15 Michal Jaegermann 2007-01-27 15:17:53 EST
> Can you reproduce the problem when running 
>  emacs -Q

Good point.  Yes, I can reproduce with it right away. I put back
emacs-22.0.93-3.fc7 and later updated to emacs-22.0.93-5.fc7 from
today updates.  What I described is still there.

What I noticed is that attaching strace to an emacs process which
attempts to resize a window may often, although not always, make
that window "resizable".  If that happens then as long as I will
leave strace attached I can make this window bigger or smaller
more or less smoothly - as expected.  The moment I detach strace
I am back to a square one.

> What is the output of 'M-x emacs-version RET' for you?

This is what shows up on a splash screen:
 
GNU Emacs 22.0.93.1 (x86_64-redhat-linux-gnu, GTK+ Version 2.10.9)
 of 2007-01-26 on hs20-bc2-4.build.redhat.com
Copyright (C) 2007 Free Software Foundation, Inc.

and the same, without "Copyright" line, after the command above. 
Clearly not the same as yours "X toolkit, Xaw3d scroll bars". 
In  "--without-gtk" configuration I did not have problems with
window resizing either.
Comment 16 dann 2007-01-27 16:03:19 EST
(In reply to comment #15)
> > Can you reproduce the problem when running 
> >  emacs -Q
> 
> Good point.  Yes, I can reproduce with it right away. I put back
> emacs-22.0.93-3.fc7 and later updated to emacs-22.0.93-5.fc7 from
> today updates.  What I described is still there.

Can you try another window manager (i.e. not metcity/sawfish)? 

> What I noticed is that attaching strace to an emacs process which
> attempts to resize a window may often, although not always, make
> that window "resizable".  If that happens then as long as I will
> leave strace attached I can make this window bigger or smaller
> more or less smoothly - as expected.  The moment I detach strace
> I am back to a square one.
> 
> > What is the output of 'M-x emacs-version RET' for you?
> 
> This is what shows up on a splash screen:
>  
> GNU Emacs 22.0.93.1 (x86_64-redhat-linux-gnu, GTK+ Version 2.10.9)
>  of 2007-01-26 on hs20-bc2-4.build.redhat.com
> Copyright (C) 2007 Free Software Foundation, Inc.
> 
> and the same, without "Copyright" line, after the command above. 
> Clearly not the same as yours "X toolkit, Xaw3d scroll bars". 
> In  "--without-gtk" configuration I did not have problems with
> window resizing either.

OK, so in this configuration you should not expect to be able to change the menu
font font size by setting X11 resources. You should use the Gtk resources. You
can find out how to do that that by typing:

C-h i m emacs RET m gtk RET
Comment 17 Michal Jaegermann 2007-01-27 23:15:43 EST
> Can you try another window manager (i.e. not metcity/sawfish)? 

Not really.  I do not have any other one save compiz but compiz
does not work for me.  All windows come without frames and all
new ones are located in 0x0 position.

> OK, so in this configuration you should not expect to be able
> to change the menu font font size by setting X11 resources.

Yes, indeed; but in comment #10 I was talking about
emacs-22.0.93-5.1.fc7 which, as it was mentioned few times already,
was compiled "--without-gtk".

Thanks for mentionting that emacs-22 has new facilities for handling
GTK resources.  I did not get as far as reading new manuals yet.
Comment 18 dann 2007-01-28 01:54:44 EST
(In reply to comment #17)

> > OK, so in this configuration you should not expect to be able
> > to change the menu font font size by setting X11 resources.
> 
> Yes, indeed; but in comment #10 I was talking about
> emacs-22.0.93-5.1.fc7 which, as it was mentioned few times already,
> was compiled "--without-gtk".

I am confused. I am not sure which version are you talking about. 
For the emacs compiled without gtk you should be able to change the menu font
using X11 resources. Does that work for you? 
The result of M-x emacs-version that you show in comment #15 clearly shows that
it is compiled with gtk, so X11 resources should not work for that one...

> Thanks for mentionting that emacs-22 has new facilities for handling
> GTK resources.  I did not get as far as reading new manuals yet.

You're welcome.
Comment 19 Michal Jaegermann 2007-01-28 12:10:17 EST
> I am confused. I am not sure which version are you talking about.

Versions are marked as needed.  In comment #6 I was explicitely asked
to try a version build "--without-gtk" and if I write "I installed
emacs-22.0.93-5.1.fc7 and emacs-common-22.0.93-5.1.fc7, those
without Gtk ...." then in that particular comment I mean just that.
I was relating, in a response, results of that particular try.

OTOH when we are talking about the problem of widows resizing,
and I write things like "... emacs-22.0.93-3.fc7 and later updated
to emacs-22.0.93-5.fc7" then these are clearly versions from
rawhide repositories, where emacs reports "GTK+ Version" with which
it was compiled.  There is no "X toolkit, Xaw3d scroll bars" there.
The later is how emacs was configured at least in FC5 and in FC6 and
I never heard about window resizing issues in those.

> For the emacs compiled without gtk you should be able to change
> the menu font using X11 resources.

This was a side issue here and it appears that I should not mention
that at all.  That most likely depends on compile configuration
options.  When I was trying a version from a location as given
in comment #6 then, as I wrote, font changes via X11 resources
did not work (although window resizing did).

> The result of M-x emacs-version that you show in comment #15

Sigh!  I started that comment with:
"I put back emacs-22.0.93-3.fc7 and later updated to emacs-22.0.93-5.fc7".
These are from "official rawhide" and are indeed compiled with
gtk.  That is what we are trying to test here.  Right?
Comment 20 dann 2007-01-29 02:18:48 EST
(In reply to comment #19)
> > I am confused. I am not sure which version are you talking about.
> 
> Versions are marked as needed.  In comment #6 I was explicitely asked
> to try a version build "--without-gtk" and if I write "I installed
> emacs-22.0.93-5.1.fc7 and emacs-common-22.0.93-5.1.fc7, those
> without Gtk ...." then in that particular comment I mean just that.
> I was relating, in a response, results of that particular try.

OK, let's try to disentangle the information here. 
You have talked about 2 problems in this bug report: 
1. not being able to resize emacs
2. not being able to set the menu font using X11 resources

I am unable to reproduce either of them on any of my machines, but I don't have
access to a rawhide machine.

1. seems to happen with the Gtk version when using either metacity or sawfish. 
Do you have twm installed? It's usually installed by default in Fedora. It would
be interesting to see if you could reproduce it with another window manager...
(the package is xorg-x11-twm and it's tiny)

2. In comment #10 you state that it was happening with the non-gtk version of
emacs. That would be a bug. I asked for M-x emacs-version output to make sure
that it was indeed a non-gtk version. Are you positive that what you saw was
with the non-gtk version? 




> OTOH when we are talking about the problem of widows resizing,
> and I write things like "... emacs-22.0.93-3.fc7 and later updated
> to emacs-22.0.93-5.fc7" then these are clearly versions from
> rawhide repositories, where emacs reports "GTK+ Version" with which
> it was compiled.  There is no "X toolkit, Xaw3d scroll bars" there.
> The later is how emacs was configured at least in FC5 and in FC6 and
> I never heard about window resizing issues in those.
> 
> > For the emacs compiled without gtk you should be able to change
> > the menu font using X11 resources.
> 
> This was a side issue here and it appears that I should not mention
> that at all.  That most likely depends on compile configuration
> options.  When I was trying a version from a location as given
> in comment #6 then, as I wrote, font changes via X11 resources
> did not work (although window resizing did).
> 
> > The result of M-x emacs-version that you show in comment #15
> 
> Sigh!  I started that comment with:
> "I put back emacs-22.0.93-3.fc7 and later updated to emacs-22.0.93-5.fc7".
> These are from "official rawhide" and are indeed compiled with
> gtk.  That is what we are trying to test here.  Right?

Comment 21 Michal Jaegermann 2007-01-29 12:19:14 EST
> You have talked about 2 problems in this bug report:

Please look at the subject and the report itself.  There is only
one bug mentioned there.
 
> 1. not being able to resize emacs

That is correct.  Let's make it more specific.  We are talking
about an _interactive_ resizing with a mouse.  If I will specify
in advance some particular window geometry then emacs opens a window
of that size. 

> 2. not being able to set the menu font using X11 resources

No, not really.  This was an aside remark made in one of comments
about a particular version with some specific compile configuration
I happened to try in the test.  In a retrospect it was an error even
to mention that as this turned out to be a distraction and a source
of confusion (although I learned from that that emacs-22 has
specific facilities for handling gtk widgets, which is good to know).

> 1. seems to happen with the Gtk version when using either metacity or sawfish.

Again!  There are NO TROUBLES with resizing, on the same machine
hence with the same Gtk, when I am using _sawfish_.  This seem to be
metacity specific.  Particular versions involded heare are:
metacity-2.17.5-1.fc7
gtk2-2.10.9-1.fc7

> Do you have twm installed?

Yes, indeed.  I used twm last time so long time ago that I completely
forgot about it.  Under twm I can resize emacs window, or any other
window without any impediments (well, to a make a window narrower you
have to make it first a bit wider and then pull the right edge to the
left - but this seems to be a twm quirk which works the same with
_any_ window; not really a big hoopla).


> 2. In comment #10 you state that it was happening with the non-gtk
> version of.

Really?  Where?  Lets have a look what I wrote there: "... and not
a whiff of a problem.  I can resize emacs windows until cows come
home and a response is immediate and interactive".

In other words with a non-gtk version, and metacity, there is no
issue. Nada! Zilch! Kaputt! Gone!  How I can make that more clear?

Or you happen to think about this fonts aside?  Forget about that
for now. This is not important here at this moment. 




Comment 22 Chip Coldwell 2007-01-29 13:26:50 EST
(In reply to comment #21)
> 
> In other words with a non-gtk version, and metacity, there is no
> issue. Nada! Zilch! Kaputt! Gone!  How I can make that more clear?

Dan -- thanks for having a look at this -- I put it aside over the weekend and
was a bit surprised to find all this email about it today.

I think this is a fair summary of the experiments Michal has done:

gtk | window manager | resizes
------------------------------
Y   | metacity       | N
Y   | sawfish        | Y
N   | metacity       | Y
Y   | twm            | Y

The surprising thing is that attaching strace to the process changes the
behavior.  IIUC, strace -p $(PID) will make the first configuration in the table
above work.

Chip
Comment 23 Chip Coldwell 2007-01-29 13:29:06 EST
(In reply to comment #7)
> Created an attachment (id=146732) [edit]
> File ~/.emacs from a test account
> 
> Well, the only non-commented line in ~/.emacs on a test account is
> (global-font-lock-mode t)


FYI, global-font-lock mode is on by default in emacs-22.

So, to summarize, all your site initialization files are the ones shipped with
the packages, right?  With the exception of the .emacs above, which in principle
isn't changing anything.

Chip

Comment 24 Chip Coldwell 2007-01-29 13:31:51 EST
(In reply to comment #9)
> Attaching strace to emacs after a window resize was attempted produces
> a constant stream of messages which look in this way:
> ...........
> select(5, [4], NULL, NULL, {0, 493000}) = 0 (Timeout)
> write(4, ";\0\5\0T\1\0\4\0\0\0\0\37\0004\0h\2\r\0L\1\5\0\203\0\0"..., 56) = 56
> select(5, [4], NULL, NULL, {0, 498464}) = 0 (Timeout)
> write(4, ";\0\5\0\224\0\0\4\0\0\0\0\37\0004\0\7\0\r\0L\1\5\0\203"..., 56) = 56
> select(5, [4], NULL, NULL, {0, 499683}) = 0 (Timeout)
> write(4, ";\0\5\0T\1\0\4\0\0\0\0\37\0004\0h\2\r\0L\1\5\0\203\0\0"..., 56) = 56
> select(5, [4], NULL, NULL, {0, 499705}) = 0 (Timeout)
> write(4, ";\0\5\0\224\0\0\4\0\0\0\0\37\0004\0\7\0\r\0L\1\5\0\203"..., 56) = 56
> select(5, [4], NULL, NULL, {0, 499763}) = 0 (Timeout)
> write(4, ";\0\5\0T\1\0\4\0\0\0\0\37\0004\0h\2\r\0L\1\5\0\203\0\0"..., 56) = 56
> select(5, [4], NULL, NULL, {0, 499673}) = 0 (Timeout)
> select(5, [4], NULL, NULL, {0, 10})     = 0 (Timeout)
> write(4, ";\0\5\0\224\0\0\4\0\0\0\0\37\0004\0\7\0\r\0L\1\5\0\203"..., 56) = 56
> select(5, [4], NULL, NULL, {0, 498731}) = 0 (Timeout)
> select(5, [4], NULL, NULL, {0, 54})     = 0 (Timeout)
> ...........

This is interesting.  Select is waiting on fd 4 to become readable, and when
that times out, emacs writes something to that file descriptor.  It would be
great if we could find out what that fd is.  Could you do this again, but also
run "lsof -p $(PID)" on the emacs PID so we can discover what it's trying to do?

Chip


Comment 25 dann 2007-01-29 13:46:47 EST
(In reply to comment #21)
> > 2. In comment #10 you state that it was happening with the non-gtk
> > version of.
> 
> Really?  Where?  Lets have a look what I wrote there: "... and not
> a whiff of a problem.  I can resize emacs windows until cows come
> home and a response is immediate and interactive".
Please reread my comment [2.] was refering to problem #2, setting the menu font.
Comment 26 Chip Coldwell 2007-01-29 14:04:52 EST
(In reply to comment #24)
> 
> This is interesting.  Select is waiting on fd 4 to become readable, and when
> that times out, emacs writes something to that file descriptor.  It would be
> great if we could find out what that fd is.  Could you do this again, but also
> run "lsof -p $(PID)" on the emacs PID so we can discover what it's trying to do?

I think it's very likely that fd 4 will turn out to be a Unix domain socket.

Chip
Comment 27 Michal Jaegermann 2007-01-29 16:52:46 EST
> IIUC, strace -p $(PID) will make the first configuration in
> the table above work.

Where $(PID) is a pid of an emacs process.  Yes, indeed, but
not entirely reliably.  On a few tries two out of every three
times. Roughly.  I was surprised myself.  Some timings change
or some locks are bypassed?

I had a remote connection open and I was attaching strace from
there.  Now I had to go to a rawhide machine and try to resize
emacs window.  Actually it is enough to look at a cursor shape
to know an outcome.  Still not a very scientific test.

Keep in mind that I never had that issue when opening an emacs
window on a remote; but I do not have two systems with rawhide
installations so I have no idea what it would happen if the
other machine would run a rawhide too.

Also, as reported, once I got into that "bad resizing" state with
sawfish too.  Only I did not managed to repeat that feat again.
Comment 28 Michal Jaegermann 2007-01-29 17:57:14 EST
What I am describing here about strace may or may not be relevant.
It does not work reliably either way and it seems that even less
reliably if I will start emacs from a non-root account (with
metacity for a window manager).  In these experiments emacs was
always started 'emacs -Q' to eliminate effects of splash and
startup files.

What Chip guessed about descriptors looks right on the money.
In strace reports repeteadly show up descriptors 4 and 5.  'lsof'
reports these, for an 'emacs' process, as
   4u  unix 0xffff810004343ac8              14533 socket
   5r  FIFO                0,6              14535 pipe

Now attaching strace like this '$(pgrep -f emacs)', before I touched
anything in this window at all, is producing somethig of that kind:

select(5, [4], NULL, NULL, {0, 208000}) = 0 (Timeout)
rt_sigprocmask(SIG_BLOCK, [IO], [], 8)  = 0
brk(0x2d46000)                          = 0x2d46000
rt_sigprocmask(SIG_UNBLOCK, [IO], [IO], 8) = 0
write(4, ";\0\5\0\264\1\340\3\0\0\0\0\37\0\0\0000\2\r\0L\1\5\0\203"..., 72) = 72
select(5, [4], NULL, NULL, {0, 497931}) = 0 (Timeout)
select(5, [4], NULL, NULL, {0, 335})    = 0 (Timeout)
write(4, ";\0\5\0\224\0\340\3\0\0\0\0\37\0\0\0\7\0\r\0L\1\5\0\203"..., 72) = 72
select(5, [4], NULL, NULL, {0, 498864}) = 0 (Timeout)
select(5, [4], NULL, NULL, {0, 315})    = 0 (Timeout)
write(4, ";\0\5\0\264\1\340\3\0\0\0\0\37\0\0\0000\2\r\0L\1\5\0\203"..., 72) = 72
select(5, [4], NULL, NULL, {0, 498789}) = 0 (Timeout)
select(5, [4], NULL, NULL, {0, 413})    = 0 (Timeout)
rt_sigprocmask(SIG_BLOCK, [IO], [], 8)  = 0
rt_sigprocmask(SIG_UNBLOCK, [IO], [IO], 8) = 0
write(4, ";\0\5\0\224\0\340\3\0\0\0\0\37\0\0\0\7\0\r\0L\1\5\0\203"..., 72) = 72
select(5, [4], NULL, NULL, {0, 498409}) = 0 (Timeout)
write(4, ";\0\5\0\264\1\340\3\0\0\0\0\37\0\0\0000\2\r\0L\1\5\0\203"..., 72) = 72
select(5, [4], NULL, NULL, {0, 498794}) = 0 (Timeout)
write(4, ";\0\5\0\224\0\340\3\0\0\0\0\37\0\0\0\7\0\r\0L\1\5\0\203"..., 72) = 72
select(5, [4], NULL, NULL, {0, 498957}) = 0 (Timeout)
rt_sigprocmask(SIG_BLOCK, [IO], [], 8)  = 0
rt_sigprocmask(SIG_UNBLOCK, [IO], [IO], 8) = 0
.....

Now, with strace attached, if I will try resize a window then most likely
this will work.  Maybe a bit slowly and haltingly but still.  It appears
that when this happens I see from strace this:
.....
rt_sigprocmask(SIG_BLOCK, [IO], [], 8)  = 0
rt_sigprocmask(SIG_UNBLOCK, [IO], [IO], 8) = 0
rt_sigprocmask(SIG_BLOCK, [IO], [], 8)  = 0
rt_sigprocmask(SIG_UNBLOCK, [IO], [IO], 8) = 0
rt_sigprocmask(SIG_BLOCK, [IO], [], 8)  = 0
rt_sigprocmask(SIG_UNBLOCK, [IO], [IO], 8) = 0
rt_sigprocmask(SIG_BLOCK, [IO], [], 8)  = 0
rt_sigprocmask(SIG_UNBLOCK, [IO], [IO], 8) = 0
.....
I am not entirely sure about correlation here but it may actually be
there.

If I will stop strace, try to resize that window, and attach strace
again it may not unblock window resizing.  I see in an output
something of that sort:
.....
select(5, [4], NULL, NULL, {0, 281000}) = 0 (Timeout)
write(4, ";\0\5\0\270\1\340\3\0\0\0\0\37\0\0\0\337\2\r\0C\1\5\0\203"..., 56) = 56
select(5, [4], NULL, NULL, {0, 499190}) = 0 (Timeout)
write(4, ";\0\5\0\270\1\340\3\0\0\0\0\37\0\0\0\337\2\r\0C\1\5\0\203"..., 56) = 56
select(5, [4], NULL, NULL, {0, 498235}) = 0 (Timeout)
write(4, ";\0\5\0\270\1\340\3\0\0\0\0\37\0\0\0\337\2\r\0C\1\5\0\203"..., 56) = 56
select(5, [4], NULL, NULL, {0, 498527}) = 0 (Timeout)
select(5, [4], NULL, NULL, {0, 18})     = 0 (Timeout)
.....
and that is it.

What is more I have now an emacs window with a mouse cursor in "<->" shape
after I tried to move the right edge and it sits there like that for at
least last 10 minutes.  The catch is that strace output looks actually
quite similar to what I got on the beginning so all of this may be
totally irrelevant.

On a root account one could expect that after some lengthy timeout this
edge will jump to a some unpredictable position and a cursor will return
to normal.  It appears that this may happen for non-root too but seemingly
it is quite a bit less likely.  The only reliable method to make now
possible to use _anything_ on a local desktop is to kill emacs.  This works.

As long as I am not trying to resize that window I do not see anything
wrong at all.

Added later: I tried again this trick with starting emacs, attaching
strace and trying to resize.  It is very far from reliable and it
appears the longer you running your sessions the the more likely
emacs get stuck on a resize - no matter what.
Comment 29 dann 2007-01-29 18:15:41 EST
> I had a remote connection open and I was attaching strace from
> there.  Now I had to go to a rawhide machine and try to resize

What are you window manager are you running on the remote machine?

From what you said previously metacity-2.17.5-1.fc7 + emacs-22 show the problem. 
Any other version of metacity where you can observe this? 

(For the record: it works fine for me with metacity-2.14.3, gtk2-2.8.20 on an
32bit x86 machine. I don't have a machine with FC7 to try it there...)
Comment 30 Michal Jaegermann 2007-01-29 21:19:44 EST
> What are you window manager are you running on the remote machine?

"machines" as a matter of fact:
FC5, x86_64, with metacity-2.14.3-1.fc5.1, gtk2-2.8.20-1
FC6,   i386, with metacity-2.16.0-5.fc6,   gtk2-2.10.8
CentOS 4, i386, with sawfish

> Any other version of metacity where you can observe this?

No, I did not try, unless using "remote" login and I am not in
a position do that right now.  OTOH I can do 'ssh -C2X localhost',
open emacs after login and, surprise, the resizing problem is
not there.  Any ideas?  At least I can hack a workaround with
a small script and 'authorized_keys'. :-)  Still nasty!

> I don't have a machine with FC7 to try 

The problem is most likely versions specific.

Comment 31 Chip Coldwell 2007-01-30 11:01:17 EST
(In reply to comment #28)
> 
> What Chip guessed about descriptors looks right on the money.
> In strace reports repeteadly show up descriptors 4 and 5.  'lsof'
> reports these, for an 'emacs' process, as
>    4u  unix 0xffff810004343ac8              14533 socket
>    5r  FIFO                0,6              14535 pipe

The unix socket is either the local X server or the gnome-session socket in
/tmp/.ICE-unix/${PID} (where now ${PID} is the process id of gnome-session).
Since the problem doesn't exist under twm, my guess is the latter.

So we need to figure out what the message is that emacs is sending to the
gnome-session.

Chip
Comment 32 Chip Coldwell 2007-01-30 11:07:57 EST
(In reply to comment #31)
> 
> So we need to figure out what the message is that emacs is sending to the
> gnome-session.

We may need to manually parse the messages.

http://www.xfree86.org/current/ice.pdf
Comment 33 Chip Coldwell 2007-01-30 11:31:08 EST
Please try the following

strace -o /tmp/emacs.trace -e trace=network -e read=4,5 -e write=4,5 -e
signal=\!SIGIO -xx emacs

and then attach the file "/tmp/emacs.trace" to the bugzilla.

Under FC-6, I am not seeing any traffic to the ICE socket when I resize emacs. 
I wonder if you'll see the same thing.

Chip
Comment 34 Michal Jaegermann 2007-01-30 13:44:24 EST
Created attachment 146948 [details]
"selective" strace from emacs run on a local display

Attached is a requested strace.  If is from 'emacs -Q' to minimize
"externalities" and for a user named "junk". :-)

Regardless if I am trying to do some resizing or if I will just let
it sit there without any action this output ends with the same line.
Here is that line translated by 'cat -v'; I am not sure what will
happen to those characters after bugzilla mangling:

accept(13, {sa_family=AF_FILE, path="M-^]^B"}, [35455951460892674]) = 15

This "path" does not look too convincing. A hex value of the next
argument is 0x7df70000000002.  Hm ...
Comment 35 Michal Jaegermann 2007-01-30 13:46:37 EST
Created attachment 146949 [details]
"selective" strace from emas after 'ssh -C2X localhost'

For a reference an analogous strace as above but after login "remote"
to a 'localhost'.
Comment 36 Chip Coldwell 2007-01-30 13:59:47 EST
socket(PF_FILE, SOCK_STREAM, 0)         = 13

fine

setsockopt(13, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0

fine

bind(13, {sa_family=AF_FILE, path="/tmp/orbit-junk/linc-e4c-0-33221501d4c0a"},
43) = 0

fine 

listen(13, 10)                          = 0

fine

getsockname(13, {sa_family=AF_FILE,
path="/tmp/orbit-junk/linc-e4c-0-33221501d4c0a"}, [8589934635]) = 0

addrlen looks suspicious

socket(PF_FILE, SOCK_STREAM, 0)         = 14

fine 

connect(14, {sa_family=AF_FILE, path="/tmp/.ICE-unix/3415"}, 21) = 0

fine

accept(13, {sa_family=AF_FILE, path="�"}, [35455951460892674]) = 15

path and addrlen look *very* suspicious.

/tmp/orbit-junk is maintained by KDE, right?

Chip
Comment 37 Michal Jaegermann 2007-01-30 15:12:04 EST
> /tmp/orbit-junk is maintained by KDE, right?

KDE?  Why KDE?  That would be ORBit2-2.14.5-2.fc7.x86_64 stuff.
As a matter of fact there are no traces of KDE on that test installation.

I also checked how this strace looks if I am using sawfish and I do
not have any resizing problems.  Actually it looks very similar.
That last "accept" line (again, after 'cat -v') comes as

accept(13, {sa_family=AF_FILE, path="M-^]^B"}, [6371669882961922]) = 15

i.e. the same path with addrlen pointer coming up as
0x16a30000000002.  This also really shows somewhat unexpected.
'twm' is not that different too and a trailing "0000000002" in an
address appears everywhere.
Comment 38 Michal Jaegermann 2007-01-30 20:00:14 EST
Just to add to this picture: I managed to completely lock up emacs,
and everything else until it was killed from a remote, just by going
through a few levels of a file completion.  At some moment emacs
deselected itself and stayed that way but holding to a cursor.

The trouble is that I failed to repeat that on a number of tries -
does not matter which window manager was in use.  The incident actually
happened when I was using sawfish.
Comment 39 Jan D. 2007-01-31 14:12:35 EST
The only thing ICE is used for in Emacs is the session management protocol.
Comment 40 Chip Coldwell 2007-01-31 15:28:25 EST
(In reply to comment #39)
> The only thing ICE is used for in Emacs is the session management protocol.

Then perhaps the socket is not the gnome-session /tmp/.ICE-unix/${PID} socket
but rather the CORBA/ORBit2 socket.  
Comment 41 Chip Coldwell 2007-02-01 11:52:16 EST
(In reply to comment #34)
> Created an attachment (id=146948) [edit]
> "selective" strace from emacs run on a local display

I want to return to this -- when I run emacs under FC-6, using the same strace
command, the only Unix sockets are:

socket(PF_FILE, SOCK_STREAM, 0)         = 3
connect(3, {sa_family=AF_FILE, path="/tmp/.X11-unix/X0"}, 19) = 0
shutdown(3, 2 /* send and receive */)   = 0

connect to the X server and shut down

socket(PF_FILE, SOCK_STREAM, 0)         = 3
connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (N
o such file or directory)
socket(PF_FILE, SOCK_STREAM, 0)         = 3
connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (N
o such file or directory)

to attempts to connect to the name service caching daemon that fail.

socket(PF_FILE, SOCK_STREAM, 0)         = 4
connect(4, {sa_family=AF_FILE, path="/tmp/.X11-unix/X0"}, 19) = 0

reconnect to the X server

socket(PF_FILE, SOCK_STREAM, 0)         = 5
connect(5, {sa_family=AF_FILE, path="/tmp/.ICE-unix/2930"}, 21) = 0

connect to the inter-client exchange (gnome-session) socket

socket(PF_FILE, SOCK_STREAM, 0)         = 3
bind(3, {sa_family=AF_FILE, path="/tmp/emacs10378/server"}, 110) = 0

I run server-mode in my .emacs.

Important points:

Never, does emacs connect to ORBit (CORBA) sockets.  In fact, it does not even
link /usr/lib/libORBit-2.so.0.  I also checked that the FC-7 emacs binary does
not link that library.  Do you have any idea why emacs would need CORBA?

Chip
Comment 42 Chip Coldwell 2007-02-01 11:57:03 EST
I started the nscd, then ran the strace again, with emacs -Q.  Here's all the
output:

--- SIGCHLD (Child exited) @ 0 (0) ---
socket(PF_FILE, SOCK_STREAM, 0)         = 3
connect(3, {sa_family=AF_FILE, path="/tmp/.X11-unix/X0"}, 19) = 0
shutdown(3, 2 /* send and receive */)   = 0
socket(PF_FILE, SOCK_STREAM, 0)         = 3
connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = 0
send(3, "\x02\x00\x00\x00\x0b\x00\x00\x00\x07\x00\x00\x00\x70\x61"..., 20,
MSG_NOSIGNAL) = 20
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"\x70\x61\x73\x73\x77\x64\x00", 7}],
msg_controllen=16, {cmsg_len=16, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS,
{4}}, msg_flags=0}, 0) = 7
socket(PF_FILE, SOCK_STREAM, 0)         = 4
connect(4, {sa_family=AF_FILE, path="/tmp/.X11-unix/X0"}, 19) = 0
socket(PF_FILE, SOCK_STREAM, 0)         = 5
connect(5, {sa_family=AF_FILE, path="/tmp/.ICE-unix/2930"}, 21) = 0

Never, does emacs connect to the ORBit socket.

Chip
Comment 43 dann 2007-02-01 12:59:24 EST
(In reply to comment #41)
> (In reply to comment #34)

> Never, does emacs connect to ORBit (CORBA) sockets.  In fact, it does not even
> link /usr/lib/libORBit-2.so.0.  I also checked that the FC-7 emacs binary does
> not link that library.  Do you have any idea why emacs would need CORBA?

I don't think emacs needs CORBA, but it might be that one of the libraries it
links to on FC7 uses it. One way to confirm this is to look at the output of

pmap $EMACS_PID

Could you do that Michal? 


Comment 44 Michal Jaegermann 2007-02-01 14:30:35 EST
> I don't think emacs needs CORBA ...

Indeed, it does not.  At least not in a direct manner.  Neither
'ldd /usr/bin/emacs-22.0.93-x' shows any of ORBit2 libraries,
nor a more radical experiment of 'yum remove ORBit2'.  On a long
list of packages slated for a removal because of dependencies emacs
is absent.

Still strace shows that something peeks into /tmp/<name>-orbit/
directories.  Also if you will go through with 'yum remove ORBit2'
then most of the "top user interface" will be gone and something
else will need to be provided instead.  I expect that a graphics
emacs interface would still work on suitable remote displays
but we know that emacs is fine there already.
Comment 45 Chip Coldwell 2007-02-01 14:35:03 EST
(In reply to comment #44)
> > I don't think emacs needs CORBA ...
> 
> Indeed, it does not.  At least not in a direct manner.  Neither
> 'ldd /usr/bin/emacs-22.0.93-x' shows any of ORBit2 libraries,
> nor a more radical experiment of 'yum remove ORBit2'.  On a long
> list of packages slated for a removal because of dependencies emacs
> is absent.

Did you try

pmap ${EMACS_PID}

?

That will show ORBit in the running process memory map if it is, indeed, using it.

Chip
Comment 46 Michal Jaegermann 2007-02-01 14:55:01 EST
Created attachment 147134 [details]
a pmap output for emacs on rawhide

> Did you try 'pmap ${EMACS_PID}'?

It never came to my mind. :-)  If you will look at it then ORBit2 does
show up there in a pretty obvious manner:
....
0000003891e00000    360K r-x--	/usr/lib64/libORBit-2.so.0.1.0
0000003891e5a000   2044K -----	/usr/lib64/libORBit-2.so.0.1.0
0000003892059000     76K rw---	/usr/lib64/libORBit-2.so.0.1.0
0000003892a00000     20K r-x--	/usr/lib64/libORBitCosNaming-2.so.0.1.0
0000003892a05000   2044K -----	/usr/lib64/libORBitCosNaming-2.so.0.1.0
0000003892c04000      8K rw---	/usr/lib64/libORBitCosNaming-2.so.0.1.0
....

Full output of pmap in an attachment, if that could be of any help
Comment 47 Michal Jaegermann 2007-02-01 14:58:35 EST
I should add that after 'ssh -C2X localhost' and starting emacs from
there there are no traces of ORBit2 in an output of pmap for that process.
Comment 48 Chip Coldwell 2007-02-01 15:01:16 EST
(In reply to comment #46)

> It never came to my mind. :-)  If you will look at it then ORBit2 does
> show up there in a pretty obvious manner:

So something must dlopen it.  The CosNaming is interesting -- it seems like some
component of gtk is trying to look up a service by name.

Chip
Comment 49 Chip Coldwell 2007-02-01 15:12:34 EST
(In reply to comment #46)
> 
> Full output of pmap in an attachment, if that could be of any help

bonobo and bonobo-activation show up in there, too.

Chip

Comment 50 dann 2007-02-01 15:31:50 EST
(In reply to comment #48)
> (In reply to comment #46)
> 
> > It never came to my mind. :-)  If you will look at it then ORBit2 does
> > show up there in a pretty obvious manner:
> 
> So something must dlopen it.  The CosNaming is interesting -- it seems like some
> component of gtk is trying to look up a service by name.

A complete strace output might show where does Orbit come from...
Comment 51 Chip Coldwell 2007-02-01 15:48:57 EST
http://developer.gnome.org/doc/API/2.0/libbonobo/debugging.html

CORBA method tracing

There is beautiful built in ORBit2 method tracing facility that will show you
all CORBA invocations, their objects, arguments, microsecond timestamps etc. To
use it you need to configure ORBit2 with the --enable-debug switch and then
either define the environment variable ORBIT2_DEBUG or use the ORBDebugFlags
command line option or orbitrc flag. See the ORBit2 FAQ for more info.

The FAQ is here

http://www.gnome.org/projects/ORBit2/orbit-faq/faq/faq.html

But it's not clear to me what the value of ORBIT2_DEBUG should be to get
tracing.  Maybe try

export ORBIT2_DEBUG=traces:objects
emacs

I build some ORBit2 packages with debugging enabled and put them up here:

http://people.redhat.com/coldwell/bugs/emacs/224611/

Chip
Comment 52 Chip Coldwell 2007-02-01 15:59:30 EST
(In reply to comment #50)
> 
> A complete strace output might show where does Orbit come from...

Good point.  Could you attach a full (unfiltered) strace, also.

Chip
Comment 53 Michal Jaegermann 2007-02-01 16:15:52 EST
I have some suspicions that these ORBit2 issues is a false track.
When I am running under sawfish, where I have no resizing problems,
then pmap output is practically the same.

As a matter of fact here is a full 'diff' of such pmap with what
I posted before:

--- pmap.emacs.txt      2007-02-01 12:48:59.000000000 -0700
+++ pmap.emacs.sawfish  2007-02-01 14:05:45.000000000 -0700
@@ -1,5 +1,5 @@
-6423:   emacs -Q
+25353:   emacs -Q
 0000000000400000   1656K r-x--  /usr/bin/emacs-x
 000000000079e000  34248K rw---  /usr/bin/emacs-x
-0000000002910000   4324K rw---    [ anon ]
+0000000002910000   4332K rw---    [ anon ]
 000000347ba00000    544K r-x--  /usr/lib64/libfreetype.so.6.3.11
@@ -193,3 +193,3 @@
 00002aaaaccab000      4K rw--- 
/usr/lib64/gtk-2.0/2.10.0/loaders/libpixbufloader-xpm.so
-00002aaaaccac000    384K rw-s-    [ shmid=0x3bb0008 ]
+00002aaaaccac000    384K rw-s-    [ shmid=0x4fa0006 ]
 00002aaaacd0c000     28K r--s- 
/var/cache/fontconfig/beeeeb3dfe132a8a0633a017c99ce0c0-x86-64.cache-2
@@ -207,4 +207,4 @@
 00002aaaacdd6000    272K rw---    [ anon ]
-00007fffc9c38000    100K rw---    [ stack ]
+00007ffffc594000    108K rw---    [ stack ]
 ffffffffff600000      4K r-x--    [ anon ]
- total           172680K
+ total           172696K
Comment 54 Michal Jaegermann 2007-02-01 16:19:28 EST
> Could you attach a full (unfiltered) strace, also.

It is pretty boring, I am afraid.  You will get megabytes and
megabytes of stuff which looks like that fragment in comment #9.
How far you want to go with that?  It does not stop!
Comment 55 Chip Coldwell 2007-02-01 16:21:01 EST
(In reply to comment #53)
> I have some suspicions that these ORBit2 issues is a false track.

Please, let's rule these things out on data, not hunches.

Chip

Comment 56 Chip Coldwell 2007-02-01 16:22:03 EST
(In reply to comment #54)
>
> It is pretty boring, I am afraid.  You will get megabytes and
> megabytes of stuff which looks like that fragment in comment #9.
> How far you want to go with that?  It does not stop!

Please

$ strace -o /tmp/emacs.trace emacs -Q

attempt to resize, and if the problem reproduces quit emacs and attach the file
/tmp/emacs.trace.  

Chip

Comment 57 Michal Jaegermann 2007-02-01 17:10:06 EST
> ... and if the problem reproduces ... 

Does not work that way.  I wrote already something about similar
things in comment #15. If I will do 'strace -o /tmp/emacs.trace emacs -Q'
then everything slows down and, once there is enough of a window to
try resizing, then it does.  If I quit now I end with with some 14-15
megs of trace and that is about it.  On about thirty attempts I did
not manage to lock that once.

Attaching strace to an already messed up process may, or may not,
unlock it but that is another story.

>  ... and if the problem reproduces quit emacs

Then quiting is hard I have to kill it from outside. :-)

BTW - I thought that an observation that with practically the
same pmap but a different window manager resizing works,
which shows that ORBit at least by itself is not the culprit,
is data and not a hunch.
Comment 58 Michal Jaegermann 2007-02-01 18:47:34 EST
Created attachment 147168 [details]
an output from pmap for the same emacs version but on FC6

OK, one more datapoint.  I took emacs-22.0.93-5.fc7.src.rpm and
on FC6 installation (on the same machine but different part of a disk)
I did 'rpmbuild --rebuild emacs-22.0.93-5.fc7.src.rpm'.
In case you wonder I have in my ~/.rpmmacros also this:

%dist	  %([ -r /etc/fedora-release ] && d=$(</etc/fedora-release);\
   d="${d% *}"; d="${d##* }"; [[ $d =~ ^6\\. ]] && d=7; echo ".fc$d")

so '--rebuild' really works.

This produced a bunch of "22.0.93-5.fc6.x86_64" binary packages and
a resulting emacs identifies itself as

GNU Emacs 22.0.93.1 (x86_64-redhat-linux-gnu, GTK+ Version 2.10.8)

The one from rawhide is:
GNU Emacs 22.0.93.1 (x86_64-redhat-linux-gnu, GTK+ Version 2.10.9)

I run that using metacity-2.16.0-5.fc6 for a window manager.
Not a whiff of a window resizing problem and outwardly emacs
window looks the same as the one from rawhide.

OTOH in pmap for that I do not see ORBit or bonobo. Attached for
a comparison.
Comment 59 dann 2007-02-01 19:57:02 EST
(In reply to comment #57)
> > ... and if the problem reproduces ... 
> 
> Does not work that way.  I wrote already something about similar
> things in comment #15. If I will do 'strace -o /tmp/emacs.trace emacs -Q'
> then everything slows down and, once there is enough of a window to
> try resizing, then it does.  If I quit now I end with with some 14-15
> megs of trace and that is about it.  On about thirty attempts I did
> not manage to lock that once.

Can you at least try to see where is Orbit comming from?
Btw, you can greatly reduce the size of the strace by filtering out 
the "rt_sigprocmask" call. On FC5 this counts for 96% of the number of lines in
the strace file.
Comment 60 Michal Jaegermann 2007-02-01 20:42:57 EST
Created attachment 147172 [details]
strace from emacs with its window "locked" - rt_sigprocmask filtered out

> Btw, you can greatly reduce the size of the strace by filtering out
> the "rt_sigprocmask" call.

Sure, but I thought that you want the full thing. :-)

Anyway, I decided to try starting with strace few more times and
at some moment I got "lucky".  Even that way an attempt to resize
an emacs window locked it.  This even made strace smaller.
After throwing away all rt_sigprocmask's it weights 443K.  If you
will do the same after "start, try to resize, close" you will get
around 750K of data.

The original trace for the case is 263304 lines long and 12 Megs.

> Can you at least try to see where is Orbit comming from?
This is not clear to me.  Quite possibly at-spi libraries are pulling
that in.
Comment 61 Chip Coldwell 2007-02-02 14:58:01 EST
(In reply to comment #60)
> Created an attachment (id=147172) [edit]
> strace from emacs with its window "locked" - rt_sigprocmask filtered out
> 
> > Can you at least try to see where is Orbit comming from?
>
> This is not clear to me.  Quite possibly at-spi libraries are pulling
> that in.

This strace is very helpful.  It's pretty clear to me that the bonobo/ORBit
stuff is coming from libatk (i.e. the GNOME Accessibility ToolKit).  Here's a
snippet:

access("/usr/lib64/gtk-2.0/modules/libatk-bridge.so", F_OK) = 0
stat("/usr/lib64/gtk-2.0/modules/libatk-bridge.so", {st_mode=S_IFREG|0755,
st_size=28160, ...}) = 0
open("/usr/lib64/gtk-2.0/modules/libatk-bridge.so", O_RDONLY) = 4
read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0,\0\0\0"..., 832) = 832
fstat(4, {st_mode=S_IFREG|0755, st_size=28160, ...}) = 0
brk(0x2968000)                          = 0x2968000
mmap(NULL, 2123648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) =
0x2aaaab319000
mprotect(0x2aaaab31f000, 2097152, PROT_NONE) = 0
mmap(0x2aaaab51f000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x6000) = 0x2aaaab51f000
close(4)                                = 0
open("/usr/lib64/tls/libspi.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib64/libspi.so.0", O_RDONLY) = 4
read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p0b\3134"..., 832) = 832
fstat(4, {st_mode=S_IFREG|0755, st_size=383424, ...}) = 0
mmap(0x34cb600000, 2476616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4,
0) = 0x2aaaab520000
mprotect(0x2aaaab56d000, 2097152, PROT_NONE) = 0
mmap(0x2aaaab76d000, 65536, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x4d000) = 0x2aaaab76d000
close(4)                                = 0
open("/usr/lib64/tls/libbonobo-2.so.0", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/lib64/libbonobo-2.so.0", O_RDONLY) = 4
read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\200\""..., 832) = 832
fstat(4, {st_mode=S_IFREG|0755, st_size=472640, ...}) = 0
mmap(0x3893200000, 2566072, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4,
0) = 0x3893200000
mprotect(0x3893263000, 2093056, PROT_NONE) = 0
mmap(0x3893462000, 69632, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x62000) = 0x3893462000
close(4)                                = 0
open("/usr/lib64/tls/libbonobo-activation.so.4", O_RDONLY) = -1 ENOENT (No such
file or directory)
open("/usr/lib64/libbonobo-activation.so.4", O_RDONLY) = 4
read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\255\340"..., 832) = 832
fstat(4, {st_mode=S_IFREG|0755, st_size=109464, ...}) = 0
mmap(0x3892e00000, 2202496, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4,
0) = 0x3892e00000
mprotect(0x3892e17000, 2093056, PROT_NONE) = 0
mmap(0x3893016000, 16384, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x16000) = 0x3893016000
close(4)                                = 0
open("/usr/lib64/tls/libORBit-2.so.0", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/lib64/libORBit-2.so.0", O_RDONLY) = 4
read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200s\342"..., 832) = 832
fstat(4, {st_mode=S_IFREG|0755, st_size=443840, ...}) = 0
brk(0x2969000)                          = 0x2969000
mmap(0x3891e00000, 2538408, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4,
0) = 0x3891e00000
mprotect(0x3891e5a000, 2093056, PROT_NONE) = 0
mmap(0x3892059000, 77824, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x59000) = 0x3892059000
close(4)                                = 0

To summarize, emacs (or some library linked therein) looks for 

/usr/lib64/gtk-2.0/modules/libatk-bridge.so

and mmaps it, then mmaps in the following additional libraries:

/usr/lib64/libspi.so.0
/usr/lib64/libbonobo-2.so.0
/usr/lib64/libbonobo-activation.so.4
/usr/lib64/libORBit-2.so.0
/usr/lib64/libORBitCosNaming-2.so.0

also, when emacs was locked, it was doing writes to fd 4 followed by selects on
fd4 becoming readable that timed out.  From the strace, it appears that fd 4
was, in fact, the X server socket:

socket(PF_FILE, SOCK_STREAM, 0)         = 4
connect(4, {sa_family=AF_FILE, path="/tmp/.X11-unix/X0"}, 19) = 0

Chip
Comment 62 dann 2007-02-02 17:19:12 EST
(In reply to comment #61)
> (In reply to comment #60)
> > Created an attachment (id=147172) [edit] [edit]
> > strace from emacs with its window "locked" - rt_sigprocmask filtered out
> > 
> > > Can you at least try to see where is Orbit comming from?
> >
> > This is not clear to me.  Quite possibly at-spi libraries are pulling
> > that in.
> 
> This strace is very helpful.  It's pretty clear to me that the bonobo/ORBit
> stuff is coming from libatk (i.e. the GNOME Accessibility ToolKit).  Here's a
> snippet:

The origin of this is probably earlier, it opens libgnomecanvas. 
It might be prossible that either emacs is linked to some gnome libraries (it
should not be, it is a gtk application not a gnome application), or one of the
libraries that emacs links to is in turn linked to gnome libraries. 

Here is what I get for "ldd emacs" on FC5: 

ldd emacs
        linux-gate.so.1 =>  (0x0027c000)
        libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x0027d000)
        libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x00d04000)
        libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x00dd0000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x00b65000)
        libm.so.6 => /lib/libm.so.6 (0x007c8000)
        libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x00dee000)
        libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x00d90000)
        libcairo.so.2 => /usr/lib/libcairo.so.2 (0x00cb0000)
        libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x009d2000)
        libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00acd000)
        libdl.so.2 => /lib/libdl.so.2 (0x007ef000)
        libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x0093e000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00928000)
        libSM.so.6 => /usr/lib/libSM.so.6 (0x00a52000)
        libICE.so.6 => /usr/lib/libICE.so.6 (0x00a13000)
        libtiff.so.3 => /usr/lib/libtiff.so.3 (0x03253000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00634000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00ad3000)
        libz.so.1 => /usr/lib/libz.so.1 (0x007f5000)
        libXpm.so.4 => /usr/lib/libXpm.so.4 (0x00110000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0x00817000)
        libasound.so.2 => /lib/libasound.so.2 (0x02dbf000)
        libncurses.so.5 => /usr/lib/libncurses.so.5 (0x03208000)
        libc.so.6 => /lib/libc.so.6 (0x00693000)
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00afd000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0x00916000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00b3c000)
        libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00b60000)
        libXi.so.6 => /usr/lib/libXi.so.6 (0x00bb7000)
        libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00b47000)
        libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00b4d000)
        libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00b59000)
        /lib/ld-linux.so.2 (0x00676000)
        libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x00b8d000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00a5d000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x00812000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x0080a000)
        libexpat.so.0 => /lib/libexpat.so.0 (0x00a2f000)

It would be interesting to find out exactly which library is linked to the gnome
libraries. Looking at the ldd emacs results and then on the libraries shown by
that should be enough. 

It's possible that this is related to the resizing problem, but it is a problem
nevertheless. 
Comment 63 Chip Coldwell 2007-02-02 17:28:01 EST
(In reply to comment #62)
> 
> It would be interesting to find out exactly which library is linked to the gnome
> libraries. Looking at the ldd emacs results and then on the libraries shown by
> that should be enough. 

Michal: could you try this:

$ for i in `ldd /usr/bin/emacs-22.0.93-x | awk '/^\t/ { print $3 }'` ; do ldd $i
; done >/tmp/emacs.ldd

and attach the /tmp/emacs.ldd file, please?

Chip






> 
> It's possible that this is related to the resizing problem, but it is a problem
> nevertheless. 

Comment 64 Michal Jaegermann 2007-02-02 18:26:42 EST
This is the whole list, sorted, of libraries as shows by ldd for emacs-x:

/lib64/libc.so.6
/lib64/libdl.so.2
/lib64/libexpat.so.0
/lib64/libglib-2.0.so.0
/lib64/libgmodule-2.0.so.0
/lib64/libgobject-2.0.so.0
/lib64/libm.so.6
/lib64/libpthread.so.0
/usr/lib64/libatk-1.0.so.0
/usr/lib64/libcairo.so.2
/usr/lib64/libfontconfig.so.1
/usr/lib64/libfreetype.so.6
/usr/lib64/libgdk_pixbuf-2.0.so.0
/usr/lib64/libgdk-x11-2.0.so.0
/usr/lib64/libgif.so.4
/usr/lib64/libgtk-x11-2.0.so.0
/usr/lib64/libICE.so.6
/usr/lib64/libjpeg.so.62
/usr/lib64/libncurses.so.5
/usr/lib64/libpango-1.0.so.0
/usr/lib64/libpangocairo-1.0.so.0
/usr/lib64/libpangoft2-1.0.so.0
/usr/lib64/libpng12.so.0
/usr/lib64/libSM.so.6
/usr/lib64/libtiff.so.3
/usr/lib64/libungif.so.4
/usr/lib64/libX11.so.6
/usr/lib64/libXau.so.6
/usr/lib64/libXcursor.so.1
/usr/lib64/libXdmcp.so.6
/usr/lib64/libXext.so.6
/usr/lib64/libXfixes.so.3
/usr/lib64/libXinerama.so.1
/usr/lib64/libXi.so.6
/usr/lib64/libXpm.so.4
/usr/lib64/libXrandr.so.2
/usr/lib64/libXrender.so.1
/usr/lib64/libz.so.1

There is libatk-1.0.so.0 on this list but nothing seems to be "obvious"
to go for a bonobo and ORBit.
Comment 65 Michal Jaegermann 2007-02-02 20:56:26 EST
I do not see striking differences between these library lists.
'libasound' shows up only on FC5 and 'libgif' and 'libungif' in
the second case.
Comment 66 dann 2007-02-02 21:10:39 EST
(In reply to comment #64)
> This is the whole list, sorted, of libraries as shows by ldd for emacs-x:

Was this list generated by the command in comment #63? 
Comment 67 Michal Jaegermann 2007-02-02 21:41:19 EST
Oh, I missed that you want to see libraries used by emacs libraries.
That list will have tons of repeats (242 lines). So below is a list
generated by

ldd /usr/bin/emacs-x | awk '/=/{c="ldd "$3 ; system(c)}' | sort -u


This comes out as:

        /lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000)
        /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
        libatk-1.0.so.0 => /usr/lib64/libatk-1.0.so.0 (0x0000003891a00000)
        libcairo.so.2 => /usr/lib64/libcairo.so.2 (0x00000034ca000000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003e0ac00000)
        libc.so.6 => /lib64/libc.so.6 (0x00002aaaaacc6000)
        libdl.so.2 => /lib64/libdl.so.2 (0x0000003e0b400000)
        libexpat.so.0 => /lib64/libexpat.so.0 (0x00000034c7800000)
        libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00000034c7c00000)
        libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x000000347ba00000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib64/libgdk_pixbuf-2.0.so.0
(0x00000034c9400000)
        libgdk-x11-2.0.so.0 => /usr/lib64/libgdk-x11-2.0.so.0 (0x00000034ca400000)
        libgif.so.4 => /usr/lib64/libgif.so.4 (0x00000034cb600000)
        libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x0000003e0d000000)
        libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x0000003e0e400000)
        libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x0000003e0d400000)
        libICE.so.6 => /usr/lib64/libICE.so.6 (0x0000003e0d800000)
        libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x0000003e14600000)
        libm.so.6 => /lib64/libm.so.6 (0x0000003e0b000000)
        libpango-1.0.so.0 => /usr/lib64/libpango-1.0.so.0 (0x0000003890400000)
        libpangocairo-1.0.so.0 => /usr/lib64/libpangocairo-1.0.so.0
(0x00000034c9c00000)
        libpangoft2-1.0.so.0 => /usr/lib64/libpangoft2-1.0.so.0 (0x00000034cae00000)
        libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x0000003e0e000000)
        libX11.so.6 => /usr/lib64/libX11.so.6 (0x00000034c7000000)
        libXau.so.6 => /usr/lib64/libXau.so.6 (0x0000003e0bc00000)
        libXcursor.so.1 => /usr/lib64/libXcursor.so.1 (0x00000034c8800000)
        libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x0000003e0b800000)
        libXext.so.6 => /usr/lib64/libXext.so.6 (0x00000034c7400000)
        libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00000034c8c00000)
        libXinerama.so.1 => /usr/lib64/libXinerama.so.1 (0x00000034c8400000)
        libXi.so.6 => /usr/lib64/libXi.so.6 (0x00000034c9800000)
        libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x00000034c9000000)
        libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00000034c8000000)
        libz.so.1 => /usr/lib64/libz.so.1 (0x0000003e0c400000)

Still not something obvious.

Do you want to see results of 
ldd /usr/bin/emacs-x | awk '/=/{print $3; c="ldd "$3 ; system(c)}'
as well?
Comment 68 Chip Coldwell 2007-02-07 14:02:19 EST
I finally set up a rawhide x86_64 box and I have reproduced this bug.

Chip
Comment 69 Chip Coldwell 2007-02-07 15:17:54 EST
Go to 

System -> Control Center -> Assistive Technology ...

Unclick "Enable assistive technologies"

The problem goes away.

ATK seems to be in some weird state right after a rawhide install.  I don't know
why emacs is the only application that suffers.

Chip
Comment 70 Chip Coldwell 2007-02-07 15:19:08 EST
(In reply to comment #69)

> 
> The problem goes away.

I take it back.  I was being fooled by strace.

Chip
Comment 71 Michal Jaegermann 2007-02-07 15:30:45 EST
> I take it back.

I does seem to go away but after "unclicking" I had to log out and
start another session.  Only that caused a change in a window behaviour.

This, of course, is only a workaround which cannot be used by everybody.
Comment 72 Chip Coldwell 2007-02-07 16:09:41 EST
(In reply to comment #71)
> > I take it back.
> 
> I does seem to go away but after "unclicking" I had to log out and
> start another session.  Only that caused a change in a window behaviour.

You're right; I've verified that on my system.  So, to summarize, turn off
assitive technologies, log out, log in, and then it works.

> This, of course, is only a workaround which cannot be used by everybody.

I'm not suggesting otherwise.  However, it does greatly narrow our search for
the root cause.  It also seems likely that when found, it will not be a bug in
emacs per se but in the atk library.

Chip

Comment 73 Chip Coldwell 2007-02-07 16:14:06 EST
I have also verified that if you turn on assitive technologies, log out and log
back in, then the problem re-appears.

Chip
Comment 74 Michal Jaegermann 2007-02-07 16:27:03 EST
> ... it will not be a bug in emacs per se but in the atk library.

Somewhere metacity is mixed in in that picture.  If I am trying
that with sawfish or twm for a window manager there are no resizing
problems does not matter what is an ATK status.  Also this detail
that the problem is really hard to reproduce under strace shows
that it is timing sensitive.
Comment 75 Jan D. 2007-02-08 02:13:15 EST
It could be that only Emacs is affected because Emacs don't use the normal gtk
event loop, but ist own mixture of raw X11 events and gtk routines.  In the past
we (Emacs developers) had problems with timers because of this.  For example, if
a timer is set in the normal gtk fashion, it will not be noticed by the Emacs
event loop.  There are some hacks for scroll bars and menus in Emacs just
because of this.  FYI, Xt-based calls and Emacs have the same problem.

Can there be some timer that Emacs fail to execute, but one that Atk depends on?
Comment 76 Chip Coldwell 2007-02-08 10:32:03 EST
I got emacs into the resize-wedged state, then attached gdb to the process. 
Here's the backtrace:

#0  0x0000003a826c7263 in __select_nocancel () from /lib64/libc.so.6
#1  0x000000000054fe79 in wait_reading_process_output (time_limit=0,
    microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=10361233,
    wait_proc=0x0, just_wait_proc=0) at process.c:4571
#2  0x00000000004bda94 in read_char (commandflag=1, nmaps=2,
    maps=0x7fff806352a0, prev_event=10361233, used_mouse_menu=0x7fff806353b0,
    end_time=0x0) at keyboard.c:4016
#3  0x00000000004c06d2 in read_key_sequence (keybuf=0x7fff80635430,
    bufsize=30, prompt=10361233, dont_downcase_last=0,
    can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9115
#4  0x00000000004c23ba in command_loop_1 () at keyboard.c:1618
#5  0x000000000051c3f4 in internal_condition_case (
    bfun=0x4c2210 <command_loop_1>, handlers=10455329,
    hfun=0x4bc440 <cmd_error>) at eval.c:1481
#6  0x00000000004bb75a in command_loop_2 () at keyboard.c:1329
#7  0x000000000051c4f7 in internal_catch (tag=<value optimized out>,
    func=0x4bb740 <command_loop_2>, arg=10361233) at eval.c:1222
#8  0x00000000004bc26c in command_loop () at keyboard.c:1308
#9  0x00000000004bc63a in recursive_edit_1 () at keyboard.c:1006
#10 0x00000000004bc739 in Frecursive_edit () at keyboard.c:1067
#11 0x00000000004b113b in main (argc=2, argv=0x7fff80635cd8) at emacs.c:1761
Comment 77 dann 2007-02-08 10:37:10 EST
(In reply to comment #68)
> I finally set up a rawhide x86_64 box and I have reproduced this bug.

 Have you  figured out what exactly brings in the gnome libraries?
Comment 78 Chip Coldwell 2007-02-08 11:29:18 EST
It's definitely looping forever in the select at src/process.c:4571.  It looks
like Jan's timer theory might be right.

Chip
Comment 79 Michal Jaegermann 2007-02-13 16:50:29 EST
It dawned on me that what I wrote in comment #58 is most likely misleading.
Not intentionally but still.  Indeed, I had a chance to try and in FC6 by
default ATK is turned off.  Once I turned that on, logged out and logged
back in then the same problem, at least with a recompiled
emacs-22.0.93-5.fc6.x86_64, shows there a well.

Actually with ATK on and an emacs window present but not touched menus
from a gnome-panel start to behave erraticaly, a response to mouse
seems "weird", possibly other things.  With ATK turned off all those
symptomps immediately disappear.
Comment 80 Andrew Gormanly 2007-02-15 13:50:29 EST
As an additional data point, I don't see this exact problem, but working using
emacs on an x86_64 rawhide install is almost impossible for me under the same
conditions (gnome, metacity, ATK) with emacs windows holding focus when I try to
switch away from it.

Trying to Alt-Tab or mouse select another window (very often, but not always) 
causes most of the session to seem frozen: the title bar of the emacs window 
remains selected, and although the system monitor applet graphs move it's 
not selectable and the clock does not advance; nothing else is usable.  Any 
keyboard commands will execute in the window I've switched to (e.g. a 
terminal) eventually.

The only guaranteed way back within a reasonable time (without sshing in from 
another machine and killing emacs) is to switch to a VT then switch back to X, 
whereupon the newly-selected window works properly.  Needless to saw, this is 
annoying.

As with the resizing issue, turning off ATK also cures this problem for me.
Comment 81 Chip Coldwell 2007-02-26 11:43:46 EST
There was a recent update of libatk in rawhide that seems to have fixed this
problem.  I'm also doing a rebuild of emacs to fix a bug in po-mode, so there
will be a new emacs package that was built against this library if that matters
(it shouldn't, since that's a shared library).  I would appreciate it if folks
could update their rawhide systems and verify that the problem is fixed for them.

Chip
Comment 82 Michal Jaegermann 2007-02-26 15:32:55 EST
> There was a recent update of libatk in rawhide that seems to have
> fixed this problem.

If by "recent" you mean atk-1.17.0-1.fc7 with "Build Date: Mon 12 Feb 2007"
then I do not see the slightest difference.  I am not aware of any
later updates.

I actually retested to make sure that I did not miss some atk changes.
Comment 83 Alexandre Oliva 2007-02-27 12:45:55 EST
*** Bug 229137 has been marked as a duplicate of this bug. ***
Comment 84 Matěj Cepl 2007-03-06 16:27:45 EST
(In reply to comment #17)
> Not really.  I do not have any other one save compiz but compiz
> does not work for me.  All windows come without frames and all
> new ones are located in 0x0 position.

You should try to run twm& from "Emergency session" (select it in the login
screen), then emacs&. Right clicking on the background should give you a menu
with Resize option.
Comment 85 Matěj Cepl 2007-03-06 17:42:47 EST
Created attachment 149399 [details]
output of strace -o emacs-strace.txt -f -F emacs
Comment 86 Matěj Cepl 2007-03-06 17:48:17 EST
Created attachment 149401 [details]
output of ltrace -r -o emacs-strace2.txt -f /usr/bin/emacs-22.0.93-x
Comment 87 Matěj Cepl 2007-03-06 17:50:25 EST
Created attachment 149402 [details]
output of strace with -c
Comment 88 Matěj Cepl 2007-03-06 17:51:56 EST
Created attachment 149403 [details]
summary of ltrace
Comment 89 Matěj Cepl 2007-03-06 17:56:09 EST
I can observe problems from comment 80 (on FC-6 with binaries daily upgraded
from Chip's repository; so I have emacs-22.0.93-3.fc6) and I have attached
strace/ltrace output when running emacs.
Comment 90 dann 2007-03-06 18:17:28 EST
(In reply to comment #89)
> I can observe problems from comment 80 (on FC-6 with binaries daily upgraded
> from Chip's repository; so I have emacs-22.0.93-3.fc6) and I have attached
> strace/ltrace output when running emacs.

Can you please find out why exactly is libbonobo loaded (or whatever gnome
library is first loaded)?  
I have a suspicion that the timer that might go wrong (as Jan said in comment
#75) might be set in libbonobo... 
Is libatk linked to libbonobo by any chance? Or does it dlopen it at run time
when ATK support is enabled? 
Comment 91 Matěj Cepl 2007-03-07 09:21:29 EST
(In reply to comment #90)
> Can you please find out why exactly is libbonobo loaded (or whatever gnome
> library is first loaded)?  
> I have a suspicion that the timer that might go wrong (as Jan said in comment
> #75) might be set in libbonobo... 
> Is libatk linked to libbonobo by any chance?

I don't think so:

[matej@hubmaier ~]$ uname -a
Linux hubmaier 2.6.18-8.el5xen #1 SMP Fri Jan 26 14:29:35 EST 2007 x86_64 x86_64
x86_64 GNU/Linux
[matej@hubmaier ~]$ ldd /usr/lib/libatk-1.0.so
        linux-gate.so.1 =>  (0xffffe000)
        libgobject-2.0.so.0 => /lib/libgobject-2.0.so.0 (0x4c046000)
        libgmodule-2.0.so.0 => /lib/libgmodule-2.0.so.0 (0x4c244000)
        libdl.so.2 => /lib/libdl.so.2 (0x4c040000)
        libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x4c087000)
        libc.so.6 => /lib/libc.so.6 (0x4bebf000)
        librt.so.1 => /lib/librt.so.1 (0x4c127000)
        /lib/ld-linux.so.2 (0x56555000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x4bffe000)
[matej@hubmaier ~]$ 
Comment 92 Matěj Cepl 2007-03-07 09:24:12 EST
I need to emphasize, that I have not Rawhide, but RHEL5-Gold here with FC6
emacs22 from Chip's repository.

Isn't time to switch component of this bug to atk?
Comment 93 Chip Coldwell 2007-03-07 11:19:54 EST
(In reply to comment #92)
> I need to emphasize, that I have not Rawhide, but RHEL5-Gold here with FC6
> emacs22 from Chip's repository.
> 
> Isn't time to switch component of this bug to atk?

Possibly.

I am attempting to debug the problem by attaching gdb to hung emacs processes. 
The emacs process itself is perfectly happy when this happens -- it is in its
usual main event loop waiting for input.  It is, in fact, metacity that is hung
when this happens.  I then tried to figure out what is happening in metacity. 
This is an email I sent to Matthias Clasen, who maintains the ATK package for
Red Hat (no reply yet):

Date: Tue, 27 Feb 2007 15:45:06 -0500 (EST)
From: Chip Coldwell <coldwell@frank.harvard.edu>
To: mclasen@redhat.com
Subject: emacs/AT-SPI bug


Hi Matthias,

I'm hoping you can give me a pointer on 

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224611

Basically, in rawhide/F-7, if you try to resize an emacs frame
metacity goes catatonic.  By strace-ing/gdb-ing emacs I can see that
it thinks it is in its usual main event loop.  The problem goes away
if I turn off "Assitive Technologies".

It occurred to me that I should probably be strace-ing metacity, not
emacs, so I rebuilt the at-spi library with -DSPI_DEBUG (see attached
patch that cleans up a syntax error).  So I get metacity into a wedged
state and attach a gdb, the top of the (x86_64) stack trace looks like
this:

#0  0x0000003a460c516f in poll () from /lib64/libc.so.6
#1  0x0000003a47c2fbee in g_str_equal () from /lib64/libglib-2.0.so.0
#2  0x0000003a47c302ce in g_main_context_iteration ()
   from /lib64/libglib-2.0.so.0
#3  0x0000003a5182b4b5 in giop_recv_buffer_get ()
   from /usr/lib64/libORBit-2.so.0
#4  0x0000003a5182f0cc in ORBit_small_invoke_stub ()
   from /usr/lib64/libORBit-2.so.0
#5  0x0000003a57e290dc in Accessibility_EventListener_notifyEvent ()
   from /usr/lib64/libspi.so.0
#6  0x00002aaaae651656 in g_str_equal ()
   from /usr/lib64/gtk-2.0/modules/libatk-bridge.so
#7  0x00002aaaae651ce8 in g_str_equal ()
   from /usr/lib64/gtk-2.0/modules/libatk-bridge.so
#8  0x0000003a4881a5b1 in g_str_equal () from /lib64/libgobject-2.0.so.0
#9  0x0000003a4881bbd4 in g_signal_emit_valist ()
   from /lib64/libgobject-2.0.so.0
#10 0x0000003a4881bda3 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#11 0x0000003a4880af19 in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#12 0x0000003a4881a788 in g_str_equal () from /lib64/libgobject-2.0.so.0
#13 0x0000003a4881bbd4 in g_signal_emit_valist ()
   from /lib64/libgobject-2.0.so.0
#14 0x0000003a4881e190 in g_signal_emit_by_name ()
   from /lib64/libgobject-2.0.so.0

I also instrumented emacs to output the xevents that it was
processing, and this trace is provoked by a FocusOut followed by a
FocusIn.

IIUC, the EventListener is instrumenting focus changes.  Can you think
of any reason it might get wedged like this?

Thanks,

Chip
Comment 94 dann 2007-03-07 13:05:01 EST
(In reply to comment #85)
> Created an attachment (id=149399) [edit]
> output of strace -o emacs-strace.txt -f -F emacs

Looking at this and at the ltrace output it seems clear that the bonobo/gnome
stuff is loaded because something loads libgail, which in turn loads
libgnomecanvas...

Could you try running emacs like this:
env GTK_MODULES= emacs -Q
when ATK is turned on and see if it still locks up? 
Comment 95 dann 2007-03-08 13:07:14 EST
On FC5 I get a segmentation when exiting emacs with ATK enabled...
(just run emacs -Q and then press C-x C-c)
It seems that enabling ATK sets the GTK_MODULES environment variable to
gail:atk-bridge. The crash does not happen if GTK_MODULES in unset.


env GTK_MODULES=gail:atk-bridge gdb --args ./emacs -Q
GNU gdb Red Hat Linux (6.3.0.0-1.134.fc5rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".

DISPLAY = :0.0
TERM = xterm
Breakpoint 1 at 0x80f3f76: file /extra/dannlt/emacs/Emacs-CVS/emacs/src/emacs.c,
line 431.
Breakpoint 2 at 0x810d126: file
/extra/dannlt/emacs/Emacs-CVS/emacs/src/sysdep.c, line 1385.
(gdb) r
Starting program: /extra/dannlt/emacs/Emacs-CVS/objs/src/emacs -geometry 80x40+0+0
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0x6b1000
[Thread debugging using libthread_db enabled]
[New Thread -1208112864 (LWP 26952)]
[Switching to Thread -1208112864 (LWP 26952)]
Breakpoint 3 at 0x80c8cc6: file /extra/dannlt/emacs/Emacs-CVS/emacs/src/xterm.c,
line 7858.
GTK Accessibility Module initialized

Program received signal SIGSEGV, Segmentation fault.
0x02d880b6 in ORBit_marshal_object () from /usr/lib/libORBit-2.so.0
(gdb) bt
#0  0x02d880b6 in ORBit_marshal_object () from /usr/lib/libORBit-2.so.0
#1  0x02d8e33e in ORBit_marshal_value () from /usr/lib/libORBit-2.so.0
#2  0x02d8e012 in ORBit_marshal_value () from /usr/lib/libORBit-2.so.0
#3  0x02d8e4e9 in ORBit_marshal_any () from /usr/lib/libORBit-2.so.0
#4  0x02d8e17c in ORBit_marshal_value () from /usr/lib/libORBit-2.so.0
#5  0x02d8e012 in ORBit_marshal_value () from /usr/lib/libORBit-2.so.0
#6  0x02d85820 in ORBit_small_allocbuf () from /usr/lib/libORBit-2.so.0
#7  0x02d85b53 in ORBit_small_invoke_stub () from /usr/lib/libORBit-2.so.0
#8  0x02d85d6e in ORBit_small_invoke_stub_n () from /usr/lib/libORBit-2.so.0
#9  0x02d92ff2 in ORBit_c_stub_invoke () from /usr/lib/libORBit-2.so.0
#10 0x00c20714 in Accessibility_EventListener_notifyEvent () from
/usr/lib/libspi.so.0
#11 0x00be3a2d in gnome_accessibility_module_shutdown () from
/usr/lib/gtk-2.0/modules/libatk-bridge.so
#12 0x00be3d13 in gnome_accessibility_module_shutdown () from
/usr/lib/gtk-2.0/modules/libatk-bridge.so
#13 0x0048081e in exit () from /lib/libc.so.6
#14 0x080f3d73 in Fkill_emacs (arg=Variable "arg" is not available.
) at /extra/dannlt/emacs/Emacs-CVS/emacs/src/emacs.c:2055
#15 0x0815bb51 in Ffuncall (nargs=1, args=0xbfe939e0) at
/extra/dannlt/emacs/Emacs-CVS/emacs/src/eval.c:2997
#16 0x0818640f in Fbyte_code (bytestr=136204051, vector=136204068, maxdepth=40)
    at /extra/dannlt/emacs/Emacs-CVS/emacs/src/bytecode.c:679
#17 0x0815b5fa in funcall_lambda (fun=136204004, nargs=1, arg_vector=0xbfe93b64)
    at /extra/dannlt/emacs/Emacs-CVS/emacs/src/eval.c:3184
#18 0x0815ba01 in Ffuncall (nargs=2, args=0xbfe93b60) at
/extra/dannlt/emacs/Emacs-CVS/emacs/src/eval.c:3054
#19 0x08158e5d in Fcall_interactively (function=137802825,
record_flag=137464009, keys=137504524)
    at /extra/dannlt/emacs/Emacs-CVS/emacs/src/callint.c:860
#20 0x080f8bb3 in Fcommand_execute (cmd=137802825, record_flag=137464009,
keys=137464009, special=137464009)
    at /extra/dannlt/emacs/Emacs-CVS/emacs/src/keyboard.c:10014
#21 0x0810441b in command_loop_1 () at
/extra/dannlt/emacs/Emacs-CVS/emacs/src/keyboard.c:1873
#22 0x0815a642 in internal_condition_case (bfun=0x81040a0 <command_loop_1>,
handlers=137508665, hfun=0x80fec10 <cmd_error>)
    at /extra/dannlt/emacs/Emacs-CVS/emacs/src/eval.c:1481
#23 0x080fdfc3 in command_loop_2 () at
/extra/dannlt/emacs/Emacs-CVS/emacs/src/keyboard.c:1329
#24 0x0815a6fa in internal_catch (tag=137502649, func=0x80fdfa0
<command_loop_2>, arg=137464009)
    at /extra/dannlt/emacs/Emacs-CVS/emacs/src/eval.c:1222
#25 0x080fea4c in command_loop () at
/extra/dannlt/emacs/Emacs-CVS/emacs/src/keyboard.c:1308
#26 0x080fedea in recursive_edit_1 () at
/extra/dannlt/emacs/Emacs-CVS/emacs/src/keyboard.c:1006
#27 0x080feed6 in Frecursive_edit () at
/extra/dannlt/emacs/Emacs-CVS/emacs/src/keyboard.c:1067
#28 0x080f4d05 in main (argc=3, argv=0xbfe94424) at
/extra/dannlt/emacs/Emacs-CVS/emacs/src/emacs.c:1761

Lisp Backtrace:
"kill-emacs" (0x93ba9a1)
"save-buffers-kill-emacs" (0x83188c9)
"call-interactively" (0x836b449)
(gdb) 

Comment 96 Chip Coldwell 2007-03-09 12:32:22 EST
(In reply to comment #95)
> On FC5 I get a segmentation when exiting emacs with ATK enabled...
> (just run emacs -Q and then press C-x C-c)
> It seems that enabling ATK sets the GTK_MODULES environment variable to
> gail:atk-bridge. The crash does not happen if GTK_MODULES in unset.

No surprise really.  That should be equivalent to switching off ATK as far as
the emacs process is concerned.

Chip
Comment 97 Michal Jaegermann 2007-03-15 18:28:04 EDT
An update from atk-1.17.0-1.fc7 to atk-1.18.0-1.fc7, which just showed
up, did not change anything in this trouble for me.
Comment 98 Chip Coldwell 2007-05-14 10:22:39 EDT
Please try the packages linked from bug 239344 -- there is a report that this
problem might be fixed.

Chip
Comment 99 Michal Jaegermann 2007-05-14 15:17:40 EDT
> there is a report that this problem might be fixed.

I am not sure about "fixed".  Looks to me rather like "possibly
and accidentally worked around".  Keep in mind that binaries
I mentioned in
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239344#c11
were produced with glibc-2.5.90-22 on x86_64.
Comment 100 Adam Goode 2007-06-07 01:23:44 EDT
Just a tip: it seems that pressing numlock a few times will unfreeze Metacity
when this problem occurs.
Comment 101 Robert P. J. Day 2007-08-22 10:26:08 EDT
this very problem is occurring with emacs in f8-t1.
Comment 102 E Chion 2007-10-07 05:25:43 EDT
Pressing CapsLock twice also seems to unfreeze Metacity.
Comment 103 Jim Treadway 2008-02-29 13:32:36 EST
This looks like a pretty old bug, so hopefully this is the correct spot to
report this.  With the latest rawhide (emacs-22.1.50-4.fc9.i386,
metacity-2.21.13-1.fc9.i386) the resize problem is happening again.  This
actually started happening to me a few weeks ago, then it seemed to be fixed,
and now it's back again.

Pressing Caps Lock and/or Num Lock twice seems to "unhang" emacs (or metacity?).

This is 100% reproducible for me, so if anyone needs more information, feel free
to ask.
Comment 104 Kjartan Maraas 2008-04-19 12:02:03 EDT
*** Bug 431050 has been marked as a duplicate of this bug. ***
Comment 105 Bug Zapper 2008-05-13 22:34:32 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 106 Charles R. Anderson 2008-06-22 16:30:38 EDT
I'm still having the symptoms mentioned in comment #80 on F9 + updates. 
Alt-Tabbing away from emacs, or Ctrl-Alt-Arrow to another desktop causes the
whole desktop to freeze.
Comment 108 Lev Shamardin 2009-02-20 09:00:42 EST
I still have the issue (as described in Bug 431050).
emacs-22.3-4.fc10.i386, metacity-2.24.0-2.fc10.i386

I also observe the same problem with openbox-3.4.7.2-7.fc10.i386 and gnome/openbox session. The only difference is that the desktop does not hang completely, but becomes usable after a click on any window.
Comment 109 Bug Zapper 2009-06-09 18:25:40 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 110 Martin Dengler 2009-06-09 18:33:10 EDT
I can't change the ticket to F10 but as it's still happening for me in F10, I'd really like to.  Can someone do this, or better, verify in rawhide / F11?
Comment 111 Joe Smith 2009-06-17 15:58:59 EDT
I'm seeing this in f11 as well.
Comment 112 Patrick 2009-08-09 13:17:33 EDT
I am having the same problem as well on Fedora 11. When I move or resize the emacs window, the screen virtually freezes. The mouse can move, however, mouse clicks are "ignored". Pressing the keyboard seems to have no effect, but I can switch to a console login by pressing Ctrl+Alt+F2. If I again return to my initial session (by pressing Ctrl+Alt+F1) then emacs is moved/resizes and the session and mouse are responsive again. I use gnome, and this is the results from 'uname -a':
  "Linux zenview.localhost 2.6.29.6-217.2.3.fc11.i686.PAE #1 SMP Wed Jul 29 16:05:22 EDT 2009 i686 i686 i386 GNU/Linux"

The version of emacs installed 'rpm -q emacs':
   "emacs-22.3-14.fc11.i586"
pats
Comment 113 Joe Smith 2009-08-13 12:05:01 EDT
FWIW, I don't see this problem with the latest f11 update to Emacs 23:

$ rpm -qa | grep emacs
emacs-23.1-1.fc11.i586
emacs-common-23.1-1.fc11.i586

M-x emacs-version
GNU Emacs 23.1.1 (i386-redhat-linux-gnu, GTK+ Version 2.16.5) of 2009-08-03 on x86-5.fedora.phx.redhat.com

Emacs with quality fonts--fantastic!
Comment 114 Daniel Novotny 2009-08-18 08:38:17 EDT
All: is it now OK in F11 after the update? can I close this?
Comment 115 Joe Smith 2009-08-18 19:20:01 EDT
The problem does not occur in emacs 23, but was still happening 100% of the time for me with the last emacs 22 update on f11. The issue was resolved by the upgrade for me, but I don't know what the Fedora support policy is in this case.

F10 is still supported, right? Will emacs 23 be released for f10? Does it solve the problem there, too?
Comment 116 Matěj Cepl 2009-08-19 06:43:21 EDT
I can confirm that I am not able to reproduce this particular bug with emacs-23, but I have to note that emacs behavior with regards to window management, doesn't make me help. Why oh why, it is not able to remember the last size and position where it was when I exited from it last time as every other application I have installed?
Comment 117 Patrick 2009-09-01 09:28:14 EDT
The latest version of emacs:
   rpm -q emacs =>  emacs-23.1-3.fc11.i586,
works fine for me. It looks very different and the resize issue appears to be gone. I have no problem with this issue being closed.
Comment 118 Daniel Novotny 2009-09-01 10:39:57 EDT
OK, closing CURRENTRELEASE
Comment 119 Martin Dengler 2010-06-07 20:06:21 EDT
I am still seeing this issue (with accessibility turned on) in F12 (GNU Emacs 23.1.1 (x86_64-redhat-linux-gnu, GTK+ Version 2.18.9)).  It's less severe than I remember it: a) emacs seems to un-hang after about 5-8 seconds (in four trials I just did I got a "hang"/delay of 7, 8, 5, and 8 seconds).  But it's still definitely an issue.  Turning off "Enable assistive technologies" in System -> Preferences -> Assistive Technologies causes the symptom to dissappear.

This seems to be GNOME bug 392889 ( https://bugzilla.gnome.org/show_bug.cgi?id=392889 ) but I lack the rights to "add external bug" appropriately.

I don't think this bug should be CLOSED as 1) the symptom still exists; and 2) the upstream bug is not closed.

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