On Thu, Mar 17, 2016 at 1:06 PM, Eli Zaretskii 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.