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: 1677 bytes --]

On Thu, Mar 17, 2016 at 1:06 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> I've reviewed the changes between 25.0.90 and 25.0.92.  I see nothing
> that could be directly linked to this problem.  The only commits that
> might be even remotely related are these 3:
>
>   d82f24ba8530eb8de04a319cc80742a0a953040e
>

This could be interesting...


>   84829495b5746417f5eaf9be693fb35f0509697a
>

scroll-conservatively is 0, at least in the core file, and it looks like
the only mode I use that changes it is jabber-chat-mode which sets it to 5,
so either way it shouldn't reach the path where this change occurred.


>   06a872b71d6580e0699600844bb9526602437990
>

Probably not relevant as I was only using X frames. There's the initial
frame created in daemon mode, which has FRAME_VISIBLE_P true but
FRAME_GARBAGED_P false (also FRAME_TERMCAP_P and FRAME_MSDOS_P false) so it
wouldn't follow that path.


>
> Maybe you should try reverting these one by one.
>

I have no reliable way of reproducing the problem, so not hitting another
crash once a change is reverted wouldn't tell me much. Is there something
further I could introduce a check for to see if one of these patches might
be causing the problem?


>
> It could also happen that the assertions you saw in 25.0.90 are caused
> by the same problem that now causes this bug.  Any idea if those
> assertions were for the mini-window as well?
>

Both assertions in .90 were in find_last_row_displaying_text, checking
row->enabled_p. The window being examined (next frame up, try_window_id) is
the root window of its frame. Redisplay is being done during a call to
wait_reading_process_output. So it doesn't look very similar.

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