Re: New shell is narrowed

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; wrote: 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＠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(a)xemacs.org Computer Science Department http://www.cs.usu.edu/~jerry/ Utah State University