unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* emacs 24 randomly hanging
@ 2012-02-19  5:28 Adam
  2012-02-19  9:45 ` Adam
                   ` (3 more replies)
  0 siblings, 4 replies; 22+ messages in thread
From: Adam @ 2012-02-19  5:28 UTC (permalink / raw)
  To: emacs-devel

I am using GNU Emacs 24.0.93.1 (x86_64-unknown-linux-gnu, GTK+ Version
2.20.1) of 2012-02-15, built from sources.

I am constantly experiencing my emacs hanging.  That is, C-g does not
work, and the screen is not updated.  It happens about twice a day or
so, which is very annoying, as I only have one emacs instance up
and running in which I am doing all my work.

I am pretty sure emacs hanging has been discussed to death, and I am
pretty sure I just screwed my emacs configuration up somewhere.  What's
worring me is that C-g does not work, though.  In fact, nothing works.
I have to send a SIGKILL to my emacs process to get rid of it.

Here's a backtrace:

~$ gdb
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
No symbol table is loaded.  Use the "file" command.
Catchpoint 1 (throw)
(gdb) attach 15790
Attaching to process 15790
[snip]
next_frame (frame=73210197, minibuf=11962754) at /usr/local/src/emacs/src/frame.c:939
939     for (tail = Vframe_list; CONSP (tail); tail = XCDR (tail))
(gdb) info threads
  Id   Target Id         Frame
* 1    Thread 0x7fd96a9817e0 (LWP 15790) next_frame (frame=73210197, minibuf=11962754) at /usr/local/src/emacs/src/frame.c:939
(gdb) bt
#0  next_frame (frame=73210197, minibuf=11962754) at /usr/local/src/emacs/src/frame.c:939
#1  0x0000000000571d1c in eval_sub (form=<optimized out>) at /usr/local/src/emacs/src/eval.c:2347
#2  0x0000000000571f90 in Fsetq (args=<optimized out>) at /usr/local/src/emacs/src/eval.c:455
#3  0x0000000000571eac in eval_sub (form=<optimized out>) at /usr/local/src/emacs/src/eval.c:2292
#4  0x00000000005720e7 in Fprogn (args=<optimized out>) at /usr/local/src/emacs/src/eval.c:358
#5  0x0000000000574d38 in Fwhile (args=<optimized out>) at /usr/local/src/emacs/src/eval.c:1136
#6  0x0000000000571eac in eval_sub (form=<optimized out>) at /usr/local/src/emacs/src/eval.c:2292
#7  0x00000000005720e7 in Fprogn (args=<optimized out>) at /usr/local/src/emacs/src/eval.c:358
#8  0x0000000000575508 in FletX (args=72870454) at /usr/local/src/emacs/src/eval.c:1044
#9  0x0000000000571eac in eval_sub (form=<optimized out>) at /usr/local/src/emacs/src/eval.c:2292
#10 0x00000000005720e7 in Fprogn (args=<optimized out>) at /usr/local/src/emacs/src/eval.c:358
#11 0x0000000000570938 in internal_catch (tag=360287970189639680, func=0x5720c0 <Fprogn>, arg=72870534) at /usr/local/src/emacs/src/eval.c:1266
#12 0x0000000000571eac in eval_sub (form=<optimized out>) at /usr/local/src/emacs/src/eval.c:2292
#13 0x0000000000571bbc in eval_sub (form=<optimized out>) at /usr/local/src/emacs/src/eval.c:2329
#14 0x0000000000571c0f in eval_sub (form=<optimized out>) at /usr/local/src/emacs/src/eval.c:2405
#15 0x0000000000571c0f in eval_sub (form=<optimized out>) at /usr/local/src/emacs/src/eval.c:2405
#16 0x00000000005720e7 in Fprogn (args=<optimized out>) at /usr/local/src/emacs/src/eval.c:358
#17 0x000000000057243d in funcall_lambda (fun=<optimized out>, nargs=0, arg_vector=0x7fff0ce5eb10) at /usr/local/src/emacs/src/eval.c:3220
#18 0x0000000000571740 in apply_lambda (fun=78214310, args=11962754) at /usr/local/src/emacs/src/eval.c:3104
#19 0x0000000000571a36 in eval_sub (form=<optimized out>) at /usr/local/src/emacs/src/eval.c:2408
#20 0x0000000000574cc5 in Fand (args=<optimized out>) at /usr/local/src/emacs/src/eval.c:282
#21 0x0000000000571eac in eval_sub (form=<optimized out>) at /usr/local/src/emacs/src/eval.c:2292
#22 0x0000000000574c51 in Fif (args=86619142) at /usr/local/src/emacs/src/eval.c:304
#23 0x0000000000571eac in eval_sub (form=<optimized out>) at /usr/local/src/emacs/src/eval.c:2292
#24 0x0000000000571c0f in eval_sub (form=<optimized out>) at /usr/local/src/emacs/src/eval.c:2405
#25 0x00000000005720e7 in Fprogn (args=<optimized out>) at /usr/local/src/emacs/src/eval.c:358
#26 0x000000000057243d in funcall_lambda (fun=<optimized out>, nargs=0, arg_vector=0x7fff0ce5f080) at /usr/local/src/emacs/src/eval.c:3220
#27 0x00000000005726db in Ffuncall (nargs=1, args=0x7fff0ce5f078) at /usr/local/src/emacs/src/eval.c:3057
#28 0x0000000000572b58 in call0 (fn=78160082) at /usr/local/src/emacs/src/eval.c:2750
#29 0x0000000000464e38 in run_funs (funs=<optimized out>) at /usr/local/src/emacs/src/window.c:2872
#30 0x0000000000469c76 in run_window_configuration_change_hook (f=<optimized out>) at /usr/local/src/emacs/src/window.c:2933
#31 0x0000000000423976 in x_set_frame_parameters (f=0x45d1950, alist=<optimized out>) at /usr/local/src/emacs/src/frame.c:2920
#32 0x0000000000425e65 in x_default_parameter (f=<optimized out>, alist=<optimized out>, prop=12143426, deflt=<optimized out>, xprop=<optimized out>, xclass=<optimized out>,
    type=RES_TYPE_NUMBER) at /usr/local/src/emacs/src/frame.c:3929
#33 0x00000000004cdc25 in Fx_create_frame (parms=86711590) at /usr/local/src/emacs/src/xfns.c:3327
#34 0x00000000005728a3 in Ffuncall (nargs=<optimized out>, args=0x7fff0ce5f430) at /usr/local/src/emacs/src/eval.c:2996
#35 0x00000000005aa696 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>,
    args=<optimized out>) at /usr/local/src/emacs/src/bytecode.c:785
#36 0x0000000000572371 in funcall_lambda (fun=9138461, nargs=<optimized out>, arg_vector=0x7fff0ce5f5f8) at /usr/local/src/emacs/src/eval.c:3227
#37 0x00000000005726db in Ffuncall (nargs=2, args=0x7fff0ce5f5f0) at /usr/local/src/emacs/src/eval.c:3057
#38 0x00000000005aa696 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>,
    args=<optimized out>) at /usr/local/src/emacs/src/bytecode.c:785
#39 0x0000000000572371 in funcall_lambda (fun=9787221, nargs=<optimized out>, arg_vector=0x7fff0ce5f7c8) at /usr/local/src/emacs/src/eval.c:3227
#40 0x00000000005726db in Ffuncall (nargs=2, args=0x7fff0ce5f7c0) at /usr/local/src/emacs/src/eval.c:3057
#41 0x00000000005aa696 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>,
    args=<optimized out>) at /usr/local/src/emacs/src/bytecode.c:785
#42 0x0000000000572371 in funcall_lambda (fun=9785117, nargs=<optimized out>, arg_vector=0x7fff0ce5f9c8) at /usr/local/src/emacs/src/eval.c:3227
#43 0x00000000005726db in Ffuncall (nargs=3, args=0x7fff0ce5f9c0) at /usr/local/src/emacs/src/eval.c:3057
#44 0x00000000005aa696 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>,
    args=<optimized out>) at /usr/local/src/emacs/src/bytecode.c:785
#45 0x00000000005726db in Ffuncall (nargs=6, args=0x7fff0ce5fba8) at /usr/local/src/emacs/src/eval.c:3057
#46 0x00000000005aa696 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>,
    args=<optimized out>) at /usr/local/src/emacs/src/bytecode.c:785
#47 0x00000000005726db in Ffuncall (nargs=1, args=0x7fff0ce5fd60) at /usr/local/src/emacs/src/eval.c:3057
#48 0x0000000000571e77 in eval_sub (form=<optimized out>) at /usr/local/src/emacs/src/eval.c:2316
#49 0x0000000000574f54 in internal_lisp_condition_case (var=69450978, bodyform=91242918, handlers=91243014) at /usr/local/src/emacs/src/eval.c:1463
#50 0x00000000005aafd9 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>,
    args=<optimized out>) at /usr/local/src/emacs/src/bytecode.c:981
#51 0x00000000005726db in Ffuncall (nargs=1, args=0x7fff0ce60160) at /usr/local/src/emacs/src/eval.c:3057
#52 0x0000000000571e77 in eval_sub (form=<optimized out>) at /usr/local/src/emacs/src/eval.c:2316
#53 0x0000000000570938 in internal_catch (tag=360287970189639680, func=0x571800 <eval_sub>, arg=91242886) at /usr/local/src/emacs/src/eval.c:1266
#54 0x00000000005ab018 in exec_byte_code (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>,
    args=<optimized out>) at /usr/local/src/emacs/src/bytecode.c:966
#55 0x00000000005726db in Ffuncall (nargs=3, args=0x7fff0ce60520) at /usr/local/src/emacs/src/eval.c:3057
#56 0x0000000000573757 in Fapply (nargs=<optimized out>, args=0x7fff0ce605d0) at /usr/local/src/emacs/src/eval.c:2501
#57 0x0000000000572c20 in apply1 (fn=69407458, arg=<optimized out>) at /usr/local/src/emacs/src/eval.c:2739
#58 0x0000000000570bbe in internal_condition_case_1 (bfun=0x5acef0 <read_process_output_call>, arg=91242838, handlers=11962754,
    hfun=0x5ace70 <read_process_output_error_handler>) at /usr/local/src/emacs/src/eval.c:1547
#59 0x00000000005ac9dd in read_process_output (proc=71731813, channel=<optimized out>) at /usr/local/src/emacs/src/process.c:5201
#60 0x00000000005b0d15 in wait_reading_process_output (time_limit=30, microsecs=0, read_kbd=<optimized out>, do_display=1, wait_for_cell=11962754, wait_proc=<optimized out>,
    just_wait_proc=0) at /usr/local/src/emacs/src/process.c:4844
#61 0x000000000041edf4 in sit_for (timeout=120, reading=1, do_display=1) at /usr/local/src/emacs/src/dispnew.c:6063
#62 0x0000000000509485 in read_char (commandflag=1, nmaps=6, maps=0x7fff0ce61ff0, prev_event=11962754, used_mouse_menu=0x7fff0ce62198, end_time=0x0)
    at /usr/local/src/emacs/src/keyboard.c:2690
#63 0x000000000050a1e7 in read_key_sequence (keybuf=0x7fff0ce621f0, prompt=11962754, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1, bufsize=30)
    at /usr/local/src/emacs/src/keyboard.c:9302
#64 0x000000000050beb5 in command_loop_1 () at /usr/local/src/emacs/src/keyboard.c:1448
#65 0x0000000000570a56 in internal_condition_case (bfun=0x50bce0 <command_loop_1>, handlers=12014946, hfun=0x500d20 <cmd_error>) at /usr/local/src/emacs/src/eval.c:1509
#66 0x00000000004ff1fe in command_loop_2 (ignore=<optimized out>) at /usr/local/src/emacs/src/keyboard.c:1159
#67 0x0000000000570938 in internal_catch (tag=360287970189639680, func=0x4ff1e0 <command_loop_2>, arg=11962754) at /usr/local/src/emacs/src/eval.c:1266
#68 0x00000000005007f7 in command_loop () at /usr/local/src/emacs/src/keyboard.c:1138
#69 recursive_edit_1 () at /usr/local/src/emacs/src/keyboard.c:758
#70 0x0000000000500b2c in Frecursive_edit () at /usr/local/src/emacs/src/keyboard.c:822
#71 0x00000000004fb81d in main (argc=2, argv=<optimized out>) at /usr/local/src/emacs/src/emacs.c:1715
(gdb)

(I am running emacs in daemon mode with about three or five open X11
clients.  Although the backtrace references Fx_create_frame, I *did* not
create a frame.  I am using a tight intergration between my window
manager and emacs though, and my window manager spawns about two
`emacsclient -e' per second).

Is this problem known?  Could this be fixed in emacs 24?



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs 24 randomly hanging
  2012-02-19  5:28 emacs 24 randomly hanging Adam
@ 2012-02-19  9:45 ` Adam
  2012-02-19  9:54 ` Andreas Schwab
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 22+ messages in thread
From: Adam @ 2012-02-19  9:45 UTC (permalink / raw)
  To: emacs-devel

> I am using GNU Emacs 24.0.93.1 (x86_64-unknown-linux-gnu, GTK+ Version
> 2.20.1) of 2012-02-15, built from sources.
>
> I am constantly experiencing my emacs hanging.  That is, C-g does not
> work, and the screen is not updated.  It happens about twice a day or
> so, which is very annoying, as I only have one emacs instance up
> and running in which I am doing all my work.
>
> I am pretty sure emacs hanging has been discussed to death, and I am
> pretty sure I just screwed my emacs configuration up somewhere.  What's
> worring me is that C-g does not work, though.  In fact, nothing works.
> I have to send a SIGKILL to my emacs process to get rid of it.
>
> Here's a backtrace:

[...]

> (gdb)
>
> (I am running emacs in daemon mode with about three or five open X11
> clients.  Although the backtrace references Fx_create_frame, I *did* not
> create a frame.  I am using a tight intergration between my window
> manager and emacs though, and my window manager spawns about two
> `emacsclient -e' per second).
>
> Is this problem known?  Could this be fixed in emacs 24?

Totally forgot why I sent this mail to emacs-devel instead of
emacs-bugs...  Obviously (?) this is a bug or a feature in the emacs
lisp execution engine - it simply does not honour C-g.  Is this a bug or
a feature?



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs 24 randomly hanging
  2012-02-19  5:28 emacs 24 randomly hanging Adam
  2012-02-19  9:45 ` Adam
@ 2012-02-19  9:54 ` Andreas Schwab
  2012-02-20  7:23   ` Adam
  2012-02-20 15:34 ` Dan Nicolaescu
  2012-02-21 10:43 ` Adam
  3 siblings, 1 reply; 22+ messages in thread
From: Andreas Schwab @ 2012-02-19  9:54 UTC (permalink / raw)
  To: emacs-devel

Adam <adam_w67@yahoo.com> writes:

> (I am running emacs in daemon mode with about three or five open X11
> clients.  Although the backtrace references Fx_create_frame, I *did* not
> create a frame.

Please include the lisp backtrace (see etc/DEBUG).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs 24 randomly hanging
  2012-02-19  9:54 ` Andreas Schwab
@ 2012-02-20  7:23   ` Adam
  0 siblings, 0 replies; 22+ messages in thread
From: Adam @ 2012-02-20  7:23 UTC (permalink / raw)
  To: emacs-devel

Andreas Schwab <schwab@linux-m68k.org> writes:

Hi Andreas,

> Adam <adam_w67@yahoo.com> writes:
>
>> (I am running emacs in daemon mode with about three or five open X11
>> clients.  Although the backtrace references Fx_create_frame, I *did* not
>> create a frame.
>
> Please include the lisp backtrace (see etc/DEBUG).

Here we go:

--8<---------------cut here---------------start------------->8---
(gdb) xbacktrace
"next-frame" (0xb2242600)
"setq" (0xb2242788)
"while" (0xb22428a8)
"let*" (0xb2242a08)
"catch" (0xb2242c38)
"cl-block-wrapper" (0xb2242d28)
"block" (0xb2242e18)
"loop" (0xb2242f08)
"a/group-buffer-visible" (0xb2242fd0)
"and" (0xb22431e8)
"if" (0xb22432e8)
"when" (0xb22433d8)
"a/on-window-change" (0xb2243540)
"x-create-frame" (0xb22438f8)
"x-create-frame-with-faces" (0xb2243ab8)
"make-frame" (0xb2243c88)
"make-frame-on-display" (0xb2243e88)
"server-create-window-system-frame" (0xb2244070)
0x4bb29e0 PVEC_COMPILED
"funcall" (0xb2244220)
0x4b29fa0 PVEC_COMPILED
"funcall" (0xb2244620)
"server-process-filter" (0xb22449e8)
(gdb)
--8<---------------cut here---------------end--------------->8---

this time I was actually creating a new frame when the error occurred.
Actually, this error might only occur whenever I create a new frame.  As
I said before, I use a tight integration between my window manager and
emacs, and my window manager creates and deletes emacs frames all the
time.  I am not sure, though.

#+BEGIN_SRC emacs-lisp
(defun a/group-buffer-visisble ()
  (loop
   for frame being the frames
   thereis
   (and (not (a/frame-invisible frame))
        (loop for window being the windows of frame
              thereis (and (eq (window-buffer window)
                               (get-buffer gnus-group-buffer)))))))
#+END_SRC

a/on-window-change is called by window-configuration-change-hook and by
my window manager everytime windows are
selected/deselected/hidden/restored.

Hope this help!



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs 24 randomly hanging
  2012-02-19  5:28 emacs 24 randomly hanging Adam
  2012-02-19  9:45 ` Adam
  2012-02-19  9:54 ` Andreas Schwab
@ 2012-02-20 15:34 ` Dan Nicolaescu
  2012-02-21 10:10   ` Adam
  2012-02-21 10:43 ` Adam
  3 siblings, 1 reply; 22+ messages in thread
From: Dan Nicolaescu @ 2012-02-20 15:34 UTC (permalink / raw)
  To: emacs-devel

Adam <adam_w67@yahoo.com> writes:

> I am using GNU Emacs 24.0.93.1 (x86_64-unknown-linux-gnu, GTK+ Version
> 2.20.1) of 2012-02-15, built from sources.
> (I am running emacs in daemon mode with about three or five open X11
> clients.  Although the backtrace references Fx_create_frame, I *did* not
> create a frame.  I am using a tight intergration between my window
> manager and emacs though, and my window manager spawns about two
> `emacsclient -e' per second).
>
> Is this problem known?  Could this be fixed in emacs 24?

Can you recompile your emacs using --with-x-toolkit=lucid and see if you
can reproduce the problem using that version?
As shown by the warning printed by Gtk emacs --daemon, there are known
problems with that version that are not fixable in emacs.  It's possible
you are seeing those problems... 




^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs 24 randomly hanging
  2012-02-20 15:34 ` Dan Nicolaescu
@ 2012-02-21 10:10   ` Adam
  0 siblings, 0 replies; 22+ messages in thread
From: Adam @ 2012-02-21 10:10 UTC (permalink / raw)
  To: emacs-devel

Dan Nicolaescu <dann@gnu.org> writes:

> Adam <adam_w67@yahoo.com> writes:
>
>> I am using GNU Emacs 24.0.93.1 (x86_64-unknown-linux-gnu, GTK+ Version
>> 2.20.1) of 2012-02-15, built from sources.
>> (I am running emacs in daemon mode with about three or five open X11
>> clients.  Although the backtrace references Fx_create_frame, I *did* not
>> create a frame.  I am using a tight intergration between my window
>> manager and emacs though, and my window manager spawns about two
>> `emacsclient -e' per second).
>>
>> Is this problem known?  Could this be fixed in emacs 24?
>
> Can you recompile your emacs using --with-x-toolkit=lucid and see if you
> can reproduce the problem using that version?
> As shown by the warning printed by Gtk emacs --daemon, there are known
> problems with that version that are not fixable in emacs.  It's possible
> you are seeing those problems...

Unfortunately this did not solve my problem.  I am still experiencing
the same infinite loop.



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs 24 randomly hanging
  2012-02-19  5:28 emacs 24 randomly hanging Adam
                   ` (2 preceding siblings ...)
  2012-02-20 15:34 ` Dan Nicolaescu
@ 2012-02-21 10:43 ` Adam
  2012-02-21 15:41   ` Dan Nicolaescu
  3 siblings, 1 reply; 22+ messages in thread
From: Adam @ 2012-02-21 10:43 UTC (permalink / raw)
  To: emacs-devel

Adam <adam_w67@yahoo.com> writes:

> I am using GNU Emacs 24.0.93.1 (x86_64-unknown-linux-gnu, GTK+ Version
> 2.20.1) of 2012-02-15, built from sources.
>
> I am constantly experiencing my emacs hanging.  That is, C-g does not
> work, and the screen is not updated.  It happens about twice a day or
> so, which is very annoying, as I only have one emacs instance up
> and running in which I am doing all my work.
>
> I am pretty sure emacs hanging has been discussed to death, and I am
> pretty sure I just screwed my emacs configuration up somewhere.  What's
> worring me is that C-g does not work, though.  In fact, nothing works.
> I have to send a SIGKILL to my emacs process to get rid of it.
>
> Here's a backtrace:

[...]

> (I am running emacs in daemon mode with about three or five open X11
> clients.  Although the backtrace references Fx_create_frame, I *did* not
> create a frame.  I am using a tight intergration between my window
> manager and emacs though, and my window manager spawns about two
> `emacsclient -e' per second).
>
> Is this problem known?  Could this be fixed in emacs 24?

I am able to reproduce my problem with emacs -q.

#+BEGIN_SRC sh
#!/bin/bash

killall -9 emacsclient

emacs -q --daemon || exit 1

emacsclient -e "(progn (require 'cl)
(defun walk-frames ()
 (loop for frame being the frames))
(add-hook 'window-configuration-change-hook 'walk-frames))"

for I in {1..100}
do
    echo $I
    emacsclient -e "(walk-frames)" >/dev/null &
    emacsclient -c -e "(delete-frame)" >/dev/null &
done

wait

emacsclient -e "(kill-emacs 0)"
#+END_SRC

It is the very same backtrace.

Although this testcase is quite artificial, the underlying problem is
real.  I really hope this can be fixed for emacs 24.



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs 24 randomly hanging
  2012-02-21 10:43 ` Adam
@ 2012-02-21 15:41   ` Dan Nicolaescu
  2012-02-21 16:54     ` martin rudalics
  0 siblings, 1 reply; 22+ messages in thread
From: Dan Nicolaescu @ 2012-02-21 15:41 UTC (permalink / raw)
  To: emacs-devel

Adam <adam_w67@yahoo.com> writes:

> Adam <adam_w67@yahoo.com> writes:
>
>> I am using GNU Emacs 24.0.93.1 (x86_64-unknown-linux-gnu, GTK+ Version
>> 2.20.1) of 2012-02-15, built from sources.
>>
>> I am constantly experiencing my emacs hanging.  That is, C-g does not
>> work, and the screen is not updated.  It happens about twice a day or
>> so, which is very annoying, as I only have one emacs instance up
>> and running in which I am doing all my work.
>>
>> I am pretty sure emacs hanging has been discussed to death, and I am
>> pretty sure I just screwed my emacs configuration up somewhere.  What's
>> worring me is that C-g does not work, though.  In fact, nothing works.
>> I have to send a SIGKILL to my emacs process to get rid of it.
>>
>> Here's a backtrace:
>
> [...]
>
>> (I am running emacs in daemon mode with about three or five open X11
>> clients.  Although the backtrace references Fx_create_frame, I *did* not
>> create a frame.  I am using a tight intergration between my window
>> manager and emacs though, and my window manager spawns about two
>> `emacsclient -e' per second).
>>
>> Is this problem known?  Could this be fixed in emacs 24?
>
> I am able to reproduce my problem with emacs -q.
>
> #+BEGIN_SRC sh
> #!/bin/bash
>
> killall -9 emacsclient
>
> emacs -q --daemon || exit 1
>
> emacsclient -e "(progn (require 'cl)
> (defun walk-frames ()
>  (loop for frame being the frames))
> (add-hook 'window-configuration-change-hook 'walk-frames))"
>
> for I in {1..100}
> do
>     echo $I
>     emacsclient -e "(walk-frames)" >/dev/null &
>     emacsclient -c -e "(delete-frame)" >/dev/null &
> done
>
> wait
>
> emacsclient -e "(kill-emacs 0)"
> #+END_SRC

I can reproduce this.

It looks like there's an infinite loop in frame.c:next_frame.
Maybe the frame list is not completely initialized when this code is
run, there's a comment about looping forever in the function.
Unfortunately I don't have time to dig more.



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs 24 randomly hanging
  2012-02-21 15:41   ` Dan Nicolaescu
@ 2012-02-21 16:54     ` martin rudalics
  2012-02-21 18:42       ` Adam
  0 siblings, 1 reply; 22+ messages in thread
From: martin rudalics @ 2012-02-21 16:54 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: emacs-devel

 > It looks like there's an infinite loop in frame.c:next_frame.

Does the patch below help?

martin


=== modified file 'src/frame.c'
--- src/frame.c	2012-01-19 07:21:25 +0000
+++ src/frame.c	2012-02-21 16:46:43 +0000
@@ -924,7 +924,7 @@
  static Lisp_Object
  next_frame (Lisp_Object frame, Lisp_Object minibuf)
  {
-  Lisp_Object tail;
+  Lisp_Object tail, frames;
    int passed = 0;

    /* There must always be at least one frame in Vframe_list.  */
@@ -935,58 +935,57 @@
       forever.  Forestall that.  */
    CHECK_LIVE_FRAME (frame);

+  frames = Fcopy_sequence (Vframe_list);
    while (1)
-    for (tail = Vframe_list; CONSP (tail); tail = XCDR (tail))
+    for (tail = frames; CONSP (tail); tail = XCDR (tail))
        {
  	Lisp_Object f;

  	f = XCAR (tail);
-
-	if (passed
-	    && ((!FRAME_TERMCAP_P (XFRAME (f)) && !FRAME_TERMCAP_P (XFRAME (frame))
-                 && FRAME_KBOARD (XFRAME (f)) == FRAME_KBOARD (XFRAME (frame)))
-                || (FRAME_TERMCAP_P (XFRAME (f)) && FRAME_TERMCAP_P (XFRAME (frame))
-                    && FRAME_TTY (XFRAME (f)) == FRAME_TTY (XFRAME (frame)))))
+	if (passed)
  	  {
-	    /* Decide whether this frame is eligible to be returned.  */
-
  	    /* If we've looped all the way around without finding any
  	       eligible frames, return the original frame.  */
  	    if (EQ (f, frame))
  	      return f;
-
-	    /* Let minibuf decide if this frame is acceptable.  */
-	    if (NILP (minibuf))
-	      {
-		if (! FRAME_MINIBUF_ONLY_P (XFRAME (f)))
-		  return f;
-	      }
-	    else if (EQ (minibuf, Qvisible))
-	      {
-		FRAME_SAMPLE_VISIBILITY (XFRAME (f));
-		if (FRAME_VISIBLE_P (XFRAME (f)))
-		  return f;
-	      }
-	    else if (INTEGERP (minibuf) && XINT (minibuf) == 0)
-	      {
-		FRAME_SAMPLE_VISIBILITY (XFRAME (f));
-		if (FRAME_VISIBLE_P (XFRAME (f))
-		    || FRAME_ICONIFIED_P (XFRAME (f)))
-		  return f;
-	      }
-	    else if (WINDOWP (minibuf))
-	      {
-		if (EQ (FRAME_MINIBUF_WINDOW (XFRAME (f)), minibuf)
-		    || EQ (WINDOW_FRAME (XWINDOW (minibuf)), f)
-		    || EQ (WINDOW_FRAME (XWINDOW (minibuf)),
-			   FRAME_FOCUS_FRAME (XFRAME (f))))
-		  return f;
-	      }
-	    else
-	      return f;
+	    /* Decide whether this frame is eligible to be returned.  */
+	    else if ((!FRAME_TERMCAP_P (XFRAME (f)) && !FRAME_TERMCAP_P (XFRAME (frame))
+		      && FRAME_KBOARD (XFRAME (f)) == FRAME_KBOARD (XFRAME (frame)))
+		     || (FRAME_TERMCAP_P (XFRAME (f)) && FRAME_TERMCAP_P (XFRAME (frame))
+			 && FRAME_TTY (XFRAME (f)) == FRAME_TTY (XFRAME (frame))))
+	      {
+		/* Let minibuf decide if this frame is acceptable.  */
+		if (NILP (minibuf))
+		  {
+		    if (! FRAME_MINIBUF_ONLY_P (XFRAME (f)))
+		      return f;
+		  }
+		else if (EQ (minibuf, Qvisible))
+		  {
+		    FRAME_SAMPLE_VISIBILITY (XFRAME (f));
+		    if (FRAME_VISIBLE_P (XFRAME (f)))
+		      return f;
+		  }
+		else if (INTEGERP (minibuf) && XINT (minibuf) == 0)
+		  {
+		    FRAME_SAMPLE_VISIBILITY (XFRAME (f));
+		    if (FRAME_VISIBLE_P (XFRAME (f))
+			|| FRAME_ICONIFIED_P (XFRAME (f)))
+		      return f;
+		  }
+		else if (WINDOWP (minibuf))
+		  {
+		    if (EQ (FRAME_MINIBUF_WINDOW (XFRAME (f)), minibuf)
+			|| EQ (WINDOW_FRAME (XWINDOW (minibuf)), f)
+			|| EQ (WINDOW_FRAME (XWINDOW (minibuf)),
+			       FRAME_FOCUS_FRAME (XFRAME (f))))
+		      return f;
+		  }
+		else
+		  return f;
+	      }
  	  }
-
-	if (EQ (frame, f))
+	else if (EQ (frame, f))
  	  passed++;
        }
  }





^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs 24 randomly hanging
  2012-02-21 16:54     ` martin rudalics
@ 2012-02-21 18:42       ` Adam
  2012-02-22  8:26         ` martin rudalics
  0 siblings, 1 reply; 22+ messages in thread
From: Adam @ 2012-02-21 18:42 UTC (permalink / raw)
  To: emacs-devel

martin rudalics <rudalics@gmx.at> writes:

>  > It looks like there's an infinite loop in frame.c:next_frame.
>
> Does the patch below help?
>
> martin

I tried applying it via git apply - which failed.  After applying your
patch manually, I still does not work - the testcase results in a
hanging emacs.  I might have screwed the application of the patch up,
though.  Can anyone confirm my result?



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs 24 randomly hanging
  2012-02-21 18:42       ` Adam
@ 2012-02-22  8:26         ` martin rudalics
  2012-02-22  9:01           ` Andreas Schwab
  0 siblings, 1 reply; 22+ messages in thread
From: martin rudalics @ 2012-02-22  8:26 UTC (permalink / raw)
  To: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 928 bytes --]

 > I tried applying it via git apply - which failed.

Sorry.  My mailer probably mangled it.  I'll attach newer versions.

 > After applying your
 > patch manually, I still does not work - the testcase results in a
 > hanging emacs.  I might have screwed the application of the patch up,
 > though.  Can anyone confirm my result?

I can't test emacsclient well on my system (Windows XP).  Also, here
`frame-list' seems broken.  It's OK with one frame but for > 1 frame
evaluating (frame-list) can sometimes return nil.  I have to check
what's going on here, IIUC it takes some time (at least a couple of
seconds) for a frame to show up on Vframe_list.

In any case the patch I attached now tries to

(1) Check whether the frame passed to next_frame is in Vframe_list and
     quit if it isn't.

(2) Put a maximum of 100 frames investigated on the loop in next_frame
     so there should be no endless looping otherwise.

martin

[-- Attachment #2: frame.c.diff --]
[-- Type: text/plain, Size: 3676 bytes --]

=== modified file 'src/frame.c'
*** src/frame.c	2012-01-19 07:21:25 +0000
--- src/frame.c	2012-02-22 07:35:19 +0000
***************
*** 935,992 ****
       forever.  Forestall that.  */
    CHECK_LIVE_FRAME (frame);
  
!   while (1)
      for (tail = Vframe_list; CONSP (tail); tail = XCDR (tail))
        {
  	Lisp_Object f;
  
  	f = XCAR (tail);
  
! 	if (passed
! 	    && ((!FRAME_TERMCAP_P (XFRAME (f)) && !FRAME_TERMCAP_P (XFRAME (frame))
!                  && FRAME_KBOARD (XFRAME (f)) == FRAME_KBOARD (XFRAME (frame)))
!                 || (FRAME_TERMCAP_P (XFRAME (f)) && FRAME_TERMCAP_P (XFRAME (frame))
!                     && FRAME_TTY (XFRAME (f)) == FRAME_TTY (XFRAME (frame)))))
  	  {
- 	    /* Decide whether this frame is eligible to be returned.  */
- 
  	    /* If we've looped all the way around without finding any
  	       eligible frames, return the original frame.  */
  	    if (EQ (f, frame))
  	      return f;
! 
! 	    /* Let minibuf decide if this frame is acceptable.  */
! 	    if (NILP (minibuf))
! 	      {
! 		if (! FRAME_MINIBUF_ONLY_P (XFRAME (f)))
! 		  return f;
! 	      }
! 	    else if (EQ (minibuf, Qvisible))
! 	      {
! 		FRAME_SAMPLE_VISIBILITY (XFRAME (f));
! 		if (FRAME_VISIBLE_P (XFRAME (f)))
! 		  return f;
! 	      }
! 	    else if (INTEGERP (minibuf) && XINT (minibuf) == 0)
! 	      {
! 		FRAME_SAMPLE_VISIBILITY (XFRAME (f));
! 		if (FRAME_VISIBLE_P (XFRAME (f))
! 		    || FRAME_ICONIFIED_P (XFRAME (f)))
! 		  return f;
! 	      }
! 	    else if (WINDOWP (minibuf))
  	      {
! 		if (EQ (FRAME_MINIBUF_WINDOW (XFRAME (f)), minibuf)
! 		    || EQ (WINDOW_FRAME (XWINDOW (minibuf)), f)
! 		    || EQ (WINDOW_FRAME (XWINDOW (minibuf)),
! 			   FRAME_FOCUS_FRAME (XFRAME (f))))
! 		  return f;
  	      }
- 	    else
- 	      return f;
  	  }
  
! 	if (EQ (frame, f))
  	  passed++;
        }
  }
--- 935,997 ----
       forever.  Forestall that.  */
    CHECK_LIVE_FRAME (frame);
  
!   while (Fmemq (frame, Vframe_list) && (passed < 100))
      for (tail = Vframe_list; CONSP (tail); tail = XCDR (tail))
        {
  	Lisp_Object f;
  
  	f = XCAR (tail);
  
! 	if (passed)
  	  {
  	    /* If we've looped all the way around without finding any
  	       eligible frames, return the original frame.  */
  	    if (EQ (f, frame))
  	      return f;
! 	    else
  	      {
! 		passed++;
! 
! 		/* Decide whether this frame is eligible to be returned.  */
! 		if ((!FRAME_TERMCAP_P (XFRAME (f)) && !FRAME_TERMCAP_P (XFRAME (frame))
! 		     && FRAME_KBOARD (XFRAME (f)) == FRAME_KBOARD (XFRAME (frame)))
! 		    || (FRAME_TERMCAP_P (XFRAME (f)) && FRAME_TERMCAP_P (XFRAME (frame))
! 			&& FRAME_TTY (XFRAME (f)) == FRAME_TTY (XFRAME (frame))))
! 		  {
! 		    /* Let minibuf decide if this frame is acceptable.  */
! 		    if (NILP (minibuf))
! 		      {
! 			if (! FRAME_MINIBUF_ONLY_P (XFRAME (f)))
! 			  return f;
! 		      }
! 		    else if (EQ (minibuf, Qvisible))
! 		      {
! 			FRAME_SAMPLE_VISIBILITY (XFRAME (f));
! 			if (FRAME_VISIBLE_P (XFRAME (f)))
! 			  return f;
! 		      }
! 		    else if (INTEGERP (minibuf) && XINT (minibuf) == 0)
! 		      {
! 			FRAME_SAMPLE_VISIBILITY (XFRAME (f));
! 			if (FRAME_VISIBLE_P (XFRAME (f))
! 			    || FRAME_ICONIFIED_P (XFRAME (f)))
! 			  return f;
! 		      }
! 		    else if (WINDOWP (minibuf))
! 		      {
! 			if (EQ (FRAME_MINIBUF_WINDOW (XFRAME (f)), minibuf)
! 			    || EQ (WINDOW_FRAME (XWINDOW (minibuf)), f)
! 			    || EQ (WINDOW_FRAME (XWINDOW (minibuf)),
! 				   FRAME_FOCUS_FRAME (XFRAME (f))))
! 			  return f;
! 		      }
! 		    else
! 		      return f;
! 		  }
  	      }
  	  }
  
! 	else if (EQ (frame, f))
  	  passed++;
        }
  }


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs 24 randomly hanging
  2012-02-22  8:26         ` martin rudalics
@ 2012-02-22  9:01           ` Andreas Schwab
  2012-02-22  9:41             ` martin rudalics
  2012-02-22 10:55             ` Chong Yidong
  0 siblings, 2 replies; 22+ messages in thread
From: Andreas Schwab @ 2012-02-22  9:01 UTC (permalink / raw)
  To: martin rudalics; +Cc: emacs-devel

martin rudalics <rudalics@gmx.at> writes:

> what's going on here, IIUC it takes some time (at least a couple of
> seconds) for a frame to show up on Vframe_list.

It should not matter at all, because x_create_frame cannot make the new
frame known to lisp before it is added to Vframe_alist.

> In any case the patch I attached now tries to
>
> (1) Check whether the frame passed to next_frame is in Vframe_list and
>     quit if it isn't.
>
> (2) Put a maximum of 100 frames investigated on the loop in next_frame
>     so there should be no endless looping otherwise.

This is just doctoring the symptoms.  There is an invariant that *every*
live frame is on Vframe_alist.  If that invariant is violated then this
is the bug that must be fixed.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs 24 randomly hanging
  2012-02-22  9:01           ` Andreas Schwab
@ 2012-02-22  9:41             ` martin rudalics
  2012-02-22 14:49               ` Stefan Monnier
  2012-02-22 10:55             ` Chong Yidong
  1 sibling, 1 reply; 22+ messages in thread
From: martin rudalics @ 2012-02-22  9:41 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 1190 bytes --]

 >> what's going on here, IIUC it takes some time (at least a couple of
 >> seconds) for a frame to show up on Vframe_list.
 >
 > It should not matter at all, because x_create_frame cannot make the new
 > frame known to lisp before it is added to Vframe_alist.

I suppose you mean Vframe_list.  At least on my system I can see frames
that are not returned by `frame-list'.

 >> (1) Check whether the frame passed to next_frame is in Vframe_list and
 >>     quit if it isn't.
 >>
 >> (2) Put a maximum of 100 frames investigated on the loop in next_frame
 >>     so there should be no endless looping otherwise.
 >
 > This is just doctoring the symptoms.

What did you expect me to do?  I first have to find out whether the
looping really is in next_frame.  Or do you have a definitive clue?

BTW my doctoring patch has an obvious bug which should be corrected in
the new attachment.

 > There is an invariant that *every*
 > live frame is on Vframe_alist.  If that invariant is violated then this
 > is the bug that must be fixed.

Such an invariant seems obvious but I don't see it neither formulated
nor preserved.  And why is Vframe_alist "V" prefixed but not available
in Lisp?

martin

[-- Attachment #2: frame.c.diff --]
[-- Type: text/plain, Size: 3684 bytes --]

=== modified file 'src/frame.c'
*** src/frame.c	2012-01-19 07:21:25 +0000
--- src/frame.c	2012-02-22 09:30:41 +0000
***************
*** 935,992 ****
       forever.  Forestall that.  */
    CHECK_LIVE_FRAME (frame);
  
!   while (1)
      for (tail = Vframe_list; CONSP (tail); tail = XCDR (tail))
        {
  	Lisp_Object f;
  
  	f = XCAR (tail);
  
! 	if (passed
! 	    && ((!FRAME_TERMCAP_P (XFRAME (f)) && !FRAME_TERMCAP_P (XFRAME (frame))
!                  && FRAME_KBOARD (XFRAME (f)) == FRAME_KBOARD (XFRAME (frame)))
!                 || (FRAME_TERMCAP_P (XFRAME (f)) && FRAME_TERMCAP_P (XFRAME (frame))
!                     && FRAME_TTY (XFRAME (f)) == FRAME_TTY (XFRAME (frame)))))
  	  {
- 	    /* Decide whether this frame is eligible to be returned.  */
- 
  	    /* If we've looped all the way around without finding any
  	       eligible frames, return the original frame.  */
  	    if (EQ (f, frame))
  	      return f;
! 
! 	    /* Let minibuf decide if this frame is acceptable.  */
! 	    if (NILP (minibuf))
! 	      {
! 		if (! FRAME_MINIBUF_ONLY_P (XFRAME (f)))
! 		  return f;
! 	      }
! 	    else if (EQ (minibuf, Qvisible))
! 	      {
! 		FRAME_SAMPLE_VISIBILITY (XFRAME (f));
! 		if (FRAME_VISIBLE_P (XFRAME (f)))
! 		  return f;
! 	      }
! 	    else if (INTEGERP (minibuf) && XINT (minibuf) == 0)
! 	      {
! 		FRAME_SAMPLE_VISIBILITY (XFRAME (f));
! 		if (FRAME_VISIBLE_P (XFRAME (f))
! 		    || FRAME_ICONIFIED_P (XFRAME (f)))
! 		  return f;
! 	      }
! 	    else if (WINDOWP (minibuf))
  	      {
! 		if (EQ (FRAME_MINIBUF_WINDOW (XFRAME (f)), minibuf)
! 		    || EQ (WINDOW_FRAME (XWINDOW (minibuf)), f)
! 		    || EQ (WINDOW_FRAME (XWINDOW (minibuf)),
! 			   FRAME_FOCUS_FRAME (XFRAME (f))))
! 		  return f;
  	      }
- 	    else
- 	      return f;
  	  }
  
! 	if (EQ (frame, f))
  	  passed++;
        }
  }
--- 935,997 ----
       forever.  Forestall that.  */
    CHECK_LIVE_FRAME (frame);
  
!   while (!NILP (Fmemq (frame, Vframe_list)) && (passed < 100))
      for (tail = Vframe_list; CONSP (tail); tail = XCDR (tail))
        {
  	Lisp_Object f;
  
  	f = XCAR (tail);
  
! 	if (passed)
  	  {
  	    /* If we've looped all the way around without finding any
  	       eligible frames, return the original frame.  */
  	    if (EQ (f, frame))
  	      return f;
! 	    else
  	      {
! 		passed++;
! 
! 		/* Decide whether this frame is eligible to be returned.  */
! 		if ((!FRAME_TERMCAP_P (XFRAME (f)) && !FRAME_TERMCAP_P (XFRAME (frame))
! 		     && FRAME_KBOARD (XFRAME (f)) == FRAME_KBOARD (XFRAME (frame)))
! 		    || (FRAME_TERMCAP_P (XFRAME (f)) && FRAME_TERMCAP_P (XFRAME (frame))
! 			&& FRAME_TTY (XFRAME (f)) == FRAME_TTY (XFRAME (frame))))
! 		  {
! 		    /* Let minibuf decide if this frame is acceptable.  */
! 		    if (NILP (minibuf))
! 		      {
! 			if (! FRAME_MINIBUF_ONLY_P (XFRAME (f)))
! 			  return f;
! 		      }
! 		    else if (EQ (minibuf, Qvisible))
! 		      {
! 			FRAME_SAMPLE_VISIBILITY (XFRAME (f));
! 			if (FRAME_VISIBLE_P (XFRAME (f)))
! 			  return f;
! 		      }
! 		    else if (INTEGERP (minibuf) && XINT (minibuf) == 0)
! 		      {
! 			FRAME_SAMPLE_VISIBILITY (XFRAME (f));
! 			if (FRAME_VISIBLE_P (XFRAME (f))
! 			    || FRAME_ICONIFIED_P (XFRAME (f)))
! 			  return f;
! 		      }
! 		    else if (WINDOWP (minibuf))
! 		      {
! 			if (EQ (FRAME_MINIBUF_WINDOW (XFRAME (f)), minibuf)
! 			    || EQ (WINDOW_FRAME (XWINDOW (minibuf)), f)
! 			    || EQ (WINDOW_FRAME (XWINDOW (minibuf)),
! 				   FRAME_FOCUS_FRAME (XFRAME (f))))
! 			  return f;
! 		      }
! 		    else
! 		      return f;
! 		  }
  	      }
  	  }
  
! 	else if (EQ (frame, f))
  	  passed++;
        }
  }


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs 24 randomly hanging
  2012-02-22  9:01           ` Andreas Schwab
  2012-02-22  9:41             ` martin rudalics
@ 2012-02-22 10:55             ` Chong Yidong
  2012-02-22 16:28               ` Eli Zaretskii
  1 sibling, 1 reply; 22+ messages in thread
From: Chong Yidong @ 2012-02-22 10:55 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: martin rudalics, emacs-devel

[-- Attachment #1: Type: text/plain, Size: 4600 bytes --]

Andreas Schwab <schwab@linux-m68k.org> writes:

> This is just doctoring the symptoms.  There is an invariant that *every*
> live frame is on Vframe_alist.  If that invariant is violated then this
> is the bug that must be fixed.

That's apparently indeed the problem.  I patched next_frame to abort
when the target frame isn't on Vframe_list (patch attached), and got the
following backtrace with Adam's recipe.

The problem is that x-create-frame calls x_set_menu_bar_lines, which
calls window-configuration-change-hook.  Because that hook is called in
the middle of x-create-frame, the (half-initialized) frame isn't on
Vframe_list yet.

Patch welcome; I don't have time to work on this further right now.



394	  kill (getpid (), SIGABRT);
(gdb) bt
#0  abort () at emacs.c:394
#1  0x00000000004226d7 in next_frame (frame=17277365, minibuf=12761602)
    at frame.c:944
#2  0x000000000042307e in Fnext_frame (frame=17277365, miniframe=12761602)
    at frame.c:1101
#3  0x000000000060637a in eval_sub (form=20840342) at eval.c:2347
#4  0x000000000060271b in Fsetq (args=20840470) at eval.c:455
...
#14 0x0000000000603f3c in Fcatch (args=20841622) at eval.c:1237
...
#21 0x0000000000607c8e in Ffuncall (nargs=1, args=0x7fffffff8d08)
    at eval.c:3057
#22 0x000000000060713a in call0 (fn=21122898) at eval.c:2750
#23 0x000000000048bb27 in run_funs (funs=14101542) at window.c:2872
#24 0x000000000048be39 in run_window_configuration_change_hook (f=0x107a1b0)
    at window.c:2933
#25 0x00000000005100ab in x_set_menu_bar_lines (f=0x107a1b0, value=0, 
    oldval=12761602) at xfns.c:1269
#26 0x000000000042701f in x_set_frame_parameters (f=0x107a1b0, alist=12761602)
    at frame.c:2929
#27 0x000000000042a0dd in x_default_parameter (f=0x107a1b0, alist=19012854, 
    prop=12942274, deflt=0, xprop=0x0, xclass=0x0, type=RES_TYPE_NUMBER)
    at frame.c:3938
#28 0x0000000000513ce8 in Fx_create_frame (parms=19012854) at xfns.c:3327
#29 0x00000000006079cb in Ffuncall (nargs=2, args=0x7fffffff91b0)
    at eval.c:2996
#30 0x0000000000653cc0 in exec_byte_code (bytestr=9928737, vector=9928773, 
    maxdepth=16, args_template=12761602, nargs=0, args=0x0) at bytecode.c:785
#31 0x00000000006083f2 in funcall_lambda (fun=9928669, nargs=1, 
    arg_vector=0x7fffffff9688) at eval.c:3227
#32 0x0000000000607bda in Ffuncall (nargs=2, args=0x7fffffff9680)
    at eval.c:3045
...
#56 0x0000000000607113 in apply1 (fn=21078306, arg=14151190) at eval.c:2739
#57 0x0000000000660a34 in read_process_output_call (fun_and_args=14151174)
    at process.c:5002
#58 0x00000000006047e1 in internal_condition_case_1 (
    bfun=0x660a06 <read_process_output_call>, arg=14151174, handlers=12761602, 
    hfun=0x660a36 <read_process_output_error_handler>) at eval.c:1547
#59 0x000000000066110b in read_process_output (proc=20995733, channel=3123)
    at process.c:5201
#60 0x00000000006603d3 in wait_reading_process_output (time_limit=30, 
    microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=12761602, 
    wait_proc=0x0, just_wait_proc=0) at process.c:4844
#61 0x000000000041f8da in sit_for (timeout=120, reading=1, do_display=1)
    at dispnew.c:6063
#62 0x000000000056977c in read_char (commandflag=1, nmaps=2, 
    maps=0x7fffffffd5a0, prev_event=12761602, used_mouse_menu=0x7fffffffd6e8, 
    end_time=0x0) at keyboard.c:2690
#63 0x0000000000577285 in read_key_sequence (keybuf=0x7fffffffd8b0, 
    bufsize=30, prompt=12761602, dont_downcase_last=0, 
    can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9302
#64 0x0000000000566f26 in command_loop_1 () at keyboard.c:1448
#65 0x000000000060467a in internal_condition_case (
    bfun=0x566b41 <command_loop_1>, handlers=12813794, 
    hfun=0x566406 <cmd_error>) at eval.c:1509
#66 0x0000000000566830 in command_loop_2 (ignore=12761602) at keyboard.c:1159
#67 0x0000000000604031 in internal_catch (tag=12809586, 
    func=0x56680a <command_loop_2>, arg=12761602) at eval.c:1266
#68 0x00000000005667e3 in command_loop () at keyboard.c:1138
#69 0x0000000000565f4a in recursive_edit_1 () at keyboard.c:758
#70 0x00000000005660ed in Frecursive_edit () at keyboard.c:822
#71 0x000000000056418e in main (argc=1, argv=0x7fffffffe198) at emacs.c:1715

Lisp Backtrace:
"next-frame" (0xffff7c20)
"setq" (0xffff7ec8)
"while" (0xffff80f8)
"let*" (0xffff8378)
"catch" (0xffff86c8)
"cl-block-wrapper" (0xffff8838)
"block" (0xffff89a8)
"loop" (0xffff8b18)
"walk-frames" (0xffff8d10)
"x-create-frame" (0xffff91b8)
"x-create-frame-with-faces" (0xffff9688)
"make-frame" (0xffff9b68)
"make-frame-on-display" (0xffffa078)
"server-create-window-system-frame" (0xffffa5e0)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: frame.c.patch --]
[-- Type: text/x-diff, Size: 517 bytes --]

=== modified file 'src/frame.c'
*** src/frame.c	2012-01-19 07:21:25 +0000
--- src/frame.c	2012-02-22 10:43:37 +0000
***************
*** 935,940 ****
--- 935,949 ----
       forever.  Forestall that.  */
    CHECK_LIVE_FRAME (frame);
  
+   passed = 0;
+   for (tail = Vframe_list; CONSP (tail); tail = XCDR (tail))
+     if (EQ (frame, XCAR (tail)))
+       passed++;
+ 
+   if (passed == 0)
+     abort ();
+ 
+   passed = 0;
    while (1)
      for (tail = Vframe_list; CONSP (tail); tail = XCDR (tail))
        {


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs 24 randomly hanging
  2012-02-22  9:41             ` martin rudalics
@ 2012-02-22 14:49               ` Stefan Monnier
  2012-02-24 18:43                 ` martin rudalics
  0 siblings, 1 reply; 22+ messages in thread
From: Stefan Monnier @ 2012-02-22 14:49 UTC (permalink / raw)
  To: martin rudalics; +Cc: Andreas Schwab, emacs-devel

>> There is an invariant that *every* live frame is on Vframe_alist.
>> If that invariant is violated then this is the bug that must
>> be fixed.
> Such an invariant seems obvious but I don't see it neither formulated
> nor preserved.

It's indeed an important invariant.

> And why is Vframe_list "V" prefixed but not available in Lisp?

I don't know why it has a V, but I suspect it's because Vbuffer_alist
also has a "V".  As for why it's not available to Lisp, it's
specifically because the above mentioned invariant needs to be preserved
and the C code might break otherwise.  Actually, now that I think about
it I have a vague recollection that Vbuffer_alist was exported to Lisp
at some point in the past, and that it later was hidden so as to prevent
Lisp code from breaking the invariant.  So if my memory isn't screwing
with me, that would explain Vbuffer_alist's "V".


        Stefan



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs 24 randomly hanging
  2012-02-22 10:55             ` Chong Yidong
@ 2012-02-22 16:28               ` Eli Zaretskii
  2012-02-23  8:05                 ` Chong Yidong
  0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2012-02-22 16:28 UTC (permalink / raw)
  To: Chong Yidong; +Cc: rudalics, schwab, emacs-devel

> From: Chong Yidong <cyd@gnu.org>
> Date: Wed, 22 Feb 2012 18:55:29 +0800
> Cc: martin rudalics <rudalics@gmx.at>, emacs-devel@gnu.org
> 
> The problem is that x-create-frame calls x_set_menu_bar_lines, which
> calls window-configuration-change-hook.  Because that hook is called in
> the middle of x-create-frame, the (half-initialized) frame isn't on
> Vframe_list yet.
> 
> Patch welcome; I don't have time to work on this further right now.

How about "don't do it"?



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs 24 randomly hanging
  2012-02-22 16:28               ` Eli Zaretskii
@ 2012-02-23  8:05                 ` Chong Yidong
  2012-02-23 14:03                   ` Christopher Schmidt
  2012-02-24 18:43                   ` martin rudalics
  0 siblings, 2 replies; 22+ messages in thread
From: Chong Yidong @ 2012-02-23  8:05 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rudalics, schwab, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>> The problem is that x-create-frame calls x_set_menu_bar_lines, which
>> calls window-configuration-change-hook.  Because that hook is called in
>> the middle of x-create-frame, the (half-initialized) frame isn't on
>> Vframe_list yet.
>> 
>> Patch welcome; I don't have time to work on this further right now.
>
> How about "don't do it"?

I committed a change to inhibit window-configuration-change-hook there.

There's another possible problem: x-create-frame sets the
background-color parameter prior to the frame being put on Vframe_list.
IIUC, this parameter needs to be set before we can consider the frame
live, because the frame size calculation depends on the default face,
which may in turn depend on the background mode.  But setting the
parameter causes a Lisp call to frame-set-background-mode, so we can in
principle get in trouble if the user redefines or advises that function.
But that's a sufficiently obscure corner case that we can leave it for
post-24.1, I think.



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs 24 randomly hanging
  2012-02-23  8:05                 ` Chong Yidong
@ 2012-02-23 14:03                   ` Christopher Schmidt
  2012-02-23 16:39                     ` Christopher Schmidt
  2012-02-23 17:42                     ` Chong Yidong
  2012-02-24 18:43                   ` martin rudalics
  1 sibling, 2 replies; 22+ messages in thread
From: Christopher Schmidt @ 2012-02-23 14:03 UTC (permalink / raw)
  To: emacs-devel; +Cc: Chong Yidong

Chong Yidong <cyd@gnu.org> writes:

Hi Chong,

> I committed a change to inhibit window-configuration-change-hook there.

I think your patch is buggy - window-configuration-change-hook is not
called at all.

recipe:

emacs -q
eval: (add-hook 'window-configuration-change-hook (lambda () (message
"rms")))
C-x 2

There is "rms" message.

        Christopher



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs 24 randomly hanging
  2012-02-23 14:03                   ` Christopher Schmidt
@ 2012-02-23 16:39                     ` Christopher Schmidt
  2012-02-23 17:42                     ` Chong Yidong
  1 sibling, 0 replies; 22+ messages in thread
From: Christopher Schmidt @ 2012-02-23 16:39 UTC (permalink / raw)
  To: emacs-devel

Christopher Schmidt <christopher@ch.ristopher.com> writes:

[...]
> There is "rms" message.

typo, that should read: there is no "rms" message.



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs 24 randomly hanging
  2012-02-23 14:03                   ` Christopher Schmidt
  2012-02-23 16:39                     ` Christopher Schmidt
@ 2012-02-23 17:42                     ` Chong Yidong
  1 sibling, 0 replies; 22+ messages in thread
From: Chong Yidong @ 2012-02-23 17:42 UTC (permalink / raw)
  To: emacs-devel

Christopher Schmidt <christopher@ch.ristopher.com> writes:

> I think your patch is buggy - window-configuration-change-hook is not
> called at all.

Forgot to initialize a global.  Should be fixed now, thanks.



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs 24 randomly hanging
  2012-02-23  8:05                 ` Chong Yidong
  2012-02-23 14:03                   ` Christopher Schmidt
@ 2012-02-24 18:43                   ` martin rudalics
  1 sibling, 0 replies; 22+ messages in thread
From: martin rudalics @ 2012-02-24 18:43 UTC (permalink / raw)
  To: Chong Yidong; +Cc: Eli Zaretskii, schwab, emacs-devel

 > There's another possible problem: x-create-frame sets the
 > background-color parameter prior to the frame being put on Vframe_list.
 > IIUC, this parameter needs to be set before we can consider the frame
 > live, because the frame size calculation depends on the default face,
 > which may in turn depend on the background mode.  But setting the
 > parameter causes a Lisp call to frame-set-background-mode, so we can in
 > principle get in trouble if the user redefines or advises that function.
 > But that's a sufficiently obscure corner case that we can leave it for
 > post-24.1, I think.

Is there any reason not to disable all hooks when creating a frame?  If
it were just for `window-configuration-change-hook' it might be simpler
to check in run_window_configuration_change_hook whether the frame is on
Vframe_list.

martin



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: emacs 24 randomly hanging
  2012-02-22 14:49               ` Stefan Monnier
@ 2012-02-24 18:43                 ` martin rudalics
  0 siblings, 0 replies; 22+ messages in thread
From: martin rudalics @ 2012-02-24 18:43 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Andreas Schwab, emacs-devel

 > I don't know why it has a V, but I suspect it's because Vbuffer_alist
 > also has a "V".  As for why it's not available to Lisp, it's
 > specifically because the above mentioned invariant needs to be preserved
 > and the C code might break otherwise.  Actually, now that I think about
 > it I have a vague recollection that Vbuffer_alist was exported to Lisp
 > at some point in the past, and that it later was hidden so as to prevent
 > Lisp code from breaking the invariant.  So if my memory isn't screwing
 > with me, that would explain Vbuffer_alist's "V".

It seems that Vwindow_list has a similar (pre-)history.  Most of this
must have happened before change logs were invented.

martin



^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2012-02-24 18:43 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-02-19  5:28 emacs 24 randomly hanging Adam
2012-02-19  9:45 ` Adam
2012-02-19  9:54 ` Andreas Schwab
2012-02-20  7:23   ` Adam
2012-02-20 15:34 ` Dan Nicolaescu
2012-02-21 10:10   ` Adam
2012-02-21 10:43 ` Adam
2012-02-21 15:41   ` Dan Nicolaescu
2012-02-21 16:54     ` martin rudalics
2012-02-21 18:42       ` Adam
2012-02-22  8:26         ` martin rudalics
2012-02-22  9:01           ` Andreas Schwab
2012-02-22  9:41             ` martin rudalics
2012-02-22 14:49               ` Stefan Monnier
2012-02-24 18:43                 ` martin rudalics
2012-02-22 10:55             ` Chong Yidong
2012-02-22 16:28               ` Eli Zaretskii
2012-02-23  8:05                 ` Chong Yidong
2012-02-23 14:03                   ` Christopher Schmidt
2012-02-23 16:39                     ` Christopher Schmidt
2012-02-23 17:42                     ` Chong Yidong
2012-02-24 18:43                   ` martin rudalics

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).