23.0.50; frozen frame after C-x 5 0

23.0.50; frozen frame after C-x 5 0

[Tassilo Horn]

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Since the multi-tty merge I start emacs as a detached server in screen.
Here's a command line to reproduce the problem:

  screen -d -m -S test emacs -nw --eval "(setq server-name \"test\")" \
         -Q --funcall server-start

Now I connect to it with

  emacsclient -s test

which opens a new X11 frame.  If I hit `C-x 5 0' to close this frame, it
freezes.  Neither are redisplays performed in it nor does it doesn't
close.  The menu bar is inaccessible, too.

A subsequent

  emacsclient -s test

closes the frozen frame and pops up a new one, which is displayed only
for a fraction of a second before it vanishes, too.  So from this point
clients with X11 frames are non-functional.

But I can connect using a client in a terminal:

  emacsclient -s test -t

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/usr/share/emacs/23.0.50/etc/DEBUG for instructions.


In GNU Emacs 23.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.10.14, multi-tty)
 of 2007-09-06 on baldur
Windowing system distributor `The X.Org Foundation', version 11.0.10300000
configured using `configure  '--prefix=/usr' '--host=i686-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--program-suffix=-emacs-23' '--infodir=/usr/share/info/emacs-23' '--without-carbon' '--with-sound' '--with-x' '--with-toolkit-scroll-bars' '--with-jpeg' '--with-tiff' '--with-gif' '--with-png' '--with-xpm' '--with-rsvg' '--with-x-toolkit=gtk' '--without-hesiod' '--with-gpm' '--build=i686-pc-linux-gnu' 'build_alias=i686-pc-linux-gnu' 'host_alias=i686-pc-linux-gnu' 'CFLAGS=-march=i686 -mtune=prescott -O2 -pipe''

Important settings:
  value of $LC_ALL: en_US.UTF-8
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Major mode: Group

Minor modes in effect:
  gnus-topic-mode: t
  gnus-undo-mode: t
  shell-dirtrack-mode: t
  recentf-mode: t
  partial-completion-mode: t
  iswitchb-mode: t
  window-number-meta-mode: t
  window-number-mode: t
  savehist-mode: t
  exec-abbrev-cmd-mode: t
  show-paren-mode: t
  global-hl-line-mode: t
  which-function-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
e m a <tab> <return> C-s c u s t C-s <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <left> C-x C-e C-x b <return> 
<down> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> SPC <down> 
<down> SPC SPC <down> SPC SPC <down> SPC <down> <down> 
<down> <down> <down> <down> <down> <down> C-l <up> 
<up> <up> <up> <up> <up> <up> <up> SPC <down> <down> 
SPC SPC <down> SPC <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> SPC 
<down> <down> <up> SPC <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <up> 
<up> <return> <up> <up> <up> <up> <up> <up> <down> 
<return> <up> <up> <down> <return> <down> <down> <down> 
<down> <return> <down> <up> <up> <up> <up> <up> <up> 
<up> <up> SPC <up> <up> <down> SPC <down> <down> <down> 
<down> <down> <down> <down> <down> <return> <up> <up> 
<up> <up> <up> <up> <up> <up> SPC <up> <up> <down> 
<up> SPC <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <up> <up> 
<up> <up> <up> <up> <up> <up> <return> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <return> C-x b p 
l a <return> <up> <up> <up> <up> <up> <up> <up> <return> 
C-x b g r <return> l s C-c g M-x <up> <up> <up> <up> 
<return>

Recent messages:
20070906T085756.659> Fetching articles for nnimap+Fastmail:INBOX...
20070906T085756.913> Fetching headers for nnimap+Fastmail:INBOX.Junk Mail...
20070906T085757.466> Fetching articles for nnimap+Fastmail:INBOX.Junk Mail...
20070906T085758.527> Fetching headers for nnimap+Fastmail:INBOX.mailinglists.ding...
20070906T085759.707> Fetching articles for nnimap+Fastmail:INBOX.mailinglists.ding...
20070906T085801.399> Fetching headers for nnimap+Fastmail:INBOX.mailinglists.stumpwm-devel...
20070906T085801.782> Fetching articles for nnimap+Fastmail:INBOX.mailinglists.stumpwm-devel...
20070906T085802.112> Fetching headers for nnimap+Fastmail:INBOX.mailinglists.tracker...
20070906T085802.656> Fetching articles for nnimap+Fastmail:INBOX.mailinglists.tracker...
20070906T085804.334> Finished fetching articles into the Gnus agent

-- 
            Wenn Windows die Lösung ist, kann ich dann bitte
                       das Problem zurück haben?

Re: 23.0.50; frozen frame after C-x 5 0

[Leo]

On 2007-09-06 08:05 +0100, Tassilo Horn wrote:
> Since the multi-tty merge I start emacs as a detached server in screen.
> Here's a command line to reproduce the problem:
>
>   screen -d -m -S test emacs -nw --eval "(setq server-name \"test\")" \
>          -Q --funcall server-start
>
> Now I connect to it with
>
>   emacsclient -s test
>
> which opens a new X11 frame.  If I hit `C-x 5 0' to close this frame, it
> freezes.  Neither are redisplays performed in it nor does it doesn't
> close.  The menu bar is inaccessible, too.
>
> A subsequent
>
>   emacsclient -s test

I have seen this as well. It only happens with the first X frame.

-- 
Leo <sdl.web AT gmail.com>                (GPG Key: 9283AA3F)

      Gnus is one component of the Emacs operating system.

Re: 23.0.50; frozen frame after C-x 5 0

[Richard Stallman]

    Since the multi-tty merge I start emacs as a detached server in screen.
    Here's a command line to reproduce the problem:

      screen -d -m -S test emacs -nw --eval "(setq server-name \"test\")" \
	     -Q --funcall server-start

    Now I connect to it with

      emacsclient -s test

    which opens a new X11 frame.  If I hit `C-x 5 0' to close this frame, it
    freezes.  Neither are redisplays performed in it nor does it doesn't
    close.  The menu bar is inaccessible, too.

    A subsequent

      emacsclient -s test

    closes the frozen frame and pops up a new one, which is displayed only
    for a fraction of a second before it vanishes, too.  So from this point
    clients with X11 frames are non-functional.

Can someone please DTRT and ack?

Tassilo, could you try debugging it with GDB?
You could see what C-x 5 0 actually does when you run it.
Why doesn't it delete the frame, as it should?

Re: 23.0.50; frozen frame after C-x 5 0

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     Since the multi-tty merge I start emacs as a detached server in screen.
  >     Here's a command line to reproduce the problem:
  > 
  >       screen -d -m -S test emacs -nw --eval "(setq server-name \"test\")" \
  > 	     -Q --funcall server-start
  > 
  >     Now I connect to it with
  > 
  >       emacsclient -s test
  > 
  >     which opens a new X11 frame.  If I hit `C-x 5 0' to close this frame, it
  >     freezes.  Neither are redisplays performed in it nor does it doesn't
  >     close.  The menu bar is inaccessible, too.
  > 
  >     A subsequent
  > 
  >       emacsclient -s test
  > 
  >     closes the frozen frame and pops up a new one, which is displayed only
  >     for a fraction of a second before it vanishes, too.  So from this point
  >     clients with X11 frames are non-functional.
  > 
  > Can someone please DTRT and ack?

I can't reproduce this problem on my Fedora machine.

  > Tassilo, could you try debugging it with GDB?
  > You could see what C-x 5 0 actually does when you run it.
  > Why doesn't it delete the frame, as it should?

Re: 23.0.50; frozen frame after C-x 5 0

[Jan Djärv]

Dan Nicolaescu skrev:
> Richard Stallman <rms@gnu.org> writes:
> 
>   >     Since the multi-tty merge I start emacs as a detached server in screen.
>   >     Here's a command line to reproduce the problem:
>   > 
>   >       screen -d -m -S test emacs -nw --eval "(setq server-name \"test\")" \
>   > 	     -Q --funcall server-start
>   > 
>   >     Now I connect to it with
>   > 
>   >       emacsclient -s test
>   > 
>   >     which opens a new X11 frame.  If I hit `C-x 5 0' to close this frame, it
>   >     freezes.  Neither are redisplays performed in it nor does it doesn't
>   >     close.  The menu bar is inaccessible, too.
>   > 
>   >     A subsequent
>   > 
>   >       emacsclient -s test
>   > 
>   >     closes the frozen frame and pops up a new one, which is displayed only
>   >     for a fraction of a second before it vanishes, too.  So from this point
>   >     clients with X11 frames are non-functional.
>   > 
>   > Can someone please DTRT and ack?
> 
> I can't reproduce this problem on my Fedora machine.
> 

FWIW, I can't either, on Ubuntu 7.04.

	Jan D.

Re: 23.0.50; frozen frame after C-x 5 0

[Leo]

On 2007-09-10 15:36 +0100, Jan Djärv wrote:
> Dan Nicolaescu skrev:
>> Richard Stallman <rms@gnu.org> writes:
>> 
>>   >     Since the multi-tty merge I start emacs as a detached server in screen.
>
>>   >     Here's a command line to reproduce the problem:
>>   > 
>>   >       screen -d -m -S test emacs -nw --eval "(setq server-name \"test\")" \
>>   > 	     -Q --funcall server-start
>>   > 
>>   >     Now I connect to it with
>>   > 
>>   >       emacsclient -s test
>>   > 
>>   >     which opens a new X11 frame.  If I hit `C-x 5 0' to close this frame, it
>>   >     freezes.  Neither are redisplays performed in it nor does it doesn't
>>   >     close.  The menu bar is inaccessible, too.
>>   > 
>>   >     A subsequent
>>   > 
>>   >       emacsclient -s test
>>   > 
>>   >     closes the frozen frame and pops up a new one, which is displayed only
>>   >     for a fraction of a second before it vanishes, too.  So from this point
>>   >     clients with X11 frames are non-functional.
>>   > 
>>   > Can someone please DTRT and ack?
>> 
>> I can't reproduce this problem on my Fedora machine.
>> 
>
> FWIW, I can't either, on Ubuntu 7.04.
>
> 	Jan D.

I can reproduce this with:
GNU Emacs 23.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.10.14, multi-tty)
of 2007-09-01.

Please try with gtk+ 2.10.14.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

=>             "(require 'cl) considered harmful" considered harmful
=>           http://dto.freeshell.org/blog/blog-2007-09-07-2323.html

Re: 23.0.50; frozen frame after C-x 5 0

[Jan Djärv]

Leo skrev:
> On 2007-09-10 15:36 +0100, Jan Djärv wrote:
>> Dan Nicolaescu skrev:
>>> Richard Stallman <rms@gnu.org> writes:
>>>
>>>   >     Since the multi-tty merge I start emacs as a detached server in screen.
>>>   >     Here's a command line to reproduce the problem:
>>>   > 
>>>   >       screen -d -m -S test emacs -nw --eval "(setq server-name \"test\")" \
>>>   > 	     -Q --funcall server-start
>>>   > 
>>>   >     Now I connect to it with
>>>   > 
>>>   >       emacsclient -s test
>>>   > 
>>>   >     which opens a new X11 frame.  If I hit `C-x 5 0' to close this frame, it
>>>   >     freezes.  Neither are redisplays performed in it nor does it doesn't
>>>   >     close.  The menu bar is inaccessible, too.
>>>   > 
>>>   >     A subsequent
>>>   > 
>>>   >       emacsclient -s test
>>>   > 
>>>   >     closes the frozen frame and pops up a new one, which is displayed only
>>>   >     for a fraction of a second before it vanishes, too.  So from this point
>>>   >     clients with X11 frames are non-functional.
>>>   > 
>>>   > Can someone please DTRT and ack?
>>>
>>> I can't reproduce this problem on my Fedora machine.
>>>
>> FWIW, I can't either, on Ubuntu 7.04.
>>
>> 	Jan D.
> 
> I can reproduce this with:
> GNU Emacs 23.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.10.14, multi-tty)
> of 2007-09-01.
> 
> Please try with gtk+ 2.10.14.

I did, and failed to reproduce.  Those that can reproduce it must try to debug 
it more.  Something else is different.

	Jan D.

Re: 23.0.50; frozen frame after C-x 5 0

[Richard Stallman]

    > Please try with gtk+ 2.10.14.

    I did, and failed to reproduce.

Maybe it didn't find that version of GTK+ attractive enough.  Perhaps
it would mate with a younger GTK version if given the chance.

Re: 23.0.50; frozen frame after C-x 5 0

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     > Please try with gtk+ 2.10.14.
>
>     I did, and failed to reproduce.
>
> Maybe it didn't find that version of GTK+ attractive enough.  Perhaps
> it would mate with a younger GTK version if given the chance.

I should think that 2.10.14 would be quite below the age of consent
already.

-- 
David Kastrup

Re: 23.0.50; frozen frame after C-x 5 0

[Richard Stallman]

    > Maybe it didn't find that version of GTK+ attractive enough.  Perhaps
    > it would mate with a younger GTK version if given the chance.

    I should think that 2.10.14 would be quite below the age of consent
    already.

Program versions' lifespans are much shorter than ours.  You have to
measure their lives in program-years, which are about a week.

Re: 23.0.50; frozen frame after C-x 5 0

[Tassilo Horn]

Richard Stallman <rms@gnu.org> writes:

Hi,

> Tassilo, could you try debugging it with GDB?

Sure.  Unfortunately I upgraded to xorg 7.3 and now my keyboard doesn't
work in X, so I'm currently banned on a console.  I'll debug it as soon
as I get X working.

Bye,
Tassilo

Re: 23.0.50; frozen frame after C-x 5 0

[Tassilo Horn]

Richard Stallman <rms@gnu.org> writes:

First, here's a simpler command line to reproduce my problem:

  emacs -nw -f server-start

to start the server (it's important that the server is no X emacs here)
followed by

  emacsclient

to open a new X frame.

> Tassilo, could you try debugging it with GDB?
> You could see what C-x 5 0 actually does when you run it.
> Why doesn't it delete the frame, as it should?

Now I did

  $ gdb /usr/bin/emacsclient
  (gdb) run
  Starting program: /usr/bin/emacsclient 
  Waiting for Emacs...

which opened an X frame.  Then I tried closing the frame with `C-x 5 0',
but the frame didn't disappear.  Nevertheless in gdb I got the message

  Program exited normally.

When I try to run emacsclient again, I get

  (gdb) run
  Starting program: /usr/bin/emacsclient 
  Waiting for Emacs...

  Program received signal SIGINT, Interrupt.
  0xb7f21410 in __kernel_vsyscall ()

Here's a backtrace:

  (gdb) bt full
  #0  0xb7f21410 in __kernel_vsyscall ()
  No symbol table info available.
  #1  0xb7e99691 in recv () from /lib/libc.so.6
  No symbol table info available.
  #2  0x0804acee in main (argc=1, argv=0xbf85f274) at /var/tmp/portage/app-editors/emacs-cvs-23.0.50/work/emacs/lib-src/emacsclient.c:1458
	  i = 0
	  rl = 15
	  needlf = 2
	  cwd = 0x804f008 "/home/heimdall"
	  str = 0x0
	  string = "-good-version ", '\0' <repeats 5539 times>, "F@ó·", '\0'
  <repeats 20 times>,
  "\234yð·Èç\205¿¼ÿó·¨é\205¿~\215ò·\000\200ð·è%\000\000\003\000\000\0002\000\000\000ÿÿÿÿ",
  '\0' <repeats 41 times>,
  "\020\024\000b\a\024\000b\a\024\000\000\000\000\000\005\000\000\000\000\020\024\000\000@\024\000\2349\024\000èe\024\000\000\020\024\000\003",
  '\0' <repeats 15 times>,
  "b\002\000\000\000\020\000\000¼ÿó·\n\000\000\000Ô\214ó·\000\000\000\000\000\020\000\000\003\000\000\000\"\000\000\000J\214ó·\000\000\000\000¼ÿó·b\002\000\000\000\000\000\000k\215ó·\b\000"...

Bye,
Tassilo

Re: 23.0.50; frozen frame after C-x 5 0

[Jan Djärv]

You should run gdb on emacs, not emacsclient.  See etc/DEBUG for useful tips.

	Jan D.


Tassilo Horn skrev:
> Richard Stallman <rms@gnu.org> writes:
> 
> First, here's a simpler command line to reproduce my problem:
> 
>   emacs -nw -f server-start
> 
> to start the server (it's important that the server is no X emacs here)
> followed by
> 
>   emacsclient
> 
> to open a new X frame.
> 
>> Tassilo, could you try debugging it with GDB?
>> You could see what C-x 5 0 actually does when you run it.
>> Why doesn't it delete the frame, as it should?
> 
> Now I did
> 
>   $ gdb /usr/bin/emacsclient
>   (gdb) run
>   Starting program: /usr/bin/emacsclient 
>   Waiting for Emacs...
> 
> which opened an X frame.  Then I tried closing the frame with `C-x 5 0',
> but the frame didn't disappear.  Nevertheless in gdb I got the message
> 
>   Program exited normally.
> 

Re: 23.0.50; frozen frame after C-x 5 0

[Tassilo Horn]

Jan Djärv <jan.h.d@swipnet.se> writes:

> You should run gdb on emacs, not emacsclient.  See etc/DEBUG for
> useful tips.

Ok.  Here's a backtrace of the emacs process after I tried to close the
client frame:

#0  0xb7f7a410 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb759b54d in select () from /lib/libc.so.6
No symbol table info available.
#2  0x081f3377 in select_wrapper (n=11, rfd=0xbfe89d00, wfd=0x0, xfd=0x0, tmo=0xbfe89c74) at process.c:4226
No locals.
#3  0x081f3cf3 in wait_reading_process_output (time_limit=0, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=137984201, wait_proc=0x0,
    just_wait_proc=0) at process.c:4596
  timeout_reduced_for_timers = 1
  channel = 156298619
  nfds = 0
  Available = {fds_bits = {1408, 0 <repeats 31 times>}}
  Connecting = {fds_bits = {0 <repeats 32 times>}}
  check_connect = 0
  check_delay = 1
  no_avail = 0
  xerrno = 0
  proc = 125
  timeout = {tv_sec = 0, tv_usec = 434000}
  end_time = {tv_sec = 7, tv_usec = -1075274344}
  wait_channel = -1
  got_some_input = 0
  count = 2
#4  0x08133140 in kbd_buffer_get_event (kbp=0xbfe89f2c, used_mouse_menu=0xbfe8a2ac, end_time=0x0) at keyboard.c:4146
  c = -514
  obj = 138038696
#5  0x081313ae in read_char (commandflag=1, nmaps=7, maps=0xbfe8a170, prev_event=137984201, used_mouse_menu=0xbfe8a2ac, end_time=0x0) at keyboard.c:3103
  kb = (KBOARD *) 0x0
  c = 137984201
  count = 0
  jmpcount = 2
  local_getcjmp = {{__jmpbuf = {-1075273360, 7, 0, -1075273448, 215471487, -67292144}, __mask_was_saved = 0, __saved_mask = {__val = {137984201,
        0, 3219693624, 135605580, 156187573, 138019577, 0, 1, 0, 3219695632, 3219693896, 135936731, 138019577, 8, 138016068, 4294967295, 142024970, 20,
        20, 4294967295, 4294967295, 4294967295, 4294967295, 0, 0, 0, 0, 0, 0, 0, 0, 0}}}}
  save_jump = {{__jmpbuf = {0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, __saved_mask = {__val = {0 <repeats 32 times>}}}}
  key_already_recorded = 0
  tem = 0
  save = 0
  previous_echo_area_message = 137984201
  also_record = 137984201
  reread = 0
  gcpro1 = {next = 0x8797d9c, var = 0x0, nvars = 3}
  gcpro2 = {next = 0xbfe89e90, var = 0x89d2733, nvars = 144076340}
  polling_stopped_here = 1
  orig_kboard = (struct kboard *) 0x85eb168
#6  0x0813afca in read_key_sequence (keybuf=0xbfe8a484, bufsize=30, prompt=137984201, dont_downcase_last=0, can_return_switch_frame=1,
    fix_current_buffer=1) at keyboard.c:9384
  interrupted_kboard = (KBOARD *) 0x85eb168
  interrupted_frame = (struct frame *) 0x83a4da8
  key = 137984201
  used_mouse_menu = 0
  echo_local_start = 0
  last_real_key_start = 0
  keys_local_start = 0
  local_first_binding = 0
  from_string = 137984201
  count = 2
  t = 0
  echo_start = 0
  keys_start = 0
  nmaps = 7
  nmaps_allocated = 7
  defs = (Lisp_Object * volatile) 0xbfe8a140
  submaps = (Lisp_Object * volatile) 0xbfe8a170
  orig_local_map = 139672141
  orig_keymap = 137984201
  localized_local_map = 0
  first_binding = 0
  first_unbound = 31
  mock_input = 0
  fkey = {parent = 138229517, map = 138229517, start = 0, end = 0}
  keytran = {parent = 138351741, map = 138351741, start = 0, end = 0}
  delayed_switch_frame = 137984201
  original_uppercase = 137984201
  original_uppercase_position = -1
  dummyflag = 0
  starting_buffer = (struct buffer *) 0x839f540
  fake_prefixed_keys = 137984201
  gcpro1 = {next = 0x1, var = 0x8644680, nvars = 137984201}
#7  0x0812e14b in command_loop_1 () at keyboard.c:1691
  cmd = 134224409
  lose = 136732988
  nonundocount = 0
  keybuf = {138051193, 138053931, 137984201, 137984201, 0, 136838227, -1075272656, 137974685, 0, -1075272488, 135453343, 156288117, 137984249,
  -1075272450, 138549785, -1208379476, 0, -1221870224, 1, 0, 138038696, -1075272392, 135452941, 156288117, -1075272450, -1075272392, 135452890, 0, 0,
  137984201}
  i = 1
  no_direct = 0
  prev_modiff = 0
  prev_buffer = (struct buffer *) 0x0
  already_adjusted = 0
#8  0x081b1133 in internal_condition_case (bfun=0x812de2b <command_loop_1>, handlers=138050833, hfun=0x812d82c <cmd_error>) at eval.c:1494
  val = 136733555
  c = {tag = 137984201, val = 137984201, next = 0xbfe8a680, gcpro = 0x0, jmp = {{__jmpbuf = {-1075271664, -1208382304, 0, -1075272136, 211875199,
        -338954736}, __mask_was_saved = 0, __saved_mask = {__val = {3219695048, 135873055, 3219695272, 16, 3219695044, 3219695040, 1, 140362155, 0,
          136484916, 16, 16, 3219695080, 135873555, 3219695272, 16, 140362171, 3219695544, 3219695632, 2, 3219695544, 135934461, 3219695272, 140362395,
          3075877004, 135934052, 3219695408, 3219695128, 140534864, 67372036, 140362379, 0}}}}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0,
  pdlcount = 2, poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0x0}
  h = {handler = 138050833, var = 137984201, chosen_clause = 137984249, tag = 0xbfe8a56c, next = 0x0}
#9  0x0812db7b in command_loop_2 () at keyboard.c:1405
  val = 0
#10 0x081b0bdd in internal_catch (tag=138033137, func=0x812db5d <command_loop_2>, arg=137984201) at eval.c:1229
  c = {tag = 138033137, val = 137984201, next = 0x0, gcpro = 0x0, jmp = {{__jmpbuf = {-1075271664, -1208382304, 0, -1075271864, 212252031,
        -335683056}, __mask_was_saved = 0, __saved_mask = {__val = {1731015218, 1869901413, 913452399, 0, 0, 0, 0, 0, 0, 0, 0, 3219695400, 135904373,
          138172177, 138168914, 137984201, 138016064, 1162170960, 542396493, 544498003, 137984201, 858857521, 138168914, 138168914, 138168914,
          925904946, 2, 138168914, 0, 0, 138168914, 3219695464}}}}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2,
  poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0x0}
#11 0x0812db2f in command_loop () at keyboard.c:1384
No locals.
#12 0x0812d434 in recursive_edit_1 () at keyboard.c:993
  count = 1
  val = 137984201
#13 0x0812d5a1 in Frecursive_edit () at keyboard.c:1055
  count = 0
  buffer = 137984201
#14 0x0812bebe in main (argc=2, argv=0xbfe8ab34) at emacs.c:1778
  dummy = 0
  stack_bottom_variable = 0 '\0'
  do_initial_setlocale = 1
  skip_args = 1
  rlim = {rlim_cur = 8388608, rlim_max = 18446744073709551615}
  no_loadup = 0
  junk = 0x0

Bye,
Tassilo

Re: 23.0.50; frozen frame after C-x 5 0

[Dan Nicolaescu]

Tassilo Horn <tassilo@member.fsf.org> writes:

  > Richard Stallman <rms@gnu.org> writes:
  > 
  > First, here's a simpler command line to reproduce my problem:
  > 
  >   emacs -nw -f server-start

Can you please first try this with "emacs -q -nw -f server-start" ? 

Re: 23.0.50; frozen frame after C-x 5 0

[Tassilo Horn]

Dan Nicolaescu <dann@ics.uci.edu> writes:

Hi Dan,

>   > First, here's a simpler command line to reproduce my problem:
>   > 
>   >   emacs -nw -f server-start
>
> Can you please first try this with "emacs -q -nw -f server-start" ?

Yes, it doesn't make a difference and -Q doesn't, too.  Here's what I
did:

1. Start the server within gdb

   $ gdb /usr/bin/emacs
   (gdb) run -q -nw -f server-start

2. Connect with a X11 client

   $ emacsclient

3. Close the frame with

   C-x 5 0

it doesn't vanish but it won't be repainted anymore.

4. Halt the server process to get a backtrace.

   $ killall -sSIGSTOP emacs

and in gdb

   (gdb) bt full

--8<---------------cut here---------------start------------->8---
(gdb) bt full
#0  0xb7f7d410 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb759e54d in select () from /lib/libc.so.6
No symbol table info available.
#2  0x081f3377 in select_wrapper (n=9, rfd=0xbfb15690, wfd=0x0, xfd=0x0, tmo=0xbfb15604) at process.c:4226
No locals.
#3  0x081f3cf3 in wait_reading_process_output (time_limit=30, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=137984201, wait_proc=0x0, 
    just_wait_proc=0) at process.c:4596
    timeout_reduced_for_timers = 0
    channel = 137984201
    nfds = -1
    Available = {fds_bits = {384, 0 <repeats 31 times>}}
    Connecting = {fds_bits = {0 <repeats 32 times>}}
    check_connect = 0
    check_delay = 0
    no_avail = 0
    xerrno = 4
    proc = 136229164
    timeout = {tv_sec = 16, tv_usec = 390000}
    end_time = {tv_sec = 1189613023, tv_usec = 675654}
    wait_channel = -1
    got_some_input = 0
    count = 2
#4  0x0805f988 in sit_for (timeout=240, reading=1, do_display=1) at dispnew.c:6610
    sec = 30
    usec = 0
#5  0x08131098 in read_char (commandflag=1, nmaps=2, maps=0xbfb15a70, prev_event=137984201, used_mouse_menu=0xbfb15b9c, end_time=0x0) at keyboard.c:2992
    tem0 = 143438392
    timeout = 30
    delay_level = 4
    buffer_size = 5
    c = 137984201
    count = 0
    jmpcount = 2
    local_getcjmp = {{__jmpbuf = {-1078896016, 2, 0, -1078896088, -338495045, -1351976748}, __mask_was_saved = 0, __saved_mask = {__val = {0, 
        137984201, 3216071224, 135936820, 568, 138019577, 143438396, 135572115, 3216071296, 137984201, 128, 137984201, 3086597280, 0, 3216071080, 
        135904373, 138089553, 138088266, 137984201, 136309528, 3216071044, 3216071584, 3216071736, 136309537, 3216071200, 8192, 0, 0, 0, 0, 0, 0}}}}
        save_jump = {{__jmpbuf = {0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, __saved_mask = {__val = {0 <repeats 32 times>}}}}
        key_already_recorded = 0
        tem = 0
        save = 0
        previous_echo_area_message = 137984201
        also_record = 137984201
        reread = 0
        gcpro1 = {next = 0xb78dfff4, var = 0x2, nvars = 216}
        gcpro2 = {next = 0xb74fca44, var = 0xd8, nvars = 138565493}
        polling_stopped_here = 0
        orig_kboard = (struct kboard *) 0x85eb168
#6  0x0813afca in read_key_sequence (keybuf=0xbfb15d74, bufsize=30, prompt=137984201, dont_downcase_last=0, can_return_switch_frame=1, 
    fix_current_buffer=1) at keyboard.c:9384
    interrupted_kboard = (KBOARD *) 0x85eb168
    interrupted_frame = (struct frame *) 0x83a4da8
    key = -1078895448
    used_mouse_menu = 0
    echo_local_start = 0
    last_real_key_start = 0
    keys_local_start = 0
    local_first_binding = 0
    from_string = 137984201
---Type <return> to continue, or q <return> to quit---
        count = 2
        t = 0
        echo_start = 0
        keys_start = 0
        nmaps = 2
        nmaps_allocated = 2
        defs = (Lisp_Object * volatile) 0xbfb15a50
        submaps = (Lisp_Object * volatile) 0xbfb15a70
        orig_local_map = 138664597
        orig_keymap = 137984201
        localized_local_map = 0
        first_binding = 0
        first_unbound = 31
        mock_input = 0
        fkey = {parent = 138229509, map = 138229509, start = 0, end = 0}
        keytran = {parent = 138356221, map = 138356221, start = 0, end = 0}
        delayed_switch_frame = 137984201
        original_uppercase = 0
        original_uppercase_position = -1
        dummyflag = 0
        starting_buffer = (struct buffer *) 0x88cb238
        fake_prefixed_keys = 137984201
        gcpro1 = {next = 0x0, var = 0xbfb15c08, nvars = 136339407}
#7  0x0812e14b in command_loop_1 () at keyboard.c:1691
    cmd = 138284457
    lose = 136732988
    nonundocount = 0
    keybuf = {138028857, 632, 528, 137984201, 0, -1078895192, 134608423, 137974085, 0, -1078895160, 135453343, 147123421, 137984249, -1078895122, 
  137984201, -1208367188, 0, -1221857936, 1, 0, 143100536, -1078895064, 135452941, 147123421, -1078895122, -1078895064, 135452890, 0, 0, 137984201}
  i = 1
  no_direct = 0
  prev_modiff = 40
  prev_buffer = (struct buffer *) 0x88cb238
  already_adjusted = 0
#8  0x081b1133 in internal_condition_case (bfun=0x812de2b <command_loop_1>, handlers=138050833, hfun=0x812d82c <cmd_error>) at eval.c:1494
    val = 136733555
    c = {tag = 137984201, val = 137984201, next = 0xbfb15f70, gcpro = 0x0, jmp = {{__jmpbuf = {-1078894336, -1208370016, 0, -1078894808, 
        -339650117, -1084441900}, __mask_was_saved = 0, __saved_mask = {__val = {3216072376, 135873055, 3216072600, 16, 3216072372, 3216072368, 1, 
          140362075, 0, 136484916, 16, 16, 3216072408, 135873555, 3216072600, 16, 140362123, 3216072872, 3216072960, 2, 3216072872, 135934461, 
          3216072600, 140362171, 3075889292, 135934052, 3216072736, 3216072456, 140533736, 67372036, 140362155, 0}}}}, backlist = 0x0, 
  handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0x0}
  h = {handler = 138050833, var = 137984201, chosen_clause = 137984249, tag = 0xbfb15e5c, next = 0x0}
#9  0x0812db7b in command_loop_2 () at keyboard.c:1405
    val = 0
#10 0x081b0bdd in internal_catch (tag=138033137, func=0x812db5d <command_loop_2>, arg=137984201) at eval.c:1229
    c = {tag = 138033137, val = 137984201, next = 0x0, gcpro = 0x0, jmp = {{__jmpbuf = {-1078894336, -1208370016, 0, -1078894536, -339502661, 
        -1083527468}, __mask_was_saved = 0, __saved_mask = {__val = {1731015218, 1869901413, 913452399, 0, 0, 0, 0, 0, 0, 0, 0, 3216072728, 135904373, 
          138172177, 138168914, 137984201, 138016064, 1162170960, 542396493, 544498003, 137984201, 858857521, 138168914, 138168914, 138168914, 
          925904946, 2, 138168914, 0, 0, 138168914, 3216072792}}}}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, 
  poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0x0}
#11 0x0812db2f in command_loop () at keyboard.c:1384
No locals.
#12 0x0812d434 in recursive_edit_1 () at keyboard.c:993
    count = 1
    val = 137984201
#13 0x0812d5a1 in Frecursive_edit () at keyboard.c:1055
    count = 0
    buffer = 137984201
#14 0x0812bebe in main (argc=5, argv=0xbfb16424) at emacs.c:1778
---Type <return> to continue, or q <return> to quit---
        dummy = 0
        stack_bottom_variable = 0 '\0'
        do_initial_setlocale = 1
        skip_args = 1
        rlim = {rlim_cur = 8388608, rlim_max = 18446744073709551615}
        no_loadup = 0
        junk = 0x0
(gdb)
--8<---------------cut here---------------end--------------->8---

Bye,
Tassilo

Re: 23.0.50; frozen frame after C-x 5 0

[Romain Francoise]

I can reproduce this problem here, and I get the same backtrace as
Tassilo (except that my machine is 64-bit).

GTK+ 2.10.13, Linux 2.6.22.5, libc6 2.6.1.

Re: 23.0.50; frozen frame after C-x 5 0

[Dan Nicolaescu]

Tassilo Horn <tassilo@member.fsf.org> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > Hi Dan,
  > 
  > >   > First, here's a simpler command line to reproduce my problem:
  > >   > 
  > >   >   emacs -nw -f server-start
  > >
  > > Can you please first try this with "emacs -q -nw -f server-start" ?
  > 
  > Yes, it doesn't make a difference and -Q doesn't, too.  Here's what I
  > did:
  > 
  > 1. Start the server within gdb
  > 
  >    $ gdb /usr/bin/emacs
  >    (gdb) run -q -nw -f server-start
  > 
  > 2. Connect with a X11 client
  > 
  >    $ emacsclient
  > 
  > 3. Close the frame with
  > 
  >    C-x 5 0
  > 
  > it doesn't vanish but it won't be repainted anymore.
  > 

I can reproduce this with an emacs build with gtk (version
gtk2-2.8.20) but not with emacs build with the Lucid toolkit (my
default build). 

In the Lucid build the frame is deleted when stepping over this call: 

 (*terminal->delete_terminal_hook) (terminal);

So my guess is that the Gtk version of x_delete_terminal does not do
the right thing...

Re: 23.0.50; frozen frame after C-x 5 0

[Jan Djärv]

Dan Nicolaescu skrev:

> I can reproduce this with an emacs build with gtk (version
> gtk2-2.8.20) but not with emacs build with the Lucid toolkit (my
> default build). 
> 
> In the Lucid build the frame is deleted when stepping over this call: 
> 
>  (*terminal->delete_terminal_hook) (terminal);
> 
> So my guess is that the Gtk version of x_delete_terminal does not do
> the right thing...
> 
> 

This may be correct, Gtk still has not fixed the bug about closing displays, 
http://bugzilla.gnome.org/show_bug.cgi?id=85715.  The bug has been known since 
Gtk 2.2.

	Jan D.

Re: 23.0.50; frozen frame after C-x 5 0

[Leo]

On 2007-09-13 07:04 +0100, Jan Djärv wrote:
> Dan Nicolaescu skrev:
>
>> I can reproduce this with an emacs build with gtk (version
>> gtk2-2.8.20) but not with emacs build with the Lucid toolkit (my
>> default build). 
>>
>> In the Lucid build the frame is deleted when stepping over this
>> call: 
>>
>>  (*terminal->delete_terminal_hook) (terminal);
>>
>> So my guess is that the Gtk version of x_delete_terminal does not do
>> the right thing...
>>
>>
>
> This may be correct, Gtk still has not fixed the bug about closing
> displays, http://bugzilla.gnome.org/show_bug.cgi?id=85715.  The bug
> has been known since Gtk 2.2.
>
> 	Jan D.

Do you know what prevent them from fixing it?

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

=>             "(require 'cl) considered harmful" considered harmful
=>           http://dto.freeshell.org/blog/blog-2007-09-07-2323.html

Re: 23.0.50; frozen frame after C-x 5 0

[Jan Djärv]

Leo skrev:
> On 2007-09-13 07:04 +0100, Jan Djärv wrote:
>> Dan Nicolaescu skrev:
>>
>>> I can reproduce this with an emacs build with gtk (version
>>> gtk2-2.8.20) but not with emacs build with the Lucid toolkit (my
>>> default build). 
>>>
>>> In the Lucid build the frame is deleted when stepping over this
>>> call: 
>>>
>>>  (*terminal->delete_terminal_hook) (terminal);
>>>
>>> So my guess is that the Gtk version of x_delete_terminal does not do
>>> the right thing...
>>>
>>>
>> This may be correct, Gtk still has not fixed the bug about closing
>> displays, http://bugzilla.gnome.org/show_bug.cgi?id=85715.  The bug
>> has been known since Gtk 2.2.
>>
>> 	Jan D.
> 
> Do you know what prevent them from fixing it?
> 

Not really, but lack of time and lack of urgency I guess.  After all, most 
Gtk+ applications only deal with one (most often local) display that the 
application keep open the whole time.

	Jan D.

Re: 23.0.50; frozen frame after C-x 5 0

[Leo]

On 2007-09-13 09:23 +0100, Jan Djärv wrote:
> Not really, but lack of time and lack of urgency I guess.  After all,
> most Gtk+ applications only deal with one (most often local) display
> that the application keep open the whole time.

Since now we use gtk if it is available, this bug just makes more people
think that Emacs is buggy. They wouldn't know it is GTK's fault.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

=>             "(require 'cl) considered harmful" considered harmful
=>           http://dto.freeshell.org/blog/blog-2007-09-07-2323.html

Re: 23.0.50; frozen frame after C-x 5 0

[Jan Djärv]

Leo skrev:
> On 2007-09-13 09:23 +0100, Jan Djärv wrote:
>> Not really, but lack of time and lack of urgency I guess.  After all,
>> most Gtk+ applications only deal with one (most often local) display
>> that the application keep open the whole time.
> 
> Since now we use gtk if it is available, this bug just makes more people
> think that Emacs is buggy. They wouldn't know it is GTK's fault.
> 

Yes it is a problem.  Gtk+ does not work well without any display connection. 
  But I've tried to work around it, please try your tests on CVS HEAD.

Thanks,

	Jan D.

Re: 23.0.50; frozen frame after C-x 5 0

[Leo]

On 2007-09-17 09:09 +0100, Jan Djärv wrote:
> Leo skrev:
>> On 2007-09-13 09:23 +0100, Jan Djärv wrote:
>>> Not really, but lack of time and lack of urgency I guess.  After all,
>>> most Gtk+ applications only deal with one (most often local) display
>>> that the application keep open the whole time.
>>
>> Since now we use gtk if it is available, this bug just makes more people
>> think that Emacs is buggy. They wouldn't know it is GTK's fault.
>>
>
> Yes it is a problem.  Gtk+ does not work well without any display
> connection. But I've tried to work around it, please try your tests
> on CVS HEAD.

The problem is now gone! Thanks for the fix.

>
> Thanks,
>
> 	Jan D.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

                                                 I use GNU Emacs  <=
                              http://www.gnu.org/software/emacs/  <=

Re: 23.0.50; frozen frame after C-x 5 0

[Tassilo Horn]

Jan Djärv <jan.h.d@swipnet.se> writes:

Hi Jan,

> Yes it is a problem.  Gtk+ does not work well without any display
> connection. But I've tried to work around it, please try your tests on
> CVS HEAD.

Yes, it works now.

Thanks a lot,
Tassilo