🚀 go-pugleaf

One of the things that emacs is taking great paints to keep right is that
the value of point should always be within the visible (narrowed) part of
the buffer. It appears, however, to be possible to get this condition
violated. I don't have a recipe for this to happen but I have noticed emacs
crashing several times during the use of VM version 5 (beta test version)
under the following circumstances:

I am working in a mail buffer, with summary mode, and the summary buffer is
the only one visible. Sometimes when I select a message (for example to
delete it or to save it) emacs crashes. It is very difficult to reconstruct
a thing like this: it seems to happen at random. The last time this
happened I looked at the core dump and I got the following:

_SetBfp+0xDC:	_abort	()
_Fset_buffer+0x30:	_SetBfp	(0x219608)
_unbind_to+0x84:???	(0x522BB0C)
_Fbyte_code+0x6AE:	_unbind_to	(0x1)
_Feval+0x560:	???	(0x30F81BC, 0x40F7008, 0x9)
_Fcall_interactively+0x1F6:	_Feval	(0x50FA434)
_Fcommand_execute+0x124:_Fcall_interactively	(0x10BFF54, 0x10A300C)
_command_loop_1+0x590:	_Fcommand_execute	(0x10BFF54, 0x10A300C)
_internal_condition_case+0xAC:	???	()
_command_loop_2+0x14:	_internal_condition_case(0x10C86, 0x10A30FC, 0x108C2)
_command_loop+0x54:	_internal_catch	(0x10A30E8, 0x10B7E, 0x10A300C)
_main+0x4AA:	_Frecursive_edit()
__start+0x6E:	_main	(0x3, 0xFFEFFB1C)

I looked into some of the data structures.

The following seems to happen:

emacs is cleaning up at the end of a save-excursion, i.e. it is resetting
the buffer and its point and mark to what they were before the
save-excursion.

In doing this, SetBfp (the routine that switches the buffer) checks the old
buffer for validity and aborts if it is not correct. The particular check
here is if point lies in the narrowed region. It appears that the current
buffer is the mail buffer, the narrowed region is a particular message, and
point is outside that region. 

I suspect (but did not check) that the code emacs is executing is
vm-follow-summary-cursor (I have the corresponding variable set to true).

The strange thing however is that point should never be outside the
narrowed region. All user accessible commands that manipulate either
enforce this condition (by changing point if necessary). So I suspect this
is an emacs bug.

I also noticed that the narrowed region was NOT EXACTLY a complete message,
but only the body. Moreover, point was at a location that I did not set (it
was at the - in a Message-id: header). So this also suggests that something
went wrong.
Also in the SetBfp routine there is some code (commented out) that does a
lot more sanity checks, apparently because someone has been trying to trap
some bug.
--
Piet* van Oostrum, Dept of Computer Science, Utrecht University,
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands.
Telephone: +31 30 531806   Uucp:   uunet!mcsun!ruuinf!piet
Telefax:   +31 30 513791   Internet:  piet@cs.ruu.nl   (*`Pete')