unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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           ` Paul Eggert
  2011-10-28  6:18           ` Tassilo Horn
  0 siblings, 2 replies; 25+ 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] 25+ messages in thread

* Re: gtk3, emacs 24 and gnome shell
  2011-10-27 20:46         ` Rasmus
@ 2011-10-27 22:01           ` Paul Eggert
  2011-10-28  6:18           ` Tassilo Horn
  1 sibling, 0 replies; 25+ 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] 25+ messages in thread

* Re: gtk3, emacs 24 and gnome shell
  2011-10-27 20:46         ` Rasmus
  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
  1 sibling, 2 replies; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ messages in thread

end of thread, other threads:[~2011-12-14  7:07 UTC | newest]

Thread overview: 25+ 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           ` 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).