Re: [lekktu@gmail.com: Re: Crash when having malformed PBM image on screen and viewing *Messages* buffer (on Windows)]

[Richard Stallman <rms@gnu.org>]

Thanks for repeating the added info.  Would someone please debug this
on GNU/Linux, then DTRT and ack?

X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed 
	version=3.1.0
Date: Wed, 25 Jul 2007 11:57:56 +0100
From: Jason Rumney <jasonr@gnu.org>
MIME-Version: 1.0
To: rms@gnu.org
Cc: emacs-devel@gnu.org
Subject: Re: [lekktu@gmail.com: Re: Crash when having malformed PBM image
 on screen and viewing *Messages* buffer (on Windows)]
In-Reply-To: <E1ID2Iv-00087H-OW@fencepost.gnu.org>
Content-Type: text/plain; charset=ISO-8859-15

Richard Stallman wrote:
> [I sent this message month ago but did not get a response.]
>
> Would someone please investigate this, then ack?
>   

As I said in the original thread about this bug, the problem can be
reproduced on GNU/Linux.  The recipe to reproduce it is:

	- start emacs -Q
	- run this in *scratch* buffer

	(progn
	  (put-image '(image :type pbm :data "") 0)
	  (pop-to-buffer "*Messages*")
	  (goto-char (point-max)))

	Now press <down> <right> <down> <right>.


The problem seems to be some mixup between the *scratch* buffer and the
*Messages* buffer during redisplay.  The crash occurs during redisplay
of the window containing the *scratch* buffer, near the end of
redisplay_window.

  /* Restore current_buffer and value of point in it.  */
  TEMP_SET_PT_BOTH (CHARPOS (opoint), BYTEPOS (opoint));
  set_buffer_internal_1 (old);
  TEMP_SET_PT_BOTH (CHARPOS (lpoint), BYTEPOS (lpoint));

opoint is 193, which is the value of zv in the *scratch* buffer. But
lpoint is 386, which I think may be the length of the *Messages* buffer
at some point in the redisplay cycle (multiple messages are output
during redisplay).  Setting breakpoints in message_dolog seems to
prevent the bug from appearing, so it is difficult to tell for sure. 
The only code that changes lpoint is on line 13062 of xdisp.c, and
should only be run if the window being redisplayed is the selected
window, and the current_buffer has not changed.  But AFAICT, the
selected_window should be the *Messages* buffer's window at this point,
while we are redisplaying the *scratch* buffer, so the bug is probably
to do with something changing selected_window somewhere before this point.


The sequence of events I have figured out so far is:

1. Pressing right arrow when at the end of the *Messages* buffer causes
a message "call interactively: End of buffer" to be displayed.

2. This triggers redisplay, during which Emacs attempts to display the
broken image again.

3. Attempting to display the broken image results in a message: "Not a
PBM image: `(image :type pbm :data )'".

4. When Emacs does not crash, the above message is (sometimes?) printed
twice, the first such message appears on the same line as the "End of
buffer" message.

5. Point in the *Messages* buffer ends up after the "End of buffer"
message, but before the "Not a PBM image" messages. There is code in
message_dolog to keep point at the end of the buffer if it was there
before. The fact that this goes wrong may be related to the bug we are
investigating.