Infinite display loop (in `redisplay_window')

[Daniel Brockman]

I have a Multi-TTY Emacs process that is stuck in an endless
display loop.  The function `redisplay_window' never returns.

This happened when trying to open an article in Gnus.
The article does not seem to contain anything strange and I
can open it in a fresh Emacs instance.

When I noticed that Emacs appeared to have hung, I hit C-g.
This caused a message from Gnus to be displayed, saying that
some NNTP process was aborted.  After this, Emacs would
redisplay itself but would not respond to any commands.
It kept showing the wristwatch mouse cursor.

Then I attached to the process with GDB and tried to return
myself out of the problem.  I had Emacs return from all
display-related functions all the way out to `command_loop'.
Continuing from here, Emacs would not display anything but
did respond to C-g by flashing.

So I typed M-x top-level RET.  This again plunged Emacs into
the infinite display loop, and this is where I am now.

I don't know how to debug this, but here is a backtrace:

#0  0x0807b476 in redisplay_window (window=150521284, just_this_one_p=0)
    at xdisp.c:12133
#1  0x0807d433 in redisplay_window_0 (window=150521284) at xdisp.c:11570
#2  0x0815f068 in internal_condition_case_1 (bfun=0x807d410 
<redisplay_window_0>,
    arg=150521284, handlers=137647413, hfun=0x8071630 <redisplay_window_error>)
    at eval.c:1522
#3  0x080713d3 in redisplay_windows (window=1) at xdisp.c:11549
#4  0x0807138f in redisplay_windows (window=1) at xdisp.c:11543
#5  0x0807ec11 in redisplay_internal (preserve_echo_area=<value optimized out>)
    at xdisp.c:11106
#6  0x081020a0 in read_char (commandflag=1, nmaps=4, maps=0xbfc2a290, 
    prev_event=137660617, used_mouse_menu=0xbfc2a328) at keyboard.c:2633
#7  0x081047a2 in read_key_sequence (keybuf=0xbfc2a3c4, bufsize=30,
    prompt=137660617, dont_downcase_last=0, can_return_switch_frame=1,
    fix_current_buffer=1) at keyboard.c:9020
#8  0x08106511 in command_loop_1 () at keyboard.c:1610
#9  0x0815f2b2 in internal_condition_case (bfun=0x8106370 <command_loop_1>,
    handlers=137726337, hfun=0x80fe290 <cmd_error>) at eval.c:1474
#10 0x080f849e in command_loop_2 () at keyboard.c:1400
#11 0x0815ef7c in internal_catch (tag=1, func=0x80f8470 <command_loop_2>,
    arg=137660617) at eval.c:1212
#12 0x080f81f7 in command_loop () at keyboard.c:1365
#13 0x080f82f4 in recursive_edit_1 () at keyboard.c:987
#14 0x0811ff80 in read_minibuf (map=137652685, initial=137660617,
    prompt=<value optimized out>, backup_n=<value optimized out>, expflag=0,
    histvar=137706049, histpos=1, defalt=137660617, allow_props=0,
    inherit_input_method=0, keep_all=0) at minibuf.c:725
#15 0x08120b9d in Fcompleting_read (prompt=156810547, table=1,
    predicate=137738921, require_match=<value optimized out>,
    initial_input=137660617, hist=137706049, def=137660617,
    inherit_input_method=137660617) at minibuf.c:1778
#16 0x080fda16 in Fexecute_extended_command (prefixarg=137660617)
    at keyboard.c:10022
#17 0x0816110d in Ffuncall (nargs=2, args=0xbfc2a890) at eval.c:2902
#18 0x0815e19d in Fcall_interactively (function=137708945, 
record_flag=137660617,
    keys=137708068) at callint.c:883
#19 0x080fd77d in Fcommand_execute (cmd=137708945, record_flag=137660617, 
keys=1,
    special=137660617) at keyboard.c:9965
#20 0x081066c9 in command_loop_1 () at keyboard.c:1865
#21 0x0815f2b2 in internal_condition_case (bfun=0x8106370 <command_loop_1>,
    handlers=137726337, hfun=0x80fe290 <cmd_error>) at eval.c:1474
#22 0x080f849e in command_loop_2 () at keyboard.c:1400
#23 0x0815ef7c in internal_catch (tag=1, func=0x80f8470 <command_loop_2>,
    arg=137660617) at eval.c:1212
#24 0x080f8249 in command_loop () at keyboard.c:1379
#25 0x080f82f4 in recursive_edit_1 () at keyboard.c:987
#26 0x080f844c in Frecursive_edit () at keyboard.c:1049
#27 0x080f74f5 in main (argc=1, argv=0xbfc2b124) at emacs.c:1793


I will keep this Emacs instance around in case someone needs
it to track the bug down.  Please let me know if this is
unnecessary or futile.

-- 
Daniel Brockman <address@hidden>

   ``For any given feature, I don't care much about the
     people who find it useless --- I care more about
     the people who find it useful.'' --- Larry Wall