bug#23013: 25.0.92; assertion failure on marker outside text range in echo area

[Ken Raeburn <raeburn@permabit.com>]

[-- Attachment #1: Type: text/plain, Size: 1724 bytes --]

On Wed, Mar 16, 2016 at 11:32 AM, Eli Zaretskii <eliz@gnu.org> wrote:

>
> > And as I said, the first time I wasn't killing a buffer. After
> extracting the recent keys from the earlier core file (we don't have a gdb
> macro for this??)
>
> recent_keys is just a vector, what macro besides xvector do you need?
>

A vector used as a ring buffer (so we don't "start" at 0), containing
integers or symbols denoting keys pressed or lists recording events like
switch-frame or commands invoked. Decoding that all at once would be handy,
since I can't use "C-h l" on a core file.

I've got one in the works, now, but it's got some glitches left to work
out. And I'm more interested in getting xbacktrace working again.


>
> > I've confirmed I was switching to an existing shell command output
> buffer.
>
> So in both cases you were inside or leaving the minibuffer, is that
> right?  And the 'mini' flag of the window is set, so it was a
> mini-window.
>

Yes

Anyway, do you have any explanation for why this started happening
> now?  Did you switch from an older Emacs version, or changed something
> in your local system configuration or in the way you invoke Emacs?
> (I'm trying to establish whether this is an old problem, or something
> that was caused by recent changes.)
>

I switched one week ago to emacs-25.0.92 from emacs-25.0.90, which I'd been
running since early or mid February.  I didn't see this problem in .90,
though a couple of assertion failures in find_last_row_displaying_text
prompted me to pick up the newer snapshot.  Some changes I saw in the log
for .92 made me think maybe that had been addressed, so I wasn't planning
to report the assertion failure unless I saw it again in the newer snapshot.

[-- Attachment #2: Type: text/html, Size: 2536 bytes --]