bug#8272: Emacs with X11 forwarding

bug#8272: Emacs with X11 forwarding

[Andrew Myers]

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

Hi All,
I'm trying to track down a really strange problem with emacs while
XForwarding and running Allegro Common lisp.  I don't know yet if this is  a
problem with emacs, X, or Allegro Lisp but I thought I would post here and
see if anyone had ideas.

Here's the situation,
Mac Laptops running either Leopard or Snow Leopard log into Linux servers
and set up X forwarding (either via ssh -Xy login or telnet and then setting
the DISPLAY variable to a remote machine).
Run emacs so that it comes up on the local Mac desktop, either using the
default X11.app or XQuartz
Start Allegro Common Lisp by running fi:common-lisp

Here's where things get strange:
If I :
Open emacs
Start lisp
Type in "(+ 4 5)"
Press Return twice //This runs the command (+ 4 5) and adds a newline after
the command

Everything will work properly, but emacs will lock up if I
A) Only hit Return once to activate the command, or
B) Only hit Return a bunch of times without typing in some kind of lisp
command.

I've tried this with both emacs 21 and 23 and see the same thing.  If I log
into a Mac or Solaris machine everything works fine.  I have the source for
emacs 23 and have gotten a backtrace from after emacs locks up, does it give
anyone ideas on where I should go next?

Thanks,
Andrew Myers
STScI

Thread 1 (process 17594):
#0  0x000000316e4cd1c3 in __select_nocancel () from /lib64/libc.so.6
#1  0x0000000000631ace in select_wrapper (n=7, rfd=0x7fffffff93d0, wfd=0x0,
xfd=0x0, tmo=0x7fffffff9330)
    at process.c:4582
#2  0x0000000000632b11 in wait_reading_process_output (time_limit=0,
microsecs=0, read_kbd=0, do_display=0,
    wait_for_cell=12384658, wait_proc=0x2e50850, just_wait_proc=0) at
process.c:4943
#3  0x000000000063121a in Faccept_process_output (process=48564309,
seconds=12384658, millisec=12384658,
    just_this_one=12384658) at process.c:4323
#4  0x00000000005cee8e in Ffuncall (nargs=2, args=0x7fffffff9690) at
eval.c:3034
#5  0x0000000000626023 in Fbyte_code (bytestr=42630353, vector=44402853,
maxdepth=16) at bytecode.c:680
#6  0x00000000005cf6e3 in funcall_lambda (fun=44403157, nargs=1,
arg_vector=0x7fffffff9bc8) at eval.c:3211
#7  0x00000000005cf0e7 in Ffuncall (nargs=2, args=0x7fffffff9bc0) at
eval.c:3070
#8  0x0000000000626023 in Fbyte_code (bytestr=42625457, vector=44401253,
maxdepth=28) at bytecode.c:680
#9  0x00000000005cf6e3 in funcall_lambda (fun=44401557, nargs=3,
arg_vector=0x7fffffffa118) at eval.c:3211
#10 0x00000000005cf0e7 in Ffuncall (nargs=4, args=0x7fffffffa110) at
eval.c:3070
#11 0x0000000000626023 in Fbyte_code (bytestr=42585873, vector=44400837,
maxdepth=20) at bytecode.c:680
#12 0x00000000005cf6e3 in funcall_lambda (fun=44401125, nargs=1,
arg_vector=0x7fffffffa658) at eval.c:3211
#13 0x00000000005cf0e7 in Ffuncall (nargs=2, args=0x7fffffffa650) at
eval.c:3070
#14 0x0000000000626023 in Fbyte_code (bytestr=44483617, vector=46044309,
maxdepth=12) at bytecode.c:680
#15 0x00000000005cf6e3 in funcall_lambda (fun=46060437, nargs=0,
arg_vector=0x7fffffffab88) at eval.c:3211
#16 0x00000000005cf0e7 in Ffuncall (nargs=1, args=0x7fffffffab80) at
eval.c:3070
#17 0x0000000000626023 in Fbyte_code (bytestr=44485537, vector=46030325,
maxdepth=8) at bytecode.c:680
#18 0x00000000005cf6e3 in funcall_lambda (fun=46085717, nargs=0,
arg_vector=0x7fffffffb0a8) at eval.c:3211
#19 0x00000000005cf0e7 in Ffuncall (nargs=1, args=0x7fffffffb0a0) at
eval.c:3070
#20 0x0000000000626023 in Fbyte_code (bytestr=44485153, vector=46132821,
maxdepth=8) at bytecode.c:680
#21 0x00000000005cf6e3 in funcall_lambda (fun=46136933, nargs=0,
arg_vector=0x7fffffffb500) at eval.c:3211
#22 0x00000000005cf35e in apply_lambda (fun=46136933, args=12384658,
eval_flag=1) at eval.c:3135
#23 0x00000000005cdd42 in Feval (form=46101078) at eval.c:2388
#24 0x00000000005cc266 in internal_condition_case_1 (bfun=0x5cd59b <Feval>,
arg=46101078, handlers=12451874,
    hfun=0x533483 <menu_item_eval_property_1>) at eval.c:1538
#25 0x0000000000533528 in menu_item_eval_property (sexpr=46101078) at
keyboard.c:7929
#26 0x0000000000533c3c in parse_menu_item (item=12384658, inmenubar=0) at
keyboard.c:8107
#27 0x000000000046fd91 in single_menu_item (key=46391282, item=51128918,
dummy=12384658, skp_v=0x7fffffffbbe0)
    at menu.c:346
#28 0x000000000053ee0a in map_keymap_item (fun=0x46fd56 <single_menu_item>,
args=12384658, key=46391282,
    val=51128918, data=0x7fffffffbbe0) at keymap.c:649
#29 0x000000000053ef9c in map_keymap_internal (map=43326838, fun=0x46fd56
<single_menu_item>, args=12384658,
    data=0x7fffffffbbe0) at keymap.c:687
#30 0x000000000053f1eb in map_keymap_canonical (map=43326838, fun=0x46fd56
<single_menu_item>, args=12384658,
    data=0x7fffffffbbe0) at keymap.c:756
#31 0x000000000046fcd5 in single_keymap_panes (keymap=51324406,
pane_name=12384658, prefix=46368338,
    maxdepth=9) at menu.c:310
#32 0x000000000046fef4 in single_menu_item (key=46368338, item=51324742,
dummy=12384658, skp_v=0x7fffffffbe80)
    at menu.c:449
#33 0x000000000053ee0a in map_keymap_item (fun=0x46fd56 <single_menu_item>,
args=12384658, key=46368338,
    val=51324742, data=0x7fffffffbe80) at keymap.c:649
#34 0x000000000053ef9c in map_keymap_internal (map=43425446, fun=0x46fd56
<single_menu_item>, args=12384658,
    data=0x7fffffffbe80) at keymap.c:687
#35 0x000000000053f1eb in map_keymap_canonical (map=43425446, fun=0x46fd56
<single_menu_item>, args=12384658,
    data=0x7fffffffbe80) at keymap.c:756
#36 0x000000000046fcd5 in single_keymap_panes (keymap=51324342,
pane_name=43966881, prefix=46368146,
    maxdepth=10) at menu.c:310
#37 0x0000000000470499 in parse_single_submenu (item_key=46368146,
item_name=43966881, maps=12384658)
    at menu.c:571
#38 0x0000000000473225 in set_frame_menubar (f=0x114b410, first_time=0,
deep_p=1) at xmenu.c:1080
#39 0x00000000004728cd in x_activate_menubar (f=0x114b410) at xmenu.c:684
#40 0x000000000052cc44 in kbd_buffer_get_event (kbp=0x7fffffffcdd8,
used_mouse_menu=0x7fffffffd4c4,
    end_time=0x0) at keyboard.c:4246
#41 0x000000000052a4ae in read_char (commandflag=1, nmaps=5,
maps=0x7fffffffd140, prev_event=12384658,
---Type <return> to continue, or q <return> to quit---
    used_mouse_menu=0x7fffffffd4c4, end_time=0x0) at keyboard.c:3079
#42 0x000000000053672d in read_key_sequence (keybuf=0x7fffffffd870,
bufsize=30, prompt=12384658,
    dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1)
at keyboard.c:9512
#43 0x0000000000526689 in command_loop_1 () at keyboard.c:1643
#44 0x00000000005cc0ca in internal_condition_case (bfun=0x5262f6
<command_loop_1>, handlers=12451874,
    hfun=0x525c54 <cmd_error>) at eval.c:1490
#45 0x0000000000526015 in command_loop_2 () at keyboard.c:1360
#46 0x00000000005cba7c in internal_catch (tag=12444690, func=0x525ffb
<command_loop_2>, arg=12384658)
    at eval.c:1226
#47 0x0000000000525fd5 in command_loop () at keyboard.c:1339
#48 0x000000000052579a in recursive_edit_1 () at keyboard.c:954
#49 0x000000000052593d in Frecursive_edit () at keyboard.c:1016
#50 0x0000000000523d9f in main (argc=1, argv=0x7fffffffe1b8) at emacs.c:1833

Lisp Backtrace:
"accept-process-output" (0xffff9698)
"fi::wait-for-reply-to-come-back" (0xffff9bc8)
"lep::eval-session-in-lisp" (0xffffa118)
"fi:eval-in-lisp" (0xffffa658)
"fi::connection-open-composer-loaded" (0xffffab88)
"fi::connection-open-composer-loaded-cached" (0xffffb0a8)
"fi::connection-open-composer-loaded-and-stopped" (0xffffb500)

[-- Attachment #2: Type: text/html, Size: 7983 bytes --]

bug#8272: Follow up

[Andrew Myers]

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

It appears that this was caused by a patch to the Allegro elisp files made
by one of our developers.  I attached to the Allegro lisp process with gdb
and saw that it was also hung on __select_nocancel().
The patch to elisp removed an initialization message from emacs to the alisp
subprocess.  My best guess right now is that this meant Allegro caught a
message meant for emacs through an inherited file descriptor.  Is this
possible?
Thanks,
Andrew Myers

[-- Attachment #2: Type: text/html, Size: 474 bytes --]

bug#8272: Follow up

[Stefan Kangas]

Andrew Myers <asm198@gmail.com> writes:

> It appears that this was caused by a patch to the Allegro elisp files made by one of our developers.  I attached to the Allegro lisp process with gdb and saw that it was also hung on __select_nocancel().
> The patch to elisp removed an initialization message from emacs to the alisp subprocess.  My best guess right now is that this meant Allegro caught a message meant for emacs through an inherited file descriptor.  Is this possible?
> Thanks,
> Andrew Myers

This bug report unfortunately never got a reply 8 years ago.

It seems like this was not a bug in Emacs, since you write above that
it was caused by an external patch.  I'm therefore closing this bug.

If you believe this is wrong and this is still an issue, please reopen
the bug report.

Best regards,
Stefan Kangas