Bug 224611
|
Description
Michal Jaegermann
2007-01-26 17:57:01 UTC
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. Not reproduced on FC-5 nor FC-6. > 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.
(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 Date: Fri, 26 Jan 2007 15:32:31 -0500
From: Jeremy Katz <katzj>
To: Chip Coldwell <coldwell>
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
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 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.
Created attachment 146733 [details]
All files from /usr/share/emacs/site-lisp/site-start.d
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)
...........
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.
(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... (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 ? 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. (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? > 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. (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 > 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. (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. > 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? (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? > 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. (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 (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 (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 (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. (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 > 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.
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.
> 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...)
> 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. (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 (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 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 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 ...
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'.
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
> /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.
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. The only thing ICE is used for in Emacs is the session management protocol. (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. (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 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
(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? > 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.
(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 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 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. (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 (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 (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... 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 (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 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 > 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! (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 (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 > ... 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. 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.
(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. 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. (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 (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. (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. 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. I do not see striking differences between these library lists. 'libasound' shows up only on FC5 and 'libgif' and 'libungif' in the second case. (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? 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?
I finally set up a rawhide x86_64 box and I have reproduced this bug. Chip 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 (In reply to comment #69) > > The problem goes away. I take it back. I was being fooled by strace. Chip > 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.
(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 I have also verified that if you turn on assitive technologies, log out and log back in, then the problem re-appears. Chip > ... 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.
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? 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
(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? It's definitely looping forever in the select at src/process.c:4571. It looks like Jan's timer theory might be right. Chip 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. 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. 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 > 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.
*** Bug 229137 has been marked as a duplicate of this bug. *** (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. Created attachment 149399 [details]
output of strace -o emacs-strace.txt -f -F emacs
Created attachment 149401 [details]
output of ltrace -r -o emacs-strace2.txt -f /usr/bin/emacs-22.0.93-x
Created attachment 149402 [details]
output of strace with -c
Created attachment 149403 [details]
summary of ltrace
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. (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? (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 ~]$ 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? (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.edu> To: mclasen 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 (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? 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)
(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 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. Please try the packages linked from bug 239344 -- there is a report that this problem might be fixed. Chip > 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. Just a tip: it seems that pressing numlock a few times will unfreeze Metacity when this problem occurs. this very problem is occurring with emacs in f8-t1. Pressing CapsLock twice also seems to unfreeze Metacity. 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. *** Bug 431050 has been marked as a duplicate of this bug. *** 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 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. 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. 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 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? I'm seeing this in f11 as well. 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 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! All: is it now OK in F11 after the update? can I close this? 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? 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? 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. OK, closing CURRENTRELEASE 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. |