New shell is narrowed

[Jerry James]

I just checked in some fixes for comint/shell.  I'm having some trouble
tracking down one bug, though, and could use some suggestions or help.

Platform: XEmacs 21.5 and packages both from current CVS, on either an
i386 or x86_64 architecture.

Symptom: M-x shell gives a blank buffer (i.e., no visible shell prompt).
Furthermore, trying to do anything in that buffer (e.g., press ENTER)
leads to error messages about bad buffer positions.

If you look at the modeline, you see that it says "Narrowed".  C-x n w
or M-x widen makes the shell prompt appear, at which point the shell
appears to behave normally.  Okay, so why is the brand new *shell*
buffer narrowed?  This doesn't happen on 21.4, and the Lisp code is the
same, so what's the difference?

Debug attempt #1
----------------
"I'll just put a breakpoint on Fnarrow_to_region," I think.  Hmmmm, that
gets called a LOT.  Okay, so I'll get an XEmacs running, type "(shell)"
in *scratch*, then attach with GDB, then press C-j.  Fnarrow_to_region
gets called twice ... on *scratch*.  It does NOT get called on the new
buffer.

Debug attempt #2
----------------
Okay, so maybe the buffer object is somehow getting created with funny
values in it.  Fine, I'll get ready to evaluate "(shell)" like before,
attach, put a breakpoint on get_buffer, get the pointer to the new
buffer object and see if it is already hosed.  If not, then I will set a
watchpoint on the begv and bufbegv fields of the buffer object and see
what I get.  Ready?

GDB isn't.  I can't go more than a couple of steps doing ANYTHING before
GDB reports a segfault in code invoked by GDB, causing it to shut down
the process.  I'm sure these are the SIGSEGVs used by VDB, but they're
killing my ability to debug.  This is *after* doing "handle SIGSEGV
noprint nostop" to make GDB shut up about them, already.  How am I
supposed to debug a VDB-using XEmacs?  Anybody?  Anybody?  Ferris?

So I have a *shell* buffer that is mysteriously and incorrectly starting
life narrowed, and I don't know how to figure out why.  Any thoughts or
help muchly appreciated.
-- 
Jerry James, Assistant Professor        james at xemacs.org
Computer Science Department             http://www.cs.usu.edu/~jerry/
Utah State University