New shell is narrowed

[Jerry James]

"Stephen J. Turnbull" <stephen at xemacs.org> wrote:
> "Don't" is my second; revert to --without-mc-alloc or even
> --without-kkcc and see if the bug still occurs.  This is probably a
> better idea.  (I wouldn't be surprised if gdb continues to segfault
> uncontrollably, though. :-( )

This works ... although your prediction panned out.  I still have to be
very careful about what I do or the debug session comes to an abrupt end
with GDB complaining about segfaults in code it invokes.  Still,
debugging is at least possible.

So I set a watchpoint on the begv field of the new shell buffer.  It
fired on editfns.c:2086, in save_restriction_restore.  The argument to
that function is:

(#<buffer "*shell*"> #<marker at 24 in *shell* 0x9fe6004> . #<marker at
24 in *shell* insertion-type=t 0x9fe601c>)

The C backtrace is:

#0  0x080f4fde in save_restriction_restore (data={...})
    at /home/james/Projects/xemacs/xemacs-21.5/src/editfns.c:2086
#1  0x08106ef4 in unbind_to_hairy (count=4)
    at /home/james/Projects/xemacs/xemacs-21.5/src/eval.c:6113
#2  0x080ad8f5 in execute_optimized_program (
    program=0xa6a56e8 "\b!\036#\r\205\b\001\016#\205\003\001\016#!\205",
    stack_depth=6, constants_data=0xa574748)
    at /home/james/Projects/xemacs/xemacs-21.5/src/bytecode.c:873
#3  0x0810befc in funcall_compiled_function (fun={...}, nargs=2, 
    args=0xbf8a97e0)
    at /home/james/Projects/xemacs/xemacs-21.5/src/eval.c:3495
#4  0x0810eb27 in Ffuncall (nargs=3, args=0xbf8a97dc)
    at /home/james/Projects/xemacs/xemacs-21.5/src/eval.c:3932
#5  0x0810f9ca in call2 (fn={...}, arg0={...}, arg1={...})
    at /home/james/Projects/xemacs/xemacs-21.5/src/eval.c:4561
#6  0x0823bf8a in read_process_output (process={...}, read_stderr=0)
    at /home/james/Projects/xemacs/xemacs-21.5/src/process.c:1091
#7  0x0811fe84 in execute_internal_event (event=Variable "event" is not
available.
)
    at /home/james/Projects/xemacs/xemacs-21.5/src/event-stream.c:3016
#8  0x0812848c in Fdispatch_event (event={...})
    at /home/james/Projects/xemacs/xemacs-21.5/src/event-stream.c:4644
#9  0x080c368c in Fcommand_loop_1 ()
    at /home/james/Projects/xemacs/xemacs-21.5/src/cmdloop.c:600
#10 0x080c37d8 in command_loop_1 (unused_dummy=Could not find the frame
base for "command_loop_1".
)
    at /home/james/Projects/xemacs/xemacs-21.5/src/cmdloop.c:505
#11 0x08109ccc in condition_case_1 (handlers={...}, 
    bfun=0x80c3792 <command_loop_1>, barg={...}, hfun=0x80c3a1d
<cmd_error>, 
    harg={...}) at
/home/james/Projects/xemacs/xemacs-21.5/src/eval.c:1924
#12 0x080c39ba in command_loop_2 (unused_dummy={...})
    at /home/james/Projects/xemacs/xemacs-21.5/src/cmdloop.c:262
#13 0x08107a10 in internal_catch (tag={...}, func=0x80c3978
<command_loop_2>, 
    arg={...}, threw=0x0, thrown_tag=0x0, backtrace_before_throw=0x0)
    at /home/james/Projects/xemacs/xemacs-21.5/src/eval.c:1530
#14 0x080c3d68 in initial_command_loop (load_me={...})
    at /home/james/Projects/xemacs/xemacs-21.5/src/cmdloop.c:313
#15 0x08102d0c in xemacs_21_5_b27_i686_pc_linux (argc=1,
argv=0xbf8aa224, 
    unused_envp=0x0, restart=0)
    at /home/james/Projects/xemacs/xemacs-21.5/src/emacs.c:2667
#16 0x081039e1 in main (argc=Cannot access memory at address 0x7d1
)
    at /home/james/Projects/xemacs/xemacs-21.5/src/emacs.c:3111

The Lisp backtrace is:

  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # bind (inhibit-read-only saved-point)
  # (unwind-protect ...)
  # bind (oprocbuf string process)
  comint-output-filter(#<process "shell" pid 22010 state:run>
"[james at localhost bin]$ ")
  ("execute_internal_event()" "[internal]")
  (dispatch-event "[internal]")
  # (condition-case ... . error)
  # (catch top-level ...)

I interpret this to mean that comint-output-filter has just finished its
run, and we are leaving the save-restriction on line 1774 of comint.el.
Somehow, XEmacs 21.5 gets the idea that it is "restoring" a narrowing
that was never there in the first place.  I wonder if this has something
to do with the insert-before-markers code and related fixups.
-- 
Jerry James, Assistant Professor        james at xemacs.org
Computer Science Department             http://www.cs.usu.edu/~jerry/
Utah State University