* gtk3, emacs 24 and gnome shell @ 2011-10-24 12:06 Andrea Crotti 2011-10-24 13:51 ` Tassilo Horn 2011-10-24 23:19 ` Rasmus 0 siblings, 2 replies; 30+ messages in thread From: Andrea Crotti @ 2011-10-24 12:06 UTC (permalink / raw) To: emacs-devel Now I can't test it again because I removed it a couple of weeks ago, but I thought only now that it's good to notify it. Using gnome3 with the gnome shell on archLinux and a self-compiled version of emacs 24 compiled against gtk3, pressing Ctrl-z on the emacs makes it unusable. ctrl-g or any other combination I tried failed, and only a kill -9 solved it. Anyone else experienced something similar? ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gtk3, emacs 24 and gnome shell 2011-10-24 12:06 gtk3, emacs 24 and gnome shell Andrea Crotti @ 2011-10-24 13:51 ` Tassilo Horn 2011-10-24 14:23 ` Andrea Crotti 2011-10-24 23:19 ` Rasmus 1 sibling, 1 reply; 30+ messages in thread From: Tassilo Horn @ 2011-10-24 13:51 UTC (permalink / raw) To: Andrea Crotti; +Cc: emacs-devel Andrea Crotti <andrea.crotti.0@gmail.com> writes: Hi Andrea, > Using gnome3 with the gnome shell on archLinux and a self-compiled > version of emacs 24 compiled against gtk3, pressing Ctrl-z on the > emacs makes it unusable. I've unset C-z, but that's `suspend-frame', right? If I do M-x suspend-frame RET (or C-z in emacs -Q) the emacs frame is minimized, and I can get it back via the GNOME 3 Overview or the application switcher. It's as usable as it was before. So it seems to work just as expected. Did you also try with emacs -Q? Bye, Tassilo ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gtk3, emacs 24 and gnome shell 2011-10-24 13:51 ` Tassilo Horn @ 2011-10-24 14:23 ` Andrea Crotti 2011-10-24 15:34 ` Tassilo Horn 0 siblings, 1 reply; 30+ messages in thread From: Andrea Crotti @ 2011-10-24 14:23 UTC (permalink / raw) To: Tassilo Horn; +Cc: emacs-devel On 10/24/2011 02:51 PM, Tassilo Horn wrote: > I've unset C-z, but that's `suspend-frame', right? If I do M-x > suspend-frame RET (or C-z in emacs -Q) the emacs frame is minimized, > and I can get it back via the GNOME 3 Overview or the application > switcher. It's as usable as it was before. So it seems to work just as > expected. Did you also try with emacs -Q? Bye, Tassilo Well no I didn't try with emacs -Q, also because I was too angry with the damn gnome-shell and I removed it almost immediately. Do you have the shell activated anyway? Probably it was more a bug in the gnome-shell than in Emacs... ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gtk3, emacs 24 and gnome shell 2011-10-24 14:23 ` Andrea Crotti @ 2011-10-24 15:34 ` Tassilo Horn 0 siblings, 0 replies; 30+ messages in thread From: Tassilo Horn @ 2011-10-24 15:34 UTC (permalink / raw) To: Andrea Crotti; +Cc: emacs-devel Andrea Crotti <andrea.crotti.0@gmail.com> writes: Hi Andrea, >> I've unset C-z, but that's `suspend-frame', right? If I do M-x >> suspend-frame RET (or C-z in emacs -Q) the emacs frame is minimized, >> and I can get it back via the GNOME 3 Overview or the application >> switcher. It's as usable as it was before. So it seems to work just >> as expected. Did you also try with emacs -Q? Bye, Tassilo > > Well no I didn't try with emacs -Q, also because I was too angry with > the damn gnome-shell and I removed it almost immediately. > > Do you have the shell activated anyway? Yes, I'm using GNOME 3.2.1 including the gnome-shell 3.2.1. My emacs is a bzr checkout as of yesterday build with In GNU Emacs 24.0.90.2 (x86_64-pc-linux-gnu, GTK+ Version 3.2.1) of 2011-10-23 on thinkpad Windowing system distributor `The X.Org Foundation', version 11.0.11101000 configured using `configure '--prefix=/usr' '--build=x86_64-pc-linux-gnu' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--libdir=/usr/lib64' '--disable-dependency-tracking' '--program-suffix=-emacs-24' '--infodir=/usr/share/info/emacs-24' '--with-crt-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../lib64' '--with-gameuser=games' '--without-compress-info' '--without-hesiod' '--without-kerberos' '--without-kerberos5' '--with-gpm' '--with-dbus' '--with-gnutls' '--without-selinux' '--with-sound' '--with-x' '--without-gconf' '--with-gsettings' '--with-xml2' '--without-toolkit-scroll-bars' '--without-wide-int' '--with-gif' '--with-jpeg' '--with-png' '--with-rsvg' '--with-tiff' '--with-xpm' '--with-imagemagick' '--with-xft' '--with-libotf' '--with-m17n-flt' '--with-x-toolkit=gtk3' 'EBZR_BRANCH=trunk' 'EBZR_REVNO=106170' 'build_alias=x86_64-pc-linux-gnu' 'host_alias=x86_64-pc-linux-gnu' 'CFLAGS=-mtune=native -O0 -pipe -g -ggdb' 'LDFLAGS=-Wl,-O1 -Wl,--as-needed'' > Probably it was more a bug in the gnome-shell than in Emacs... I don't know. All I can say is that it works fine for me. Bye, Tassilo ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gtk3, emacs 24 and gnome shell 2011-10-24 12:06 gtk3, emacs 24 and gnome shell Andrea Crotti 2011-10-24 13:51 ` Tassilo Horn @ 2011-10-24 23:19 ` Rasmus 2011-10-25 4:30 ` Chong Yidong 2011-10-25 7:06 ` Tassilo Horn 1 sibling, 2 replies; 30+ messages in thread From: Rasmus @ 2011-10-24 23:19 UTC (permalink / raw) To: Andrea Crotti; +Cc: emacs-devel Andrea Crotti <andrea.crotti.0@gmail.com> writes: > Now I can't test it again because I removed it a couple of weeks ago, > but I thought only now that it's good to notify it. > > Using gnome3 with the gnome shell on archLinux and a self-compiled version > of emacs 24 compiled against gtk3, pressing Ctrl-z on the emacs makes > it unusable. > > ctrl-g or any other combination I tried failed, and only a kill -9 > solved it. > > Anyone else experienced something similar? Emacs 24 bzr with GTK3 is very unstable on my Archlinux system as well. It will often just kill itself. I haven't figured out a way to test this properly as I am not aware of potential systematic errors. I use the Emacs daemon and i3 window manager. –Rasmus -- Sent from my Emacs ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gtk3, emacs 24 and gnome shell 2011-10-24 23:19 ` Rasmus @ 2011-10-25 4:30 ` Chong Yidong 2011-10-25 7:06 ` Tassilo Horn 1 sibling, 0 replies; 30+ messages in thread From: Chong Yidong @ 2011-10-25 4:30 UTC (permalink / raw) To: Rasmus; +Cc: Andrea Crotti, emacs-devel Rasmus <rasmus@gmx.us> writes: > Emacs 24 bzr with GTK3 is very unstable on my Archlinux system as > well. It will often just kill itself. I haven't figured out a way to > test this properly as I am not aware of potential systematic errors. > I use the Emacs daemon and i3 window manager. Any backtrace? ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gtk3, emacs 24 and gnome shell 2011-10-24 23:19 ` Rasmus 2011-10-25 4:30 ` Chong Yidong @ 2011-10-25 7:06 ` Tassilo Horn 2011-10-25 8:23 ` Rasmus 1 sibling, 1 reply; 30+ messages in thread From: Tassilo Horn @ 2011-10-25 7:06 UTC (permalink / raw) To: Rasmus; +Cc: Andrea Crotti, emacs-devel Rasmus <rasmus@gmx.us> writes: >> Anyone else experienced something similar? > > Emacs 24 bzr with GTK3 is very unstable on my Archlinux system as > well. It will often just kill itself. If "kill itself" means you close some frame and emacs is killed completely, that most likely the issue I've described in <87d3flnxoo.fsf@thinkpad.tsdh.de>. Bye, Tassilo ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gtk3, emacs 24 and gnome shell 2011-10-25 7:06 ` Tassilo Horn @ 2011-10-25 8:23 ` Rasmus 2011-10-25 8:52 ` Tassilo Horn 0 siblings, 1 reply; 30+ messages in thread From: Rasmus @ 2011-10-25 8:23 UTC (permalink / raw) To: Tassilo Horn; +Cc: Andrea Crotti, emacs-devel Tassilo Horn <tassilo@member.fsf.org> writes: > Rasmus <rasmus@gmx.us> writes: > >>> Anyone else experienced something similar? >> >> Emacs 24 bzr with GTK3 is very unstable on my Archlinux system as >> well. It will often just kill itself. > > If "kill itself" means you close some frame and emacs is killed > completely, that most likely the issue I've described in > <87d3flnxoo.fsf@thinkpad.tsdh.de>. A more adequate word would have been crash, i.e. a non-expected and undesirable halt. Examples on the top of my head: - I start Gnus. Emacs has some times closed ("crashed") before it got to the group buffer. - Emacs resists on a txt virtual desktop. Some times when I return from the www VD it has disappeared. But, as stated I am not aware of a systematic bug so I'm having a hard time reproducing it. I experience the kill-frame kill-daemon issue you have described in a previous post as well. This is more of an expected kill, though, and thus different from what I am describing above. Is there a way to have Emacs always log itself? –Rasmus -- Sent from my Emacs ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gtk3, emacs 24 and gnome shell 2011-10-25 8:23 ` Rasmus @ 2011-10-25 8:52 ` Tassilo Horn 2011-10-27 20:46 ` Rasmus 0 siblings, 1 reply; 30+ messages in thread From: Tassilo Horn @ 2011-10-25 8:52 UTC (permalink / raw) To: Rasmus; +Cc: Andrea Crotti, emacs-devel Rasmus <rasmus@gmx.us> writes: > Is there a way to have Emacs always log itself? Run it in gdb. Compile it without optimizations and -ggdb in CFLAGS and then run it like so: $ cd path/to/emacs/src/ $ gdb emacs gdb> run Then you'll get C and lisp backtraces when emacs crashes. (It's important to start emacs from its src directory, because that contains some GDB setup scripts.) Bye, Tassilo ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gtk3, emacs 24 and gnome shell 2011-10-25 8:52 ` Tassilo Horn @ 2011-10-27 20:46 ` Rasmus 2011-10-27 22:01 ` bug#9893: " Paul Eggert ` (2 more replies) 0 siblings, 3 replies; 30+ messages in thread From: Rasmus @ 2011-10-27 20:46 UTC (permalink / raw) To: Tassilo Horn; +Cc: emacs-devel Tassilo Horn <tassilo@member.fsf.org> writes: > Rasmus <rasmus@gmx.us> writes: > >> Is there a way to have Emacs always log itself? > > Run it in gdb. Compile it without optimizations and -ggdb in CFLAGS and > then run it like so: > > $ cd path/to/emacs/src/ > $ gdb emacs > gdb> run > > Then you'll get C and lisp backtraces when emacs crashes. (It's > important to start emacs from its src directory, because that contains > some GDB setup scripts.) I run the program using gdb etc. as suggested above, but no message is echoed upon a crash. Do I have to issue some command to get a backtrace? Thanks, Rasmus -- Sent from my Emacs ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#9893: gtk3, emacs 24 and gnome shell 2011-10-27 20:46 ` Rasmus @ 2011-10-27 22:01 ` Paul Eggert 2011-10-27 22:01 ` Paul Eggert 2011-10-28 6:18 ` Tassilo Horn 2 siblings, 0 replies; 30+ messages in thread From: Paul Eggert @ 2011-10-27 22:01 UTC (permalink / raw) To: emacs-devel; +Cc: Tassilo Horn, Rasmus, 9893 I can reproduce the problem on Fedora 15 x86-64 when running under the Gnome shell. I filed a bug report <http://debbugs.gnu.org/9893>. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gtk3, emacs 24 and gnome shell 2011-10-27 20:46 ` Rasmus 2011-10-27 22:01 ` bug#9893: " Paul Eggert @ 2011-10-27 22:01 ` Paul Eggert 2011-10-27 22:42 ` bug#9893: " Paul Eggert 2011-10-28 6:18 ` Tassilo Horn 2 siblings, 1 reply; 30+ messages in thread From: Paul Eggert @ 2011-10-27 22:01 UTC (permalink / raw) To: emacs-devel; +Cc: Tassilo Horn, Andrea Crotti, Rasmus, 9893 I can reproduce the problem on Fedora 15 x86-64 when running under the Gnome shell. I filed a bug report <http://debbugs.gnu.org/9893>. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#9893: gtk3, emacs 24 and gnome shell 2011-10-27 22:01 ` Paul Eggert @ 2011-10-27 22:42 ` Paul Eggert 2011-10-28 21:02 ` Jan Djärv 2011-10-30 17:26 ` Jan Djärv 0 siblings, 2 replies; 30+ messages in thread From: Paul Eggert @ 2011-10-27 22:42 UTC (permalink / raw) To: 9893 One more thing: the problem is not new to Emacs 24, as it occurs with the bundled Fedora 15 emacs ("GNU Emacs 23.2.1 (x86_64-redhat-linux-gnu, GTK+ Version 2.24.4) of 2011-05-23 on x86-12.phx2.fedoraproject.org"). There has been a bug report about this for Fedora since June <https://bugzilla.redhat.com/show_bug.cgi?id=711739>. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#9893: gtk3, emacs 24 and gnome shell 2011-10-27 22:42 ` bug#9893: " Paul Eggert @ 2011-10-28 21:02 ` Jan Djärv 2011-10-30 17:26 ` Jan Djärv 1 sibling, 0 replies; 30+ messages in thread From: Jan Djärv @ 2011-10-28 21:02 UTC (permalink / raw) To: Paul Eggert; +Cc: 9893 28 okt 2011 kl. 00:42 skrev Paul Eggert: > One more thing: the problem is not new to Emacs 24, as it > occurs with the bundled Fedora 15 emacs ("GNU Emacs 23.2.1 > (x86_64-redhat-linux-gnu, GTK+ Version 2.24.4) of 2011-05-23 > on x86-12.phx2.fedoraproject.org"). > > There has been a bug report about this for Fedora since June > <https://bugzilla.redhat.com/show_bug.cgi?id=711739>. > > I'm looking in to it now. There is no Map event when emacs is uniconified, so Emacs thinks it is still iconified. Either Gtk swallows it or gnome-shell doesn't send any. The former is unlikely as this also happens with Gtk 2.24.4 which works fine with other window managers. It is most likely gnome-shell specific. I'll see if there is any other way Emacs can detect when it becomes uniconified. Jan D. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#9893: gtk3, emacs 24 and gnome shell 2011-10-27 22:42 ` bug#9893: " Paul Eggert 2011-10-28 21:02 ` Jan Djärv @ 2011-10-30 17:26 ` Jan Djärv 2011-10-31 20:13 ` Paul Eggert 1 sibling, 1 reply; 30+ messages in thread From: Jan Djärv @ 2011-10-30 17:26 UTC (permalink / raw) To: Paul Eggert; +Cc: 9893-done 28 okt 2011 kl. 00:42 skrev Paul Eggert: > One more thing: the problem is not new to Emacs 24, as it > occurs with the bundled Fedora 15 emacs ("GNU Emacs 23.2.1 > (x86_64-redhat-linux-gnu, GTK+ Version 2.24.4) of 2011-05-23 > on x86-12.phx2.fedoraproject.org"). > > There has been a bug report about this for Fedora since June > <https://bugzilla.redhat.com/show_bug.cgi?id=711739>. > > Emacs expects MapNotify to arrive when it is deiconfified. But this doesn't seem to happen when we have iconfied us with gtk_window_iconfiy. So we now check for _NET_WM_STATE_HIDDEN changes also. But I don't really understand why Emacs does not process keypresses as normal when it is iconified or why Emacs even cares if it is iconfified or not. Jan D. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#9893: gtk3, emacs 24 and gnome shell 2011-10-30 17:26 ` Jan Djärv @ 2011-10-31 20:13 ` Paul Eggert 0 siblings, 0 replies; 30+ messages in thread From: Paul Eggert @ 2011-10-31 20:13 UTC (permalink / raw) To: 9893 Thanks for fixing that. I checked, and it works for my environment too (Fedora 15 x86-64, Emacs compiled with GCC 4.6.2). ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gtk3, emacs 24 and gnome shell 2011-10-27 20:46 ` Rasmus 2011-10-27 22:01 ` bug#9893: " Paul Eggert 2011-10-27 22:01 ` Paul Eggert @ 2011-10-28 6:18 ` Tassilo Horn 2011-10-28 6:58 ` Eli Zaretskii 2011-10-28 18:21 ` Rasmus Pank Roulund 2 siblings, 2 replies; 30+ messages in thread From: Tassilo Horn @ 2011-10-28 6:18 UTC (permalink / raw) To: Rasmus; +Cc: emacs-devel Rasmus <rasmus@gmx.us> writes: Hi Rasmus, >> Run it in gdb. Compile it without optimizations and -ggdb in CFLAGS and >> then run it like so: >> >> $ cd path/to/emacs/src/ >> $ gdb emacs >> gdb> run >> >> Then you'll get C and lisp backtraces when emacs crashes. (It's >> important to start emacs from its src directory, because that contains >> some GDB setup scripts.) > > I run the program using gdb etc. as suggested above, but no message is > echoed upon a crash. It shoult at least say that emacs has crashed somehow. > Do I have to issue some command to get a backtrace? Yes: bt full Bye, Tassilo ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gtk3, emacs 24 and gnome shell 2011-10-28 6:18 ` Tassilo Horn @ 2011-10-28 6:58 ` Eli Zaretskii 2011-10-28 18:21 ` Rasmus Pank Roulund 1 sibling, 0 replies; 30+ messages in thread From: Eli Zaretskii @ 2011-10-28 6:58 UTC (permalink / raw) To: Tassilo Horn; +Cc: rasmus, emacs-devel > From: Tassilo Horn <tassilo@member.fsf.org> > Date: Fri, 28 Oct 2011 08:18:13 +0200 > Cc: emacs-devel@gnu.org > > > I run the program using gdb etc. as suggested above, but no message is > > echoed upon a crash. > > It shoult at least say that emacs has crashed somehow. Not if Emacs exited normally. Then it will just said "Inferior exited normally". ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gtk3, emacs 24 and gnome shell 2011-10-28 6:18 ` Tassilo Horn 2011-10-28 6:58 ` Eli Zaretskii @ 2011-10-28 18:21 ` Rasmus Pank Roulund 2011-10-28 23:30 ` Michael Welsh Duggan 1 sibling, 1 reply; 30+ messages in thread From: Rasmus Pank Roulund @ 2011-10-28 18:21 UTC (permalink / raw) To: Tassilo Horn; +Cc: emacs-devel Tassilo Horn <tassilo@member.fsf.org> writes: > Hi Rasmus, > >>> Run it in gdb. Compile it without optimizations and -ggdb in CFLAGS and >>> then run it like so: >>> >>> $ cd path/to/emacs/src/ >>> $ gdb emacs >>> gdb> run >>> >>> Then you'll get C and lisp backtraces when emacs crashes. (It's >>> important to start emacs from its src directory, because that contains >>> some GDB setup scripts.) >> >> I run the program using gdb etc. as suggested above, but no message is >> echoed upon a crash. > > It shoult at least say that emacs has crashed somehow. > >> Do I have to issue some command to get a backtrace? > > Yes: bt full It says nothing. ┏━━━ ┃ (gdb) bt full ┃ No stack. ┃ ┃ Lisp Backtrace: ┃ Cannot access memory at address 0x7fffffffcb98 ┗━━━ I started Emacs with run --daemon. Emacs often crash after returning from suspend, although not in any deterministic sense. –Rasmus -- Sent from my Emacs ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gtk3, emacs 24 and gnome shell 2011-10-28 18:21 ` Rasmus Pank Roulund @ 2011-10-28 23:30 ` Michael Welsh Duggan 2011-10-29 8:55 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 30+ messages in thread From: Michael Welsh Duggan @ 2011-10-28 23:30 UTC (permalink / raw) To: Rasmus Pank Roulund; +Cc: Tassilo Horn, emacs-devel Rasmus Pank Roulund <rasmus@gmx.us> writes: > Tassilo Horn <tassilo@member.fsf.org> writes: > >> Hi Rasmus, >> >>>> Run it in gdb. Compile it without optimizations and -ggdb in CFLAGS and >>>> then run it like so: >>>> >>>> $ cd path/to/emacs/src/ >>>> $ gdb emacs >>>> gdb> run >>>> >>>> Then you'll get C and lisp backtraces when emacs crashes. (It's >>>> important to start emacs from its src directory, because that contains >>>> some GDB setup scripts.) >>> >>> I run the program using gdb etc. as suggested above, but no message is >>> echoed upon a crash. >> >> It shoult at least say that emacs has crashed somehow. >> >>> Do I have to issue some command to get a backtrace? >> >> Yes: bt full > > It says nothing. > > ┏━━━ > ┃ (gdb) bt full > ┃ No stack. > ┃ > ┃ Lisp Backtrace: > ┃ Cannot access memory at address 0x7fffffffcb98 > ┗━━━ > > I started Emacs with run --daemon. > > Emacs often crash after returning from suspend, although not in any > deterministic sense. In order to debug when running as a daemon, you need to add something like the following to your src/.gdbinit file: # Follow emacs when running using --daemon. We need to follow the # child of the daemonizing fork, and go back to following parents # shortly afterward. break main commands silent set follow-fork-mode child continue end break init_signals commands silent set follow-fork-mode parent continue end -- Michael Welsh Duggan (md5i@md5i.com) ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gtk3, emacs 24 and gnome shell 2011-10-28 23:30 ` Michael Welsh Duggan @ 2011-10-29 8:55 ` Eli Zaretskii 2011-10-29 15:45 ` Michael Welsh Duggan 2011-11-03 1:08 ` Rasmus 2011-11-03 1:08 ` Rasmus 2 siblings, 1 reply; 30+ messages in thread From: Eli Zaretskii @ 2011-10-29 8:55 UTC (permalink / raw) To: Michael Welsh Duggan; +Cc: tassilo, rasmus, emacs-devel > From: Michael Welsh Duggan <md5i@md5i.com> > Date: Fri, 28 Oct 2011 19:30:03 -0400 > Cc: Tassilo Horn <tassilo@member.fsf.org>, emacs-devel@gnu.org > > In order to debug when running as a daemon, you need to add something > like the following to your src/.gdbinit file: > > # Follow emacs when running using --daemon. We need to follow the > # child of the daemonizing fork, and go back to following parents > # shortly afterward. > break main > commands > silent > set follow-fork-mode child > continue > end > break init_signals > commands > silent > set follow-fork-mode parent > continue > end This should be a good addition to etc/DEBUG. However, I wonder: . would "tbreak" be a better choice? . why do you need to put a breakpoint with identical commands in two different functions? isn't the code path of becoming a daemon deterministic enough to have it only in `main'? ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gtk3, emacs 24 and gnome shell 2011-10-29 8:55 ` Eli Zaretskii @ 2011-10-29 15:45 ` Michael Welsh Duggan 2011-10-29 15:54 ` Michael Welsh Duggan 0 siblings, 1 reply; 30+ messages in thread From: Michael Welsh Duggan @ 2011-10-29 15:45 UTC (permalink / raw) To: Eli Zaretskii; +Cc: tassilo, rasmus, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: Michael Welsh Duggan <md5i@md5i.com> >> Date: Fri, 28 Oct 2011 19:30:03 -0400 >> Cc: Tassilo Horn <tassilo@member.fsf.org>, emacs-devel@gnu.org >> >> In order to debug when running as a daemon, you need to add something >> like the following to your src/.gdbinit file: >> >> # Follow emacs when running using --daemon. We need to follow the >> # child of the daemonizing fork, and go back to following parents >> # shortly afterward. >> break main >> commands >> silent >> set follow-fork-mode child >> continue >> end >> break init_signals >> commands >> silent >> set follow-fork-mode parent >> continue >> end > > This should be a good addition to etc/DEBUG. However, I wonder: > > . would "tbreak" be a better choice? I used tbreak first, but was irritated when I tried to re-run emacs from the debugger and > . why do you need to put a breakpoint with identical commands in two > different functions? isn't the code path of becoming a daemon > deterministic enough to have it only in `main'? The commands are not identical. The first one sets follow-fork-mode to child in order to follow emacs while it daemonizes itself, and the second one sets it back to parent so that after daemonizing, we stay in emacs whenever emacs forks and execs other processes. -- Michael Welsh Duggan (md5i@md5i.com) ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gtk3, emacs 24 and gnome shell 2011-10-29 15:45 ` Michael Welsh Duggan @ 2011-10-29 15:54 ` Michael Welsh Duggan 2011-11-03 4:42 ` Chris Moore 0 siblings, 1 reply; 30+ messages in thread From: Michael Welsh Duggan @ 2011-10-29 15:54 UTC (permalink / raw) To: Eli Zaretskii; +Cc: tassilo, rasmus, emacs-devel Michael Welsh Duggan <md5i@md5i.com> writes: > Eli Zaretskii <eliz@gnu.org> writes: > >> This should be a good addition to etc/DEBUG. However, I wonder: >> >> . would "tbreak" be a better choice? I used tbreak first, but was irritated when I tried to re-run emacs from the debugger and the breakpoints that I set up to make things work properly were gone. -- Michael Welsh Duggan (md5i@md5i.com) ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gtk3, emacs 24 and gnome shell 2011-10-29 15:54 ` Michael Welsh Duggan @ 2011-11-03 4:42 ` Chris Moore 0 siblings, 0 replies; 30+ messages in thread From: Chris Moore @ 2011-11-03 4:42 UTC (permalink / raw) To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 207 bytes --] I've recently had a couple of crashes running Emacs 23 in with gnome-shell on archlinux. emacs 23.3.a-3 gnome-shell 3.2.1-1 Since I started running Emacs in gdb maybe 24 hours ago it has stopped crashing. [-- Attachment #2: Type: text/html, Size: 300 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gtk3, emacs 24 and gnome shell 2011-10-28 23:30 ` Michael Welsh Duggan 2011-10-29 8:55 ` Eli Zaretskii @ 2011-11-03 1:08 ` Rasmus 2011-11-03 3:59 ` Eli Zaretskii 2011-11-03 1:08 ` Rasmus 2 siblings, 1 reply; 30+ messages in thread From: Rasmus @ 2011-11-03 1:08 UTC (permalink / raw) To: Michael Welsh Duggan Michael Welsh Duggan <md5i@md5i.com> writes: n> Rasmus Pank Roulund <rasmus@gmx.us> writes: > >> Tassilo Horn <tassilo@member.fsf.org> writes: >> >>> Hi Rasmus, >>> >>>>> Run it in gdb. Compile it without optimizations and -ggdb in >>>>> CFLAGS and >>>>> then run it like so: >>>>> >>>>> $ cd path/to/emacs/src/ >>>>> $ gdb emacs >>>>> gdb> run Here is a backtrace where Emacs seems to have broken. In this specific case my computer was playing back music while I was reading an article. When I got back Emacs had crashed. (gdb) bt full #0 abort () at emacs.c:386 No locals. #1 0x000000000044d214 in redisplay_internal () at xdisp.c:12644 w = 0x576e090 sw = 0x77 fr = 0x7fffffffb800 pending = 0 must_finish = 0 tlbufpos = { charpos = 1, bytepos = 12848690 } tlendpos = { charpos = 140737488336720, bytepos = 6182231 } number_of_visible_frames = 0 count = 32767 count1 = 0 sf = 0x7ffff7fcc4c8 polling_stopped_here = 0 old_frame = 20073637 consider_all_windows_p = 0 #2 0x000000000044ee42 in redisplay_preserve_echo_area (from_where=13) at xdisp.c:13385 No locals. #3 0x0000000000651732 in Fdelete_process (process=91333653) at process.c:758 p = 0x571a410 #4 0x000000000065e620 in kill_buffer_processes (buffer=12716498) at process.c:7085 tail = 70305974 proc = 91333653 #5 0x0000000000560e2a in shut_down_emacs (sig=0, no_x=0, stuff=12716498) at emacs.c:2068 No locals. #6 0x0000000000503d95 in x_connection_closed (dpy=0xff6830, error_message=0x7fffffffbc60 "X protocol error: BadMatch (invalid parameter attributes) on protocol request 42") at xterm.c:7799 dpyinfo = 0x10e4600 frame = 20073637 tail = 12716498 idx = 3 #7 0x00000000005042cd in x_error_quitter (display=0xff6830, event=0x7fffffffbf10) at xterm.c:7893 buf = "BadMatch (invalid parameter attributes)", '\000' <repeats 216 times> buf1 = "X protocol error: BadMatch (invalid parameter attributes) on protocol request 42", '\000' <repeats 23 times>"\200, \377?", '\000' <repeats 12 times>, "0\215˿", '\000' <repeats 16 times>"\377, \000\000\000\000\000\377\377\377\377\377\377\377\377\377\377\000\000\377\377\000\000-mnemonics\000Gtk/V-mne\000\000\000\000\022\000\000\000\000\000\000\000K\000\000\000\000\000\000\000\240\311\373\367\377\177\000\000\006\062\003g\000\000\000\000\002u\336\367\377\177\000\000\006\000\000\000\000\000\000\000\000\277\377\377\377\177\000\000\377\377\377\377\000\000\000\000\264.\342\364\377\177\000\000о\377\377\377\177"... #8 0x000000000050422e in x_error_handler (display=0xff6830, event=0x7fffffffbf10) at xterm.c:7863 No locals. #9 0x00007ffff4e68083 in _XError () from /usr/lib/libX11.so.6 No symbol table info available. #10 0x00007ffff4e64ed1 in ?? () from /usr/lib/libX11.so.6 No symbol table info available. #11 0x00007ffff4e64f15 in ?? () from /usr/lib/libX11.so.6 No symbol table info available. #12 0x00007ffff4e65d20 in _XReply () from /usr/lib/libX11.so.6 No symbol table info available. #13 0x00007ffff4e5b000 in XQueryPointer () from /usr/lib/libX11.so.6 No symbol table info available. ---Type <return> to continue, or q <return> to quit--- #14 0x00007ffff7552fef in ?? () from /usr/lib/libgdk-3.so.0 No symbol table info available. #15 0x00007ffff756cb23 in ?? () from /usr/lib/libgdk-3.so.0 No symbol table info available. #16 0x00007ffff7547f9b in gdk_window_get_device_position () from /usr/lib/libgdk-3.so.0 No symbol table info available. #17 0x00007ffff75532aa in ?? () from /usr/lib/libgdk-3.so.0 No symbol table info available. #18 0x00007ffff7a32832 in ?? () from /usr/lib/libgtk-3.so.0 No symbol table info available. #19 0x00007ffff78e8828 in ?? () from /usr/lib/libgtk-3.so.0 No symbol table info available. #20 0x00007ffff65f80e4 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #21 0x00007ffff6609e9f in ?? () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #22 0x00007ffff66134c3 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #23 0x00007ffff6613892 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #24 0x00007ffff7a152b9 in ?? () from /usr/lib/libgtk-3.so.0 No symbol table info available. #25 0x00007ffff78e8683 in gtk_main_do_event () from /usr/lib/libgtk-3.so.0 No symbol table info available. #26 0x00007ffff7561512 in ?? () from /usr/lib/libgdk-3.so.0 No symbol table info available. #27 0x00007ffff63387fd in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #28 0x00007ffff6338ff8 in ?? () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #29 0x00007ffff63391c9 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #30 0x00007ffff78e78a5 in gtk_main_iteration () from /usr/lib/libgtk-3.so.0 No symbol table info available. #31 0x000000000050269e in XTread_socket (terminal=0x10e1450, expected=1, hold_quit=0x7fffffffc9a0) at xterm.c:7157 count = 0 event_found = 0 #32 0x000000000056e783 in read_avail_input (expected=1) at keyboard.c:6821 nr = 1 hold_quit = { kind = NO_EVENT, code = 0, part = scroll_bar_above_handle, modifiers = 0, x = 0, y = 0, timestamp = 0, padding = {0x0, 0x0}, frame_or_window = 0, arg = 0 } next = 0x0 nread = 0 err = 0 t = 0x10e1450 ---Type <return> to continue, or q <return> to quit--- #33 0x000000000056f0dd in handle_async_input () at keyboard.c:7149 nread = 32767 #34 0x000000000056f0fc in process_pending_signals () at keyboard.c:7165 No locals. #35 0x0000000000658785 in wait_reading_process_output (time_limit=0, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=12716498, wait_proc=0x0, just_wait_proc=0) at process.c:4332 timeout_reduced_for_timers = 0 channel = 62 nfds = 1 Available = { fds_bits = {128, 0 <repeats 15 times>} } Writeok = { fds_bits = {0 <repeats 16 times>} } check_write = 1 check_delay = 3 no_avail = 0 xerrno = 11 proc = 66387093 timeout = { tv_sec = 0, tv_usec = 0 } end_time = { tv_sec = 0, tv_usec = 5666740 } wait_channel = -1 got_some_input = 1 count = 2 #36 0x000000000056854a in kbd_buffer_get_event (kbp=0x7fffffffcf80, used_mouse_menu=0x7fffffffd594, end_time=0x0) at keyboard.c:3850 c = 0 obj = 0 #37 0x0000000000565f2e in read_char (commandflag=1, nmaps=7, maps=0x7fffffffd300, prev_event=12716498, used_mouse_menu=0x7fffffffd594, end_time=0x0) at keyboard.c:2796 kb = 0x578ddc0 c = 12716498 jmpcount = 2 local_getcjmp = {{ __jmpbuf = {0, 1489677321743271225, 4274192, 140737488347408, 0, 0, 1489677321384658233, -1489676684761332423}, __mask_was_saved = 0, __saved_mask = { __val = {274887369285, 64, 3, 12716498, 140737488334416, 12716498, 16109281, 3, 140737488347408, 140737488335024, 34048, 93423686, 1489677321789408569, 4274192, 140737488347408, 0} } }} save_jump = {{ __jmpbuf = {12716498, 1489677320759706937, 3, 140737488347408, 0, 0, 1489677320342373689, -1489676684761332423}, __mask_was_saved = 0, __saved_mask = { __val = {12839202, 40237510, 16109857, 13754082, 8, 40237510, 274887369285, 64, 3, 12716498, 140737488334416, 12716498, 16109281, 3, 140737488347408, 140737488335024} } }} key_already_recorded = 0 tem = 12750578 save = 140737488343696 previous_echo_area_message = 12716498 ---Type <return> to continue, or q <return> to quit--- also_record = 12716498 reread = 0 gcpro1 = { next = 0x1ffffd330, var = 0x5356a15, nvars = 12716498 } gcpro2 = { next = 0x0, var = 0x1, nvars = 140737488342976 } polling_stopped_here = 1 orig_kboard = 0x10e6aa0 #38 0x0000000000573849 in read_key_sequence (keybuf=0x7fffffffd800, bufsize=30, prompt=12716498, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9290 interrupted_kboard = 0x10e6aa0 interrupted_frame = 0x1324ca0 key = 92096341 used_mouse_menu = 0 echo_local_start = 0 last_real_key_start = 0 keys_local_start = 0 local_first_binding = 0 from_string = 12716498 count = 2 t = 0 echo_start = 0 keys_start = 0 nmaps = 7 nmaps_allocated = 7 defs = 0x7fffffffd2b0 submaps = 0x7fffffffd300 orig_local_map = 26498966 orig_keymap = 12716498 localized_local_map = 0 first_binding = 0 first_unbound = 31 mock_input = 0 fkey = { parent = 18987686, map = 18987686, start = 0, end = 0 } keytran = { parent = 12695974, map = 12695974, start = 0, end = 0 } indec = { parent = 18987670, map = 18987670, start = 0, end = 0 ---Type <return> to continue, or q <return> to quit--- } shift_translated = 0 delayed_switch_frame = 12716498 original_uppercase = 3026 original_uppercase_position = -1 dummyflag = 0 starting_buffer = 0x5356a10 fake_prefixed_keys = 12716498 outer_gcpro1 = { next = 0x57d4755, var = 0x100000001, nvars = 0 } #39 0x000000000056333a in command_loop_1 () at keyboard.c:1447 cmd = 12769746 keybuf = {13433074, 24, 3070, 16, 12856386, 140737488345344, 12716546, 56453718, 140737488345184, 5228472, 4307683794, 20073632, 9382806, 12769698, 140737488345072, 9410481, 4294956768, 12716498, 12716498, 9382817, 140737488345312, 5647192, 140737488345344, 56453718, 0, 20073632, 140737488345376, 0, 140737488345424, 5646701} i = 1 prev_modiff = 2 prev_buffer = 0x57d4750 already_adjusted = 0 #40 0x00000000005fe9ff in internal_condition_case (bfun=0x562f55 <command_loop_1>, handlers=12768690, hfun=0x56283d <cmd_error>) at eval.c:1499 val = 0 c = { tag = 12716498, val = 12716498, next = 0x7fffffffdb30, gcpro = 0x0, jmp = {{ __jmpbuf = {0, 1489677322020095289, 4274192, 140737488347408, 0, 0, 1489677322131244345, -1489676756818950855}, __mask_was_saved = 0, __saved_mask = { __val = {16957067316890600761, 0, 140737354130504, 13194630, 0, 9329144, 0, 0, 0, 0, 140737351954612, 140733193388033, 0, 0, 140737265632968, 140737353862184} } }}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0x0 } h = { handler = 12768690, var = 12716498, chosen_clause = 12716546, tag = 0x7fffffffd9b0, next = 0x0 } #41 0x0000000000562c44 in command_loop_2 (ignore=12716498) at keyboard.c:1158 val = 0 #42 0x00000000005fe389 in internal_catch (tag=12764482, func=0x562c1e <command_loop_2>, arg=12716498) at eval.c:1256 c = { tag = 12764482, ---Type <return> to continue, or q <return> to quit--- val = 12716498, next = 0x0, gcpro = 0x0, jmp = {{ __jmpbuf = {0, 1489677321967666489, 4274192, 140737488347408, 0, 0, 1489677322062038329, -1489676757153708743}, __mask_was_saved = 0, __saved_mask = { __val = {6183610, 144, 4294967296, 0, 0, 12114560, 12744544, 384, 0, 140737488346128, 12942256, 14, 0, 4274192, 140737488347408, 140737488346208} } }}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0x0 } #43 0x0000000000562bf7 in command_loop () at keyboard.c:1137 No locals. #44 0x0000000000562381 in recursive_edit_1 () at keyboard.c:757 count = 1 val = 12716498 #45 0x0000000000562524 in Frecursive_edit () at keyboard.c:821 count = 0 buffer = 12716498 #46 0x00000000005605e2 in main (argc=1, argv=0x7fffffffe118) at emacs.c:1706 dummy = 4234711 stack_bottom_variable = 0 '\000' do_initial_setlocale = 1 skip_args = 0 rlim = { rlim_cur = 8720000, rlim_max = 18446744073709551615 } no_loadup = 0 junk = 0x0 dname_arg = 0x0 ch_to_dir = 0x7ffff2b92c80 "" -- Sent from my Emacs ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gtk3, emacs 24 and gnome shell 2011-11-03 1:08 ` Rasmus @ 2011-11-03 3:59 ` Eli Zaretskii 2011-11-04 1:02 ` Rasmus 0 siblings, 1 reply; 30+ messages in thread From: Eli Zaretskii @ 2011-11-03 3:59 UTC (permalink / raw) To: Rasmus; +Cc: md5i, emacs-devel > From: Rasmus <rasmus@gmx.us> > Date: Thu, 03 Nov 2011 01:08:19 +0000 > > Here is a backtrace where Emacs seems to have broken. In this specific > case my computer was playing back music while I was reading an article. > When I got back Emacs had crashed. > > (gdb) bt full > #0 abort () at emacs.c:386 > No locals. > #1 0x000000000044d214 in redisplay_internal () at xdisp.c:12644 I hope you still have this under GDB. If so, please do (gdb) frame 1 (gdb) print selected_frame (gdb) xtype If "xtype" says it's a symbol, then type (gdb) xsymbol ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gtk3, emacs 24 and gnome shell 2011-11-03 3:59 ` Eli Zaretskii @ 2011-11-04 1:02 ` Rasmus 0 siblings, 0 replies; 30+ messages in thread From: Rasmus @ 2011-11-04 1:02 UTC (permalink / raw) To: Eli Zaretskii; +Cc: md5i, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: Rasmus <rasmus@gmx.us> >> Date: Thu, 03 Nov 2011 01:08:19 +0000 >> >> Here is a backtrace where Emacs seems to have broken. In this >> specific >> case my computer was playing back music while I was reading an >> article. >> When I got back Emacs had crashed. >> >> (gdb) bt full >> #0 abort () at emacs.c:386 >> No locals. >> #1 0x000000000044d214 in redisplay_internal () at xdisp.c:12644 > > I hope you still have this under GDB. If so, please do > > (gdb) frame 1 > (gdb) print selected_frame > (gdb) xtype > > If "xtype" says it's a symbol, then type > > (gdb) xsymbol I am afraid I don't. My computer ran out of power during a lecture. I will see if I can get the details later. –Rasmus -- Sent from my Emacs ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gtk3, emacs 24 and gnome shell 2011-10-28 23:30 ` Michael Welsh Duggan 2011-10-29 8:55 ` Eli Zaretskii 2011-11-03 1:08 ` Rasmus @ 2011-11-03 1:08 ` Rasmus 2 siblings, 0 replies; 30+ messages in thread From: Rasmus @ 2011-11-03 1:08 UTC (permalink / raw) To: Tassilo Horn; +Cc: emacs-devel Michael Welsh Duggan <md5i@md5i.com> writes: n> Rasmus Pank Roulund <rasmus@gmx.us> writes: > >> Tassilo Horn <tassilo@member.fsf.org> writes: >> >>> Hi Rasmus, >>> >>>>> Run it in gdb. Compile it without optimizations and -ggdb in >>>>> CFLAGS and >>>>> then run it like so: >>>>> >>>>> $ cd path/to/emacs/src/ >>>>> $ gdb emacs >>>>> gdb> run Here is a backtrace where Emacs seems to have broken. In this specific case my computer was playing back music while I was reading an article. When I got back Emacs had crashed. (gdb) bt full #0 abort () at emacs.c:386 No locals. #1 0x000000000044d214 in redisplay_internal () at xdisp.c:12644 w = 0x576e090 sw = 0x77 fr = 0x7fffffffb800 pending = 0 must_finish = 0 tlbufpos = { charpos = 1, bytepos = 12848690 } tlendpos = { charpos = 140737488336720, bytepos = 6182231 } number_of_visible_frames = 0 count = 32767 count1 = 0 sf = 0x7ffff7fcc4c8 polling_stopped_here = 0 old_frame = 20073637 consider_all_windows_p = 0 #2 0x000000000044ee42 in redisplay_preserve_echo_area (from_where=13) at xdisp.c:13385 No locals. #3 0x0000000000651732 in Fdelete_process (process=91333653) at process.c:758 p = 0x571a410 #4 0x000000000065e620 in kill_buffer_processes (buffer=12716498) at process.c:7085 tail = 70305974 proc = 91333653 #5 0x0000000000560e2a in shut_down_emacs (sig=0, no_x=0, stuff=12716498) at emacs.c:2068 No locals. #6 0x0000000000503d95 in x_connection_closed (dpy=0xff6830, error_message=0x7fffffffbc60 "X protocol error: BadMatch (invalid parameter attributes) on protocol request 42") at xterm.c:7799 dpyinfo = 0x10e4600 frame = 20073637 tail = 12716498 idx = 3 #7 0x00000000005042cd in x_error_quitter (display=0xff6830, event=0x7fffffffbf10) at xterm.c:7893 buf = "BadMatch (invalid parameter attributes)", '\000' <repeats 216 times> buf1 = "X protocol error: BadMatch (invalid parameter attributes) on protocol request 42", '\000' <repeats 23 times>"\200, \377?", '\000' <repeats 12 times>, "0\215˿", '\000' <repeats 16 times>"\377, \000\000\000\000\000\377\377\377\377\377\377\377\377\377\377\000\000\377\377\000\000-mnemonics\000Gtk/V-mne\000\000\000\000\022\000\000\000\000\000\000\000K\000\000\000\000\000\000\000\240\311\373\367\377\177\000\000\006\062\003g\000\000\000\000\002u\336\367\377\177\000\000\006\000\000\000\000\000\000\000\000\277\377\377\377\177\000\000\377\377\377\377\000\000\000\000\264.\342\364\377\177\000\000о\377\377\377\177"... #8 0x000000000050422e in x_error_handler (display=0xff6830, event=0x7fffffffbf10) at xterm.c:7863 No locals. #9 0x00007ffff4e68083 in _XError () from /usr/lib/libX11.so.6 No symbol table info available. #10 0x00007ffff4e64ed1 in ?? () from /usr/lib/libX11.so.6 No symbol table info available. #11 0x00007ffff4e64f15 in ?? () from /usr/lib/libX11.so.6 No symbol table info available. #12 0x00007ffff4e65d20 in _XReply () from /usr/lib/libX11.so.6 No symbol table info available. #13 0x00007ffff4e5b000 in XQueryPointer () from /usr/lib/libX11.so.6 No symbol table info available. ---Type <return> to continue, or q <return> to quit--- #14 0x00007ffff7552fef in ?? () from /usr/lib/libgdk-3.so.0 No symbol table info available. #15 0x00007ffff756cb23 in ?? () from /usr/lib/libgdk-3.so.0 No symbol table info available. #16 0x00007ffff7547f9b in gdk_window_get_device_position () from /usr/lib/libgdk-3.so.0 No symbol table info available. #17 0x00007ffff75532aa in ?? () from /usr/lib/libgdk-3.so.0 No symbol table info available. #18 0x00007ffff7a32832 in ?? () from /usr/lib/libgtk-3.so.0 No symbol table info available. #19 0x00007ffff78e8828 in ?? () from /usr/lib/libgtk-3.so.0 No symbol table info available. #20 0x00007ffff65f80e4 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #21 0x00007ffff6609e9f in ?? () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #22 0x00007ffff66134c3 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #23 0x00007ffff6613892 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #24 0x00007ffff7a152b9 in ?? () from /usr/lib/libgtk-3.so.0 No symbol table info available. #25 0x00007ffff78e8683 in gtk_main_do_event () from /usr/lib/libgtk-3.so.0 No symbol table info available. #26 0x00007ffff7561512 in ?? () from /usr/lib/libgdk-3.so.0 No symbol table info available. #27 0x00007ffff63387fd in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #28 0x00007ffff6338ff8 in ?? () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #29 0x00007ffff63391c9 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #30 0x00007ffff78e78a5 in gtk_main_iteration () from /usr/lib/libgtk-3.so.0 No symbol table info available. #31 0x000000000050269e in XTread_socket (terminal=0x10e1450, expected=1, hold_quit=0x7fffffffc9a0) at xterm.c:7157 count = 0 event_found = 0 #32 0x000000000056e783 in read_avail_input (expected=1) at keyboard.c:6821 nr = 1 hold_quit = { kind = NO_EVENT, code = 0, part = scroll_bar_above_handle, modifiers = 0, x = 0, y = 0, timestamp = 0, padding = {0x0, 0x0}, frame_or_window = 0, arg = 0 } next = 0x0 nread = 0 err = 0 t = 0x10e1450 ---Type <return> to continue, or q <return> to quit--- #33 0x000000000056f0dd in handle_async_input () at keyboard.c:7149 nread = 32767 #34 0x000000000056f0fc in process_pending_signals () at keyboard.c:7165 No locals. #35 0x0000000000658785 in wait_reading_process_output (time_limit=0, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=12716498, wait_proc=0x0, just_wait_proc=0) at process.c:4332 timeout_reduced_for_timers = 0 channel = 62 nfds = 1 Available = { fds_bits = {128, 0 <repeats 15 times>} } Writeok = { fds_bits = {0 <repeats 16 times>} } check_write = 1 check_delay = 3 no_avail = 0 xerrno = 11 proc = 66387093 timeout = { tv_sec = 0, tv_usec = 0 } end_time = { tv_sec = 0, tv_usec = 5666740 } wait_channel = -1 got_some_input = 1 count = 2 #36 0x000000000056854a in kbd_buffer_get_event (kbp=0x7fffffffcf80, used_mouse_menu=0x7fffffffd594, end_time=0x0) at keyboard.c:3850 c = 0 obj = 0 #37 0x0000000000565f2e in read_char (commandflag=1, nmaps=7, maps=0x7fffffffd300, prev_event=12716498, used_mouse_menu=0x7fffffffd594, end_time=0x0) at keyboard.c:2796 kb = 0x578ddc0 c = 12716498 jmpcount = 2 local_getcjmp = {{ __jmpbuf = {0, 1489677321743271225, 4274192, 140737488347408, 0, 0, 1489677321384658233, -1489676684761332423}, __mask_was_saved = 0, __saved_mask = { __val = {274887369285, 64, 3, 12716498, 140737488334416, 12716498, 16109281, 3, 140737488347408, 140737488335024, 34048, 93423686, 1489677321789408569, 4274192, 140737488347408, 0} } }} save_jump = {{ __jmpbuf = {12716498, 1489677320759706937, 3, 140737488347408, 0, 0, 1489677320342373689, -1489676684761332423}, __mask_was_saved = 0, __saved_mask = { __val = {12839202, 40237510, 16109857, 13754082, 8, 40237510, 274887369285, 64, 3, 12716498, 140737488334416, 12716498, 16109281, 3, 140737488347408, 140737488335024} } }} key_already_recorded = 0 tem = 12750578 save = 140737488343696 previous_echo_area_message = 12716498 ---Type <return> to continue, or q <return> to quit--- also_record = 12716498 reread = 0 gcpro1 = { next = 0x1ffffd330, var = 0x5356a15, nvars = 12716498 } gcpro2 = { next = 0x0, var = 0x1, nvars = 140737488342976 } polling_stopped_here = 1 orig_kboard = 0x10e6aa0 #38 0x0000000000573849 in read_key_sequence (keybuf=0x7fffffffd800, bufsize=30, prompt=12716498, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9290 interrupted_kboard = 0x10e6aa0 interrupted_frame = 0x1324ca0 key = 92096341 used_mouse_menu = 0 echo_local_start = 0 last_real_key_start = 0 keys_local_start = 0 local_first_binding = 0 from_string = 12716498 count = 2 t = 0 echo_start = 0 keys_start = 0 nmaps = 7 nmaps_allocated = 7 defs = 0x7fffffffd2b0 submaps = 0x7fffffffd300 orig_local_map = 26498966 orig_keymap = 12716498 localized_local_map = 0 first_binding = 0 first_unbound = 31 mock_input = 0 fkey = { parent = 18987686, map = 18987686, start = 0, end = 0 } keytran = { parent = 12695974, map = 12695974, start = 0, end = 0 } indec = { parent = 18987670, map = 18987670, start = 0, end = 0 ---Type <return> to continue, or q <return> to quit--- } shift_translated = 0 delayed_switch_frame = 12716498 original_uppercase = 3026 original_uppercase_position = -1 dummyflag = 0 starting_buffer = 0x5356a10 fake_prefixed_keys = 12716498 outer_gcpro1 = { next = 0x57d4755, var = 0x100000001, nvars = 0 } #39 0x000000000056333a in command_loop_1 () at keyboard.c:1447 cmd = 12769746 keybuf = {13433074, 24, 3070, 16, 12856386, 140737488345344, 12716546, 56453718, 140737488345184, 5228472, 4307683794, 20073632, 9382806, 12769698, 140737488345072, 9410481, 4294956768, 12716498, 12716498, 9382817, 140737488345312, 5647192, 140737488345344, 56453718, 0, 20073632, 140737488345376, 0, 140737488345424, 5646701} i = 1 prev_modiff = 2 prev_buffer = 0x57d4750 already_adjusted = 0 #40 0x00000000005fe9ff in internal_condition_case (bfun=0x562f55 <command_loop_1>, handlers=12768690, hfun=0x56283d <cmd_error>) at eval.c:1499 val = 0 c = { tag = 12716498, val = 12716498, next = 0x7fffffffdb30, gcpro = 0x0, jmp = {{ __jmpbuf = {0, 1489677322020095289, 4274192, 140737488347408, 0, 0, 1489677322131244345, -1489676756818950855}, __mask_was_saved = 0, __saved_mask = { __val = {16957067316890600761, 0, 140737354130504, 13194630, 0, 9329144, 0, 0, 0, 0, 140737351954612, 140733193388033, 0, 0, 140737265632968, 140737353862184} } }}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0x0 } h = { handler = 12768690, var = 12716498, chosen_clause = 12716546, tag = 0x7fffffffd9b0, next = 0x0 } #41 0x0000000000562c44 in command_loop_2 (ignore=12716498) at keyboard.c:1158 val = 0 #42 0x00000000005fe389 in internal_catch (tag=12764482, func=0x562c1e <command_loop_2>, arg=12716498) at eval.c:1256 c = { tag = 12764482, ---Type <return> to continue, or q <return> to quit--- val = 12716498, next = 0x0, gcpro = 0x0, jmp = {{ __jmpbuf = {0, 1489677321967666489, 4274192, 140737488347408, 0, 0, 1489677322062038329, -1489676757153708743}, __mask_was_saved = 0, __saved_mask = { __val = {6183610, 144, 4294967296, 0, 0, 12114560, 12744544, 384, 0, 140737488346128, 12942256, 14, 0, 4274192, 140737488347408, 140737488346208} } }}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0x0 } #43 0x0000000000562bf7 in command_loop () at keyboard.c:1137 No locals. #44 0x0000000000562381 in recursive_edit_1 () at keyboard.c:757 count = 1 val = 12716498 #45 0x0000000000562524 in Frecursive_edit () at keyboard.c:821 count = 0 buffer = 12716498 #46 0x00000000005605e2 in main (argc=1, argv=0x7fffffffe118) at emacs.c:1706 dummy = 4234711 stack_bottom_variable = 0 '\000' do_initial_setlocale = 1 skip_args = 0 rlim = { rlim_cur = 8720000, rlim_max = 18446744073709551615 } no_loadup = 0 junk = 0x0 dname_arg = 0x0 ch_to_dir = 0x7ffff2b92c80 "" -- Sent from my Emacs ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gtk3, emacs 24 and gnome shell
@ 2011-12-13 21:00 Benjamin Redelings
2011-12-14 7:07 ` Jan D.
0 siblings, 1 reply; 30+ messages in thread
From: Benjamin Redelings @ 2011-12-13 21:00 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1687 bytes --]
Tassilo Horn wrote:
> Andrea Crotti<address@hidden> writes:
>
> Hi Andrea,
>
> >/ Using gnome3 with the gnome shell on archLinux and a self-compiled/
> >/ version of emacs 24 compiled against gtk3, pressing Ctrl-z on the/
> >/ emacs makes it unusable./
>
> I've unset C-z, but that's `suspend-frame', right? If I do
>
> M-x suspend-frame RET
>
> (or C-z in emacs -Q) the emacs frame is minimized, and I can get it back
> via the GNOME 3 Overview or the application switcher. It's as usable as
> it was before. So it seems to work just as expected.
I have the same problem that Andrea had. If I use C-z (or M-x
suspend-frame) then
(1) the window is minimized
(2) I can get it back by clicking on the emacs icon in the overview
(3) the menus work, but I cannot enter or edit any text any more.
+ I can even select checkboxes in the menus, and I can save the file
from the "File" menu.
+ However, the text-entry area is frozen.
- The scroll-bar will not scroll.
- I can right-click on the text-entry area and change the current
buffer from *scratch* to *Messages*, but the status bar is not updated
to reflect the changes to *Messages*. Interestingly, the
'Lisp-interaction' menu item disappears, so I think that the buffer
really is changed to *Messages*, but the buffer is just not displayed.
If I click on the minimize button on the frame decoration, emacs is
minimized, and is usable after the emacs icon is clicked on again.
Using -Q makes no difference.
I'm using emacs 23.3 and gnome-shell 3.2.1.
Did you attempt to enter any text after you "got it back"? If so, then
perhaps this means that emacs 24 does not suffer from this problem.
-BenRI
[-- Attachment #2: Type: text/html, Size: 2174 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: gtk3, emacs 24 and gnome shell 2011-12-13 21:00 Benjamin Redelings @ 2011-12-14 7:07 ` Jan D. 0 siblings, 0 replies; 30+ messages in thread From: Jan D. @ 2011-12-14 7:07 UTC (permalink / raw) To: Benjamin Redelings; +Cc: emacs-devel Hello. This has been fixed in trunk (i.e. upcoming 24.1). It wont be fixed in Emacs23 as no more 23 releases are planned. Please try the tunk, you can get it by following the instuctions at http://savannah.gnu.org/bzr/?group=emacs. Jan D. Benjamin Redelings skrev 2011-12-13 22:00: > Tassilo Horn wrote: >> Andrea Crotti<address@hidden> writes: >> >> Hi Andrea, >> >> >/ Using gnome3 with the gnome shell on archLinux and a self-compiled/ >> >/ version of emacs 24 compiled against gtk3, pressing Ctrl-z on the/ >> >/ emacs makes it unusable./ >> >> I've unset C-z, but that's `suspend-frame', right? If I do >> >> M-x suspend-frame RET >> >> (or C-z in emacs -Q) the emacs frame is minimized, and I can get it back >> via the GNOME 3 Overview or the application switcher. It's as usable as >> it was before. So it seems to work just as expected. > I have the same problem that Andrea had. If I use C-z (or M-x > suspend-frame) then > (1) the window is minimized > (2) I can get it back by clicking on the emacs icon in the overview > (3) the menus work, but I cannot enter or edit any text any more. > + I can even select checkboxes in the menus, and I can save the file > from the "File" menu. > + However, the text-entry area is frozen. > - The scroll-bar will not scroll. > - I can right-click on the text-entry area and change the current buffer > from *scratch* to *Messages*, but the status bar is not updated to > reflect the changes to *Messages*. Interestingly, the 'Lisp-interaction' > menu item disappears, so I think that the buffer really is changed to > *Messages*, but the buffer is just not displayed. > > If I click on the minimize button on the frame decoration, emacs is > minimized, and is usable after the emacs icon is clicked on again. > > Using -Q makes no difference. > > I'm using emacs 23.3 and gnome-shell 3.2.1. > > Did you attempt to enter any text after you "got it back"? If so, then > perhaps this means that emacs 24 does not suffer from this problem. > > -BenRI ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2011-12-14 7:07 UTC | newest] Thread overview: 30+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-10-24 12:06 gtk3, emacs 24 and gnome shell Andrea Crotti 2011-10-24 13:51 ` Tassilo Horn 2011-10-24 14:23 ` Andrea Crotti 2011-10-24 15:34 ` Tassilo Horn 2011-10-24 23:19 ` Rasmus 2011-10-25 4:30 ` Chong Yidong 2011-10-25 7:06 ` Tassilo Horn 2011-10-25 8:23 ` Rasmus 2011-10-25 8:52 ` Tassilo Horn 2011-10-27 20:46 ` Rasmus 2011-10-27 22:01 ` bug#9893: " Paul Eggert 2011-10-27 22:01 ` Paul Eggert 2011-10-27 22:42 ` bug#9893: " Paul Eggert 2011-10-28 21:02 ` Jan Djärv 2011-10-30 17:26 ` Jan Djärv 2011-10-31 20:13 ` Paul Eggert 2011-10-28 6:18 ` Tassilo Horn 2011-10-28 6:58 ` Eli Zaretskii 2011-10-28 18:21 ` Rasmus Pank Roulund 2011-10-28 23:30 ` Michael Welsh Duggan 2011-10-29 8:55 ` Eli Zaretskii 2011-10-29 15:45 ` Michael Welsh Duggan 2011-10-29 15:54 ` Michael Welsh Duggan 2011-11-03 4:42 ` Chris Moore 2011-11-03 1:08 ` Rasmus 2011-11-03 3:59 ` Eli Zaretskii 2011-11-04 1:02 ` Rasmus 2011-11-03 1:08 ` Rasmus -- strict thread matches above, loose matches on Subject: below -- 2011-12-13 21:00 Benjamin Redelings 2011-12-14 7:07 ` Jan D.
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.