bug#13007: 24.3.50; emacs_backtrace.txt

bug#13007: 24.3.50; emacs_backtrace.txt

[Drew Adams]

In case it helps, here is an emacs_backtrace.txt.  AFAIK, I wasn't doing
anything particular at the moment (usual use), and I had started Emacs
only about 30 sec before the crash.
 

Backtrace:
0x0115470D
0x0115477F
0x01001459
0x01021A07
0x012072B8
0x012080B9
0x0103B54F
0x0104F14B
0x01038878
0x01010EDE
0x0103800B
0x0101093B
0x01037FC5
0x0103757F
0x010378AC
0x010029AB
0x010010F9
0x7C817073
 
Backtrace:
0x0115470D
0x0115477F
0x01001459
0x01021A07
0x01063E40
0x010030FF
0x01001411
0x01021A07
0x01208B6F
0x01206FA0
0x01203D74
0x0103B556
0x0104F14B
0x01038878
0x01010EDE
0x0103800B
0x0101093B
0x01037FC5
0x0103757F
0x010378AC
0x010029AB
0x010010F9
0x7C817073
 
Backtrace:
0x0115470D
0x0115477F
0x01001459
0x01144D4F
0x01144D2A
0x01144D83
0x010011E6
0x7C8438F6
 
Backtrace:
0x0115470D
0x0115477F
0x01001459
0x01144D4F
0x01144D2A
0x01144D83
0x010011E6
0x7C8438F6
 
Backtrace:
0x0115470D
0x0115477F
0x01001459
0x01021A07
0x01063E40
0x010030FF
0x01001411
0x01021A07
0x01271987
0x012753CF
0x01201334
0x01202410
0x0121160D
0x01208C14
0x01010FC6
0x01208BA1
0x01206FA0
0x01203D74
0x0103B556
0x0104F14B
0x01038878
0x01010EDE
0x0103800B
0x0101093B
0x01037FC5
0x0103757F
0x010378AC
0x010029AB
0x010010F9
0x7C817073
 
Backtrace:
0x0115470D
0x0115477F
0x01001459
0x01021A07
0x010EFEEA
0x010F6A68
0x010F5208
0x010F48F4
0x010F4616
0x0120710E
0x01203D74
0x0103B556
0x0104F14B
0x01038878
0x01010EDE
0x0103800B
0x0101093B
0x01037FC5
0x0103757F
0x010378AC
0x010029AB
0x010010F9
0x7C817073
 
Backtrace:
0x0115470D
0x0115477F
0x01001459
0x01144D4F
0x01144D2A
0x01144D83
0x010011E6
0x7C8438F6
 
Backtrace:
0x0115470D
0x0115477F
0x01001459
0x01021A07
0x012D32D3
0x01014F64
0x010E117F
0x01015E7E
0x01015317
0x010E117F
0x01015E7E
0x01015317
0x010E117F
0x01015E7E
0x01015317
0x010E117F
0x01015E7E
0x01015317
0x010E6C1C
0x01014FD5
0x01014733
0x01052C55
0x010390C7
0x01010EDE
0x0103800B
0x0101093B
0x01037FC5
0x0103757F
0x010378AC
0x010029AB
0x010010F9
0x7C817073
 
Backtrace:
0x0115470D
0x0115477F
0x01001459
0x01021A07
0x012D32D3
0x01014F64
0x010E117F
0x01015E7E
0x01015317
0x010E117F
0x01015E7E
0x01015317
0x010E117F
0x01015E7E
0x01015317
0x010E117F
0x01015E7E
0x01015317
0x010E6C1C
0x01014FD5
0x01014733
0x01052C55
0x010390C7
0x01010EDE
0x0103800B
0x0101093B
0x01037FC5
0x0103757F
0x010378AC
0x010029AB
0x010010F9
0x7C817073
 
Backtrace:
0x0115470D
0x0115477F
0x01250F9C
0x01019E58
0x0105A84F
0x01014EFC
0x010E117F
0x010E0546
0x010132B0
0x01010DFC
0x010E1DBC
0x01015E7E
0x01015317
0x01014685
0x0103A4F4
0x01010EDE
0x0103A912
0x0101457A
0x0103A966
0x0103910E
0x01010EDE
0x0103800B
0x0101093B
0x01037F74
0x0103757F
0x010BE6ED
0x010BF3F7
0x01015217
0x010E117F
0x01015A23
0x01015317
0x010C1764
0x010152CD
0x010E117F
0x01015A23
0x01015317
0x010E117F
0x01015A23
0x01015317
0x010E117F
0x01015E7E
0x01015317
0x010E117F
0x010E0546
0x010132B0
0x01012901
0x010E4D6B
0x01014FD5
0x01014733
0x01052C55
0x010390C7
0x01010EDE
0x0103800B
0x0101093B
0x01037FC5
0x0103757F
0x010378AC
0x010029AB
0x010010F9
0x7C817073
 
Backtrace:
0x01154C71
0x01154CE3
0x01001459
0x010218FB
0x011FE67C
0x01205BCF
0x0120377C
0x0103B552
0x0107A10D
0x0107A3AF
0x01014D1D
0x010E1A0B
0x01015BC6
0x0101505F
0x010E1A0B
0x01015BC6
0x0101505F
0x010E1A0B
0x01015BC6
0x0101505F
0x010E1A0B
0x01015BC6
0x0101505F
0x010E1A0B
0x01015BC6
0x0101505F
0x01014378
0x010E5789
0x01014D1D
0x0101447B
0x01052C6F
0x010390C3
0x01010C9B
0x01038007
0x010106F8
0x01037F70
0x0103757B
0x010BEF81
0x010BFC8B
0x01014F5F
0x010E1A0B
0x01015BC6
0x0101505F
0x010E1A0B
0x01015BC6
0x0101505F
0x010E1A0B
0x010E0DD2
0x01012FF8
0x010106F8
0x010E259F
0x01015BC6
0x0101505F
0x010E1A0B
0x0101576B
0x0101505F
0x010E1A0B
0x010E0DD2
0x01012FF8
0x010106F8
0x010E259F
0x010E0DD2
...
 
 
 
In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
 of 2012-11-26 on MS-W7-DANI
Bzr revision: 111014 monnier@iro.umontreal.ca-20121126195614-fwcm2hg6vt2fcn24
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -Ic:/emacs/libs/libXpm-3.5.10/include -Ic:/emacs/libs/libXpm-3.5.10/src
 -Ic:/emacs/libs/libpng-1.2.37-lib/include -Ic:/emacs/libs/zlib-1.2.5
 -Ic:/emacs/libs/giflib-4.1.4-1-lib/include
 -Ic:/emacs/libs/jpeg-6b-4-lib/include
 -Ic:/emacs/libs/tiff-3.8.2-1-lib/include
 -Ic:/emacs/libs/libxml2-2.7.8-w32-bin/include/libxml2
 -Ic:/emacs/libs/gnutls-3.0.9-w32-bin/include
 -Ic:/emacs/libs/libiconv-1.9.2-1-lib/include'
 

bug#13007: 24.3.50; emacs_backtrace.txt

[Drew Adams]

Started Emacs again, did the same thing, with my setup (tried to complete a file
name for M-x load-file, as usual), and got another backtrace file.

Backtrace:
0x01154C71
0x01154CE3
0x01001459
0x010218FB
0x011FE67C
0x01205BCF
0x0120377C
0x0103B552
0x0107A10D
0x0107A3AF
0x01014D1D
0x010E1A0B
0x01015BC6
0x0101505F
0x010E1A0B
0x01015BC6
0x0101505F
0x010E1A0B
0x01015BC6
0x0101505F
0x010E1A0B
0x01015BC6
0x0101505F
0x010E1A0B
0x01015BC6
0x0101505F
0x01014378
0x010E5789
0x01014D1D
0x0101447B
0x01052C6F
0x010390C3
0x01010C9B
0x01038007
0x010106F8
0x01037F70
0x0103757B
0x010BEF81
0x010BFC8B
0x01014F5F
0x010E1A0B
0x01015BC6
0x0101505F
0x010E1A0B
0x01015BC6
0x0101505F
0x010E1A0B
0x010E0DD2
0x01012FF8
0x010106F8
0x010E259F
0x01015BC6
0x0101505F
0x010E1A0B
0x0101576B
0x0101505F
0x010E1A0B
0x010E0DD2
0x01012FF8
0x010106F8
0x010E259F
0x010E0DD2
...

I will stop using this build and return to the previous Windows build available.
Cannot use this one at all.

bug#13007: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Mon, 26 Nov 2012 22:23:50 -0800
> 
> In case it helps, here is an emacs_backtrace.txt.  AFAIK, I wasn't doing
> anything particular at the moment (usual use), and I had started Emacs
> only about 30 sec before the crash.

Thanks, it does help.  The backtrace produced by addr2line is below.

The crash is due to assertion violation here:

  static int
  window_outdated (struct window *w)
  {
    eassert (XBUFFER (w->buffer) == current_buffer);  <<<<<<<<<<<<<<<<<<
    return (w->last_modified < MODIFF 
	    || w->last_overlay_modified < OVERLAY_MODIFF);
  }

Dmitry, why did you add this assertion?  What code that you introduced
assumes that this condition is always true?

I suspect that we need to change this assertion to

    eassert (MINI_WINDOW_P (w) || w->pseudo_window_p
             || XBUFFER (w->buffer) == current_buffer);

At least in this case (see the backtrace below), window_outdated is
called from code that handles minibuffer windows, so I'm guessing the
above assertion is not true.

Here's the full backtrace:

  w32_backtrace at C:\emacs\trunk\src/w32fns.c:7735
  emacs_abort at C:\emacs\trunk\src/w32fns.c:7767
  terminate_due_to_signal at C:\emacs\trunk\src/emacs.c:341
  die at C:\emacs\trunk\src/alloc.c:6487
  window_outdated at C:\emacs\trunk\src/xdisp.c:10906
  redisplay_internal at C:\emacs\trunk\src/xdisp.c:13213
  redisplay at C:\emacs\trunk\src/xdisp.c:12715
  read_char at C:\emacs\trunk\src/keyboard.c:2416
  read_filtered_event at C:\emacs\trunk\src/lread.c:609
  Fread_event at C:\emacs\trunk\src/lread.c:721
  Ffuncall at C:\emacs\trunk\src/eval.c:2678
  exec_byte_code at C:\emacs\trunk\src/bytecode.c:899
  funcall_lambda at C:\emacs\trunk\src/eval.c:2903
  Ffuncall at C:\emacs\trunk\src/eval.c:2720
  exec_byte_code at C:\emacs\trunk\src/bytecode.c:899
  funcall_lambda at C:\emacs\trunk\src/eval.c:2903
  Ffuncall at C:\emacs\trunk\src/eval.c:2720
  exec_byte_code at C:\emacs\trunk\src/bytecode.c:899
  funcall_lambda at C:\emacs\trunk\src/eval.c:2903
  Ffuncall at C:\emacs\trunk\src/eval.c:2720
  exec_byte_code at C:\emacs\trunk\src/bytecode.c:899
  funcall_lambda at C:\emacs\trunk\src/eval.c:2903
  Ffuncall at C:\emacs\trunk\src/eval.c:2720
  exec_byte_code at C:\emacs\trunk\src/bytecode.c:899
  funcall_lambda at C:\emacs\trunk\src/eval.c:2903
  Ffuncall at C:\emacs\trunk\src/eval.c:2720
  apply1 at C:\emacs\trunk\src/eval.c:2432
  Fcall_interactively at C:\emacs\trunk\src/callint.c:377
  Ffuncall at C:\emacs\trunk\src/eval.c:2678
  call3 at C:\emacs\trunk\src/eval.c:2496
  Fcommand_execute at C:\emacs\trunk\src/keyboard.c:10214
  command_loop_1 at C:\emacs\trunk\src/keyboard.c:1576
  internal_condition_case at C:\emacs\trunk\src/eval.c:1192
  command_loop_2 at C:\emacs\trunk\src/keyboard.c:1163
  internal_catch at C:\emacs\trunk\src/eval.c:963
  command_loop at C:\emacs\trunk\src/keyboard.c:1134
  recursive_edit_1 at C:\emacs\trunk\src/keyboard.c:774
  read_minibuf at C:\emacs\trunk\src/minibuf.c:678
  Fread_from_minibuffer at C:\emacs\trunk\src/minibuf.c:980
  Ffuncall at C:\emacs\trunk\src/eval.c:2697
  exec_byte_code at C:\emacs\trunk\src/bytecode.c:899
  funcall_lambda at C:\emacs\trunk\src/eval.c:2903
  Ffuncall at C:\emacs\trunk\src/eval.c:2720
  exec_byte_code at C:\emacs\trunk\src/bytecode.c:899
  funcall_lambda at C:\emacs\trunk\src/eval.c:2903
  Ffuncall at C:\emacs\trunk\src/eval.c:2720
  exec_byte_code at C:\emacs\trunk\src/bytecode.c:899
  Fbyte_code at C:\emacs\trunk\src/bytecode.c:474
  eval_sub at C:\emacs\trunk\src/eval.c:2042
  internal_catch at C:\emacs\trunk\src/eval.c:963
  exec_byte_code at C:\emacs\trunk\src/bytecode.c:1080
  funcall_lambda at C:\emacs\trunk\src/eval.c:2903
  Ffuncall at C:\emacs\trunk\src/eval.c:2720
  exec_byte_code at C:\emacs\trunk\src/bytecode.c:899
  funcall_lambda at C:\emacs\trunk\src/eval.c:2837
  Ffuncall at C:\emacs\trunk\src/eval.c:2720
  exec_byte_code at C:\emacs\trunk\src/bytecode.c:899
  Fbyte_code at C:\emacs\trunk\src/bytecode.c:474
  eval_sub at C:\emacs\trunk\src/eval.c:2042
  internal_catch at C:\emacs\trunk\src/eval.c:963
  exec_byte_code at C:\emacs\trunk\src/bytecode.c:1080
  Fbyte_code at C:\emacs\trunk\src/bytecode.c:474

bug#13007: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Mon, 26 Nov 2012 22:28:21 -0800
> 
> Started Emacs again, did the same thing, with my setup (tried to
> complete a file name for M-x load-file, as usual), and got another
> backtrace file.

So the abort happens when you are doing minibuffer input, or when some
message is displayed in the echo area, is that right?

Can you describe the configuration of frames and windows at the moment
of the abort?

bug#13007: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> > Started Emacs again, did the same thing, with my setup (tried to
> > complete a file name for M-x load-file, as usual), and got another
> > backtrace file.
> 
> So the abort happens when you are doing minibuffer input, or when some
> message is displayed in the echo area, is that right?

Yes.  I did (in my setup - standalone minibuffer, Icicles, etc.):

 M-x load-file icicles-ma TAB

to complete to icicles-mac.el[c]
 
> Can you describe the configuration of frames and windows at the moment
> of the abort?

3 frames:

1. Dired (could be a file buffer or anything else)
2. Standalone minibuffer frame
3. *Completions* frame, showing the two candidates:
icicles-mac.el  icicles-mac-elc

Immediately after starting Emacs (in Dired), I did the above `M-x'.

TAB causes these things to happen, which I can see happened before the abort
dialog appeared:

a. Displays *Completions*, as mentioned above.
b. Completes minibuffer input to c:/my/path/icicles-mac.el, and highlights the
icicles-mac.el part to show that it is complete.

The Emacs Abort Dialog says the usual (new text).

HTH.  In case there were minor differences from the original backtrace context,
here is another backtrace file, from repeating exactly the recipe given above:

Backtrace:
0x01154C71
0x01154CE3
0x01001459
0x010218FB
0x011FE67C
0x01205BCF
0x0120377C
0x0103B552
0x0107A10D
0x0107A3AF
0x01014D1D
0x010E1A0B
0x01015BC6
0x0101505F
0x010E1A0B
0x01015BC6
0x0101505F
0x010E1A0B
0x01015BC6
0x0101505F
0x010E1A0B
0x01015BC6
0x0101505F
0x010E1A0B
0x01015BC6
0x0101505F
0x01014378
0x010E5789
0x01014D1D
0x0101447B
0x01052C6F
0x010390C3
0x01010C9B
0x01038007
0x010106F8
0x01037F70
0x0103757B
0x010BEF81
0x010BFC8B
0x01014F5F
0x010E1A0B
0x01015BC6
0x0101505F
0x010E1A0B
0x01015BC6
0x0101505F
0x010E1A0B
0x010E0DD2
0x01012FF8
0x010106F8
0x010E259F
0x01015BC6
0x0101505F
0x010E1A0B
0x0101576B
0x0101505F
0x010E1A0B
0x010E0DD2
0x01012FF8
0x010106F8
0x010E259F
0x010E0DD2
...

bug#13007: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> 3. *Completions* frame, showing the two candidates:
>    icicles-mac.el  icicles-mac-elc
                     ^^^^^^^^^^^^^^^

I meant icicles-mac.elc.

bug#13007: 24.3.50; emacs_backtrace.txt

[Juanma Barranquero]

On Tue, Nov 27, 2012 at 4:15 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> So the abort happens when you are doing minibuffer input, or when some
> message is displayed in the echo area, is that right?
>
> Can you describe the configuration of frames and windows at the moment
> of the abort?

I (having missed this bug thread, sorry) just filed bug#13012 with an
easy recipe for the assertion failure.

Feel free to merge both reports.

    Juanma

bug#13007: 24.3.50; emacs_backtrace.txt

[Dmitry Antipov]

On 11/27/2012 07:14 PM, Eli Zaretskii wrote:

> The crash is due to assertion violation here:
>
>    static int
>    window_outdated (struct window *w)
>    {
>      eassert (XBUFFER (w->buffer) == current_buffer);  <<<<<<<<<<<<<<<<<<
>      return (w->last_modified < MODIFF
> 	    || w->last_overlay_modified < OVERLAY_MODIFF);
>    }
>
> Dmitry, why did you add this assertion?  What code that you introduced
> assumes that this condition is always true?

This eassert was installed just to trap on the suspicious use cases as we found
in this bug :-).

> I suspect that we need to change this assertion to
>
>      eassert (MINI_WINDOW_P (w) || w->pseudo_window_p
>               || XBUFFER (w->buffer) == current_buffer);
>
> At least in this case (see the backtrace below), window_outdated is
> called from code that handles minibuffer windows, so I'm guessing the
> above assertion is not true.

Hm... this really helps to bypass eassert, but:

1) is it meaningful to compare w->last_modified of minibuffer window with
MODIFF? Shouldn't we compare it against BUFF_MODIFF of appropriate minibuffer?

2) is it possible to have an overlay in a minibuffer?

3) should window_outdated_p be applicable to pseudowindows at all?

Dmitry

bug#13007: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Tue, 27 Nov 2012 20:49:44 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: Drew Adams <drew.adams@oracle.com>, 13007@debbugs.gnu.org
> 
> 1) is it meaningful to compare w->last_modified of minibuffer window with
> MODIFF?

I don't know.  The old code did exactly that.

> 2) is it possible to have an overlay in a minibuffer?

Yes, definitely.  E.g., icomplete-mode does that, AFAIR.

> 3) should window_outdated_p be applicable to pseudowindows at all?

I don't know.  Do you want more crashes to be sure? ;-)

bug#13007: 24.3.50; emacs_backtrace.txt

[Jambunathan K]

Eli Zaretskii <eliz@gnu.org> writes:

>> 2) is it possible to have an overlay in a minibuffer?
>
> Yes, definitely.  E.g., icomplete-mode does that, AFAIR.

minibuffer.el does it as well.  See `minibuffer-message'.  

Stuff like `[Sole completion]', `[No completions]' etc are really
overlays.
-- 

bug#13007: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Tue, 27 Nov 2012 17:39:38 +0100
> Cc: Drew Adams <drew.adams@oracle.com>, 13007@debbugs.gnu.org
> 
> On Tue, Nov 27, 2012 at 4:15 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > So the abort happens when you are doing minibuffer input, or when some
> > message is displayed in the echo area, is that right?
> >
> > Can you describe the configuration of frames and windows at the moment
> > of the abort?
> 
> I (having missed this bug thread, sorry) just filed bug#13012 with an
> easy recipe for the assertion failure.
> 
> Feel free to merge both reports.

Done.

bug#13007: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> >> 2) is it possible to have an overlay in a minibuffer?
> >
> > Yes, definitely.  E.g., icomplete-mode does that, AFAIR.
> 
> minibuffer.el does it as well.  See `minibuffer-message'.  
> Stuff like `[Sole completion]', `[No completions]' etc are really
> overlays.

Yes, and more importantly, _user_ code can use overlays in the minibuffer (as in
any other buffer, AFAIK).

It is great to point _also_ to existing Emacs source code in this regard, but
this is really inessential (irrelevant).

What's important wrt overlays here is that users can create and use them, not
that some existing Emacs code might do so.

What users can do they will do.  Emacs should do its best not to crash in such a
context.

bug#13007: 24.3.50; emacs_backtrace.txt

[Dmitry Antipov]

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

IIUC crash is triggered by this fragment:

  13212    else if (EQ (selected_window, minibuf_window)
  13213             && (current_buffer->clip_changed || window_outdated (w))
  13214             && resize_mini_window (w, 0))

So selected_window is the same as minibuf_window, and w->buffer is not the
same as current_buffer; but, is w equal to XWINDOW (selected_window) here?

Look above:

  13114    /* Notice any pending interrupt request to change frame size.  */
  13115    do_pending_window_change (1);
  13116
  13117    /* do_pending_window_change could change the selected_window due to
  13118       frame resizing which makes the selected window too small.  */
  13119    if (WINDOWP (selected_window) && (w = XWINDOW (selected_window)) != sw)
  13120      {
  13121        sw = w;
  13122        reconsider_clip_changes (w, current_buffer);
  13123      }
  13124
  13125    /* Clear frames marked as garbaged.  */
  13126    clear_garbaged_frames ();
  13127
  13128    /* Build menubar and tool-bar items.  */
  13129    if (NILP (Vmemory_full))
  13130      prepare_menu_bars ();

Here prepare_menu_bars can run Lisp and so change something.

  13131
  13132    if (windows_or_buffers_changed)
  13133      update_mode_lines++;
  13134
  13135    /* Detect case that we need to write or remove a star in the mode line.  */
  13136    if ((SAVE_MODIFF < MODIFF) != w->last_had_star)

If we ran Lisp above, how we can be sure that w is still equal to XWINDOW (selected_window)?

Can someone try this patch?

Dmitry

[-- Attachment #2: 1.patch --]
[-- Type: text/plain, Size: 1416 bytes --]

=== modified file 'src/xdisp.c'
--- src/xdisp.c	2012-11-27 03:10:32 +0000
+++ src/xdisp.c	2012-11-28 07:13:04 +0000
@@ -10903,6 +10903,9 @@
 static int
 window_outdated (struct window *w)
 {
+  if (w->pseudo_window_p)
+    /* Always update menu bar windows.  */
+    return 1;
   eassert (XBUFFER (w->buffer) == current_buffer);
   return (w->last_modified < MODIFF 
 	  || w->last_overlay_modified < OVERLAY_MODIFF);
@@ -13114,14 +13117,6 @@
   /* Notice any pending interrupt request to change frame size.  */
   do_pending_window_change (1);
 
-  /* do_pending_window_change could change the selected_window due to
-     frame resizing which makes the selected window too small.  */
-  if (WINDOWP (selected_window) && (w = XWINDOW (selected_window)) != sw)
-    {
-      sw = w;
-      reconsider_clip_changes (w, current_buffer);
-    }
-
   /* Clear frames marked as garbaged.  */
   clear_garbaged_frames ();
 
@@ -13129,6 +13124,15 @@
   if (NILP (Vmemory_full))
     prepare_menu_bars ();
 
+  /* Resync because prepare_menu_bars may run Lisp or do_pending_window_change
+     could change the selected_window due to frame resizing which makes the
+     selected window too small.  */
+  if (WINDOWP (selected_window) && (w = XWINDOW (selected_window)) != sw)
+    {
+      sw = w;
+      reconsider_clip_changes (w, current_buffer);
+    }
+
   if (windows_or_buffers_changed)
     update_mode_lines++;
 

bug#13007: 24.3.50; emacs_backtrace.txt

[Juanma Barranquero]

On Wed, Nov 28, 2012 at 8:19 AM, Dmitry Antipov <dmantipov@yandex.ru> wrote:

> Can someone try this patch?

What result did you expect? In my use case, the assertion still fails.

    Juanma

bug#13007: 24.3.50; emacs_backtrace.txt

[Dmitry Antipov]

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

On 11/28/2012 05:09 PM, Juanma Barranquero wrote:

> What result did you expect? In my use case, the assertion still fails.

OK. Your crash recipe from Bug#13012 (which I can reproduce) hits the
corner case where XBUFFER (XWINDOW (selected_window)->buffer) !=
current_buffer; this should be fixed by always examining window buffer
instead of current. This should works for mini windows too, but I'm
not 100% sure about pseudo windows.

Drew, since I can't reproduce your crash, could you please a) try this
patch and b) check whether window with non-zero pseudo_window_p field
is passed to window_outdated_p?

Dmitry


[-- Attachment #2: 2.patch --]
[-- Type: text/plain, Size: 772 bytes --]

=== modified file 'src/xdisp.c'
--- src/xdisp.c	2012-11-27 03:10:32 +0000
+++ src/xdisp.c	2012-11-28 15:39:55 +0000
@@ -10898,14 +10898,17 @@
 }
 
 /* Nonzero if W doesn't reflect the actual state of
-   current buffer due to its text or overlays change.  */
+   its buffer due to its text or overlays change.  */
 
 static int
 window_outdated (struct window *w)
 {
-  eassert (XBUFFER (w->buffer) == current_buffer);
-  return (w->last_modified < MODIFF 
-	  || w->last_overlay_modified < OVERLAY_MODIFF);
+  struct buffer *b = XBUFFER (w->buffer);
+
+  eassert (BUFFER_LIVE_P (b));
+
+  return (w->last_modified < BUF_MODIFF (b)
+	  || w->last_overlay_modified < BUF_OVERLAY_MODIFF (b));
 }
 
 /* Nonzero if W's buffer was changed but not saved or Transient Mark mode

bug#13007: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Wed, 28 Nov 2012 19:51:37 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: Juanma Barranquero <lekktu@gmail.com>, 
>  Drew Adams <drew.adams@oracle.com>,
>  Eli Zaretskii <eliz@gnu.org>
> 
> OK. Your crash recipe from Bug#13012 (which I can reproduce) hits the
> corner case where XBUFFER (XWINDOW (selected_window)->buffer) !=
> current_buffer; this should be fixed by always examining window buffer
> instead of current.

The display engine assumes that the buffer being rendered is
current_buffer in a lot of places.  If you want to use w->buffer
instead, you will have to change many places, including those that
don't receive a pointer to the window being redisplayed.  (And there's
the TTY redisplay which is frame-based, and doesn't necessarily go by
windows in the first place.)

Let me turn the table and ask why should we insist on this assertion?
What do we gain by enforcing it?

I know what we lose: the trunk is severely broken for 2 days, and
counting.  3 people have independently bumped into this in 2 different
situations.  If there's no significant gain in this, I say let's
remove the assertion and move on.

bug#13007: 24.3.50; emacs_backtrace.txt

[Dmitry Antipov]

On 11/28/2012 09:59 PM, Eli Zaretskii wrote:

> Let me turn the table and ask why should we insist on this assertion?
> What do we gain by enforcing it?
>
> I know what we lose: the trunk is severely broken for 2 days, and
> counting.  3 people have independently bumped into this in 2 different
> situations.  If there's no significant gain in this, I say let's
> remove the assertion and move on.

OK for now. But I still thinks that we just ignore some unusual cases
which needs more investigations.

Dmitry

bug#13007: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Thu, 29 Nov 2012 10:19:53 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: 13007@debbugs.gnu.org, lekktu@gmail.com, drew.adams@oracle.com
> 
> On 11/28/2012 09:59 PM, Eli Zaretskii wrote:
> 
> > Let me turn the table and ask why should we insist on this assertion?
> > What do we gain by enforcing it?
> >
> > I know what we lose: the trunk is severely broken for 2 days, and
> > counting.  3 people have independently bumped into this in 2 different
> > situations.  If there's no significant gain in this, I say let's
> > remove the assertion and move on.
> 
> OK for now. But I still thinks that we just ignore some unusual cases
> which needs more investigations.

I'm okay with investigating, as long as others don't suffer too much.

For starters, can you tell what triggered the assertion violation in
Juanma's case?  IOW, how did we wind up in a situation where (AFAIU)
the selected window displays a buffer other than the current one?

And Drew, could you please try coming up with a simple recipe starting
with "emacs -Q"?  If you define a configuration with a minibuffer-less
frame, a separate minibuffer frame, and arrange for *Completions* to
pop up yet another frame, then trigger completion in some simple way,
does Emacs abort like in your original report?

TIA

bug#13007: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> And Drew, could you please try coming up with a simple recipe starting
> with "emacs -Q"?  If you define a configuration with a minibuffer-less
> frame, a separate minibuffer frame, and arrange for *Completions* to
> pop up yet another frame, then trigger completion in some simple way,
> does Emacs abort like in your original report?

No, I'm sorry Eli, I just don't have the time for that now.  I have reverted to
using the Emacs binary before these crashes were introduced.

If you happen to make some progress then I will be glad to try the result and
let you know the effect in my context.

My guess (& hope) is that there is a good chance that Juanma and I were bitten
by the same bug.  If not, we can look into my case more later, when I have some
more time.

bug#13007: 24.3.50; emacs_backtrace.txt

[Dmitry Antipov]

On 11/29/2012 08:46 PM, Eli Zaretskii wrote:

> For starters, can you tell what triggered the assertion violation in
> Juanma's case?  IOW, how did we wind up in a situation where (AFAIU)
> the selected window displays a buffer other than the current one?

IIUC, here is the sequence:

Function set_window_buffer (W, B, ...) is called where W is selected_window
and XBUFFER (B) != current_buffer. This function temporary sets current
buffer to XBUFFER (B) to run hooks, and then restore old current_buffer [1].
So, on exit we have XBUFFER (XWINDOW (selected_window)->buffer) != current_buffer,
and these gets _finally_ synchronized only when read_key_sequence is called with
fix_current_buffer == true [2]. If redisplay is invoked between [1] and [2],
its routines may see the condition which was eassert'ed; _finally_ means
that some redisplay routines may do the synchronization temporary and
then restore original value of current buffer (see pos_visible_p for example).

Dmitry

bug#13007: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <13007@debbugs.gnu.org>, <lekktu@gmail.com>
> Date: Thu, 29 Nov 2012 09:02:13 -0800
> 
> > And Drew, could you please try coming up with a simple recipe starting
> > with "emacs -Q"?  If you define a configuration with a minibuffer-less
> > frame, a separate minibuffer frame, and arrange for *Completions* to
> > pop up yet another frame, then trigger completion in some simple way,
> > does Emacs abort like in your original report?
> 
> No, I'm sorry Eli, I just don't have the time for that now.  I have reverted to
> using the Emacs binary before these crashes were introduced.

Don't you still have the buggy binary on your disk somewhere?

> If you happen to make some progress then I will be glad to try the result and
> let you know the effect in my context.

We cannot make progress, because we cannot reproduce your way to
trigger the bug.

> My guess (& hope) is that there is a good chance that Juanma and I were bitten
> by the same bug.

It's the same bug, in the sense that the same assertion is violated.
But they are 2 different ways of triggering that violation, because
the call to the faulty function comes from 2 different places (as
evidenced by the backtrace) and the buffer that is not the current one
is different in these two cases (*scratch* for Juanma, minibuffer for
you).

> If not, we can look into my case more later, when I have some more
> time.

Please do, and thanks.

bug#13007: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> > No, I'm sorry Eli, I just don't have the time for that now. 
> > I have reverted to using the Emacs binary before these
> > crashes were introduced.
> 
> Don't you still have the buggy binary on your disk somewhere?

Yes, I do.

> > If you happen to make some progress then I will be glad to 
> > try the result and let you know the effect in my context.
> 
> We cannot make progress, because we cannot reproduce your way to
> trigger the bug.

Then we'll just have to wait until you obtain a recipe from someone else for a
different way to trigger "the bug" or perhaps a related bug.

> > My guess (& hope) is that there is a good chance that 
> > Juanma and I were bitten by the same bug.
> 
> It's the same bug, in the sense that the same assertion is violated.
> But they are 2 different ways of triggering that violation, because
> the call to the faulty function comes from 2 different places (as
> evidenced by the backtrace) and the buffer that is not the current one
> is different in these two cases (*scratch* for Juanma, minibuffer for
> you).

Don't you think that by understanding Juanma's case you will understand ways, in
general, that the assertion can be violated?

If we have already seen more than one way, as you say, that seems like a good
hint that the assertion itself might be flawed: the wrong assertion.  It
suggests to me that the assertion does not understand what it should be
expecting, and it has too narrow a view of things.

IOW, I would expect Juanma's case to turn on some light wrt how the assertion is
wrong.  That's because I'm guessing that the code (apparently more than one code
path) that violates the assertion is not the problem, and the assertion itself
is the problem: the wrong assertion.

(Just a hunch, from ignorance.)
 
> > If not, we can look into my case more later, when I have some more
> > time.
> 
> Please do, and thanks.

Thank you for trying to find a solution.

bug#13007: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <dmantipov@yandex.ru>, <13007@debbugs.gnu.org>, <lekktu@gmail.com>
> Date: Thu, 29 Nov 2012 09:47:21 -0800
> 
> > It's the same bug, in the sense that the same assertion is violated.
> > But they are 2 different ways of triggering that violation, because
> > the call to the faulty function comes from 2 different places (as
> > evidenced by the backtrace) and the buffer that is not the current one
> > is different in these two cases (*scratch* for Juanma, minibuffer for
> > you).
> 
> Don't you think that by understanding Juanma's case you will understand ways, in
> general, that the assertion can be violated?

There is no "general" here, just a lot of different use-cases.

> If we have already seen more than one way, as you say, that seems like a good
> hint that the assertion itself might be flawed: the wrong assertion.  It
> suggests to me that the assertion does not understand what it should be
> expecting, and it has too narrow a view of things.

Yes, that part is clear, and therefore the assertion was removed from
the trunk.  But we are trying to figure out with what to replace it,
and for that, we need as many use-cases that violate it as possible.

bug#13007: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> > If we have already seen more than one way, as you say, that 
> > seems like a good hint that the assertion itself might be
> > flawed: the wrong assertion.  It suggests to me that the
> > assertion does not understand what it should be
> > expecting, and it has too narrow a view of things.
> 
> Yes, that part is clear, and therefore the assertion was removed from
> the trunk.  But we are trying to figure out with what to replace it,
> and for that, we need as many use-cases that violate it as possible.

In that case, you are in effect stating that the addition of such a (proper)
assertion is just a nice-to-have, not something needed.

I would suggest, in that case, that we/you move on to other things...

bug#13007: 24.3.50; emacs_backtrace.txt

[Stefan Monnier]

FWIW, it's normal for current-buffer to be different from (window-buffer
(selected-window)).  That happens all the time in Elisp (e.g. whenever
you use `set-buffer').

So if a piece of code needs the two to be "in sync" that code needs to
sync-them-up by hand.  Otherwise, it's better not to assume that the two
are related.

This is quite different from the issue of (selected-window) -vs-
(frame-selected-window) where this is (almost) always equal and that
equality can't be broken by Elisp code.


        Stefan

bug#13007: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <dmantipov@yandex.ru>, <13007@debbugs.gnu.org>, <lekktu@gmail.com>
> Date: Thu, 29 Nov 2012 10:13:33 -0800
> 
> > > If we have already seen more than one way, as you say, that 
> > > seems like a good hint that the assertion itself might be
> > > flawed: the wrong assertion.  It suggests to me that the
> > > assertion does not understand what it should be
> > > expecting, and it has too narrow a view of things.
> > 
> > Yes, that part is clear, and therefore the assertion was removed from
> > the trunk.  But we are trying to figure out with what to replace it,
> > and for that, we need as many use-cases that violate it as possible.
> 
> In that case, you are in effect stating that the addition of such a (proper)
> assertion is just a nice-to-have, not something needed.

Assertions are always "nice to have".  They are a means of catching
bugs that violate assumptions of the code before that code causes harm
or crashes in a place where the original reason is lost.  If you think
this is not needed, then we will have to disagree.  There are hundreds
of assertions in the Emacs code (grep for "eassert").

> I would suggest, in that case, that we/you move on to other things...

I'm sorry to hear that you won't help.

bug#13007: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Dmitry Antipov <dmantipov@yandex.ru>,  13007@debbugs.gnu.org,  lekktu@gmail.com
> Date: Thu, 29 Nov 2012 14:14:13 -0500
> 
> FWIW, it's normal for current-buffer to be different from (window-buffer
> (selected-window)).  That happens all the time in Elisp (e.g. whenever
> you use `set-buffer').

We are talking about redisplay, not Lisp.

bug#13007: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Thu, 29 Nov 2012 21:23:37 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: 13007@debbugs.gnu.org, lekktu@gmail.com, drew.adams@oracle.com
> 
> On 11/29/2012 08:46 PM, Eli Zaretskii wrote:
> 
> > For starters, can you tell what triggered the assertion violation in
> > Juanma's case?  IOW, how did we wind up in a situation where (AFAIU)
> > the selected window displays a buffer other than the current one?
> 
> IIUC, here is the sequence:
> 
> Function set_window_buffer (W, B, ...) is called where W is selected_window
> and XBUFFER (B) != current_buffer. This function temporary sets current
> buffer to XBUFFER (B) to run hooks, and then restore old current_buffer [1].
> So, on exit we have XBUFFER (XWINDOW (selected_window)->buffer) != current_buffer,
> and these gets _finally_ synchronized only when read_key_sequence is called with
> fix_current_buffer == true [2]. If redisplay is invoked between [1] and [2],
> its routines may see the condition which was eassert'ed; _finally_ means
> that some redisplay routines may do the synchronization temporary and
> then restore original value of current buffer (see pos_visible_p for example).

OK.  So what do you suggest, in practical terms?  Are you saying that
we should use BUF_MODIFF(XBUFFER (w->buffer)) instead of MODIFF and
BUF_OVERLAY_MODIFF(XBUFFER (w->buffer)) instead of OVERLAY_MODIFF
inside window_outdated?  Or do you suggest something else?

I'm okay with using BUF_* macros in window_outdated.

My reading of redisplay_internal is that it goes by the selected
window, not assuming that the buffer of that window is the current
buffer.  But when redisplay_window is called, it temporarily selects
the window's buffer as current buffer, and all the functions called by
redisplay_window then rely on that.

So if window_outdated is called not from redisplay_window or its
subroutines, we cannot assume that current_buffer and the selected
window's buffer are the same.  Also, for minibuffer windows and
pseudo-windows, we may need more care, but I'm not sure.

bug#13007: 24.3.50; emacs_backtrace.txt

[Dmitry Antipov]

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

On 11/30/2012 01:53 PM, Eli Zaretskii wrote:

> OK.  So what do you suggest, in practical terms?  Are you saying that
> we should use BUF_MODIFF(XBUFFER (w->buffer)) instead of MODIFF and
> BUF_OVERLAY_MODIFF(XBUFFER (w->buffer)) instead of OVERLAY_MODIFF
> inside window_outdated?  Or do you suggest something else?
>
> I'm okay with using BUF_* macros in window_outdated.

There is one more similar thing: if we can enter redisplay_internal
with different current_buffer and selected window's buffer, we can
confuse reconsider_clip_changes, which comment explicitly assumes
that W->buffer and B are the same buffer.

What if we just delay the real redisplay action until current_buffer
and selected window's buffer becomes synchronized, assuming that it
happens in the very near future (when someone finally update current_buffer
with selected window's buffer and then attract redisplay attention with
++windows_or_buffers_changed or similar)?

> So if window_outdated is called not from redisplay_window or its
> subroutines, we cannot assume that current_buffer and the selected
> window's buffer are the same.  Also, for minibuffer windows and
> pseudo-windows, we may need more care, but I'm not sure.

IIUC pseudo-windows are always non-leaf; so, selected_window can't be
a pseudo-window, and pseudo-window can't be passed to redisplay_window.

Attached patch illustrates all from the above.

Dmitry

[-- Attachment #2: 3.patch --]
[-- Type: text/plain, Size: 2152 bytes --]

=== modified file 'src/xdisp.c'
--- src/xdisp.c	2012-11-30 09:23:15 +0000
+++ src/xdisp.c	2012-11-30 15:45:36 +0000
@@ -10906,6 +10906,7 @@
 static int
 window_outdated (struct window *w)
 {
+  eassert (XBUFFER (w->buffer) == current_buffer);
   return (w->last_modified < MODIFF 
 	  || w->last_overlay_modified < OVERLAY_MODIFF);
 }
@@ -12917,6 +12918,8 @@
 static void
 reconsider_clip_changes (struct window *w, struct buffer *b)
 {
+  eassert (XBUFFER (w->buffer) == b);
+
   if (b->clip_changed
 	   && !NILP (w->window_end_valid)
 	   && w->current_matrix->buffer == b
@@ -12924,13 +12927,11 @@
 	   && w->current_matrix->begv == BUF_BEGV (b))
     b->clip_changed = 0;
 
-  /* If display wasn't paused, and W is not a tool bar window, see if
-     point has been moved into or out of a composition.  In that case,
-     we set b->clip_changed to 1 to force updating the screen.  If
-     b->clip_changed has already been set to 1, we can skip this
-     check.  */
-  if (!b->clip_changed
-      && BUFFERP (w->buffer) && !NILP (w->window_end_valid))
+  /* If display wasn't paused, see if point has been moved into or
+     out of a composition.  In that case, we set b->clip_changed
+     to 1 to force updating the screen.  If b->clip_changed has
+     already been set to 1, we can skip this check.  */
+  if (!b->clip_changed && !NILP (w->window_end_valid))
     {
       ptrdiff_t pt;
 
@@ -13079,6 +13080,10 @@
      may need to run Elisp code (via prepare_menu_bars).  */
   ensure_selected_frame (old_frame);
 
+  if (XBUFFER (w->buffer) != current_buffer)
+    /* Out of sync, do nothing.  */
+    goto end_of_redisplay;
+
   pending = 0;
   reconsider_clip_changes (w, current_buffer);
   last_escape_glyph_frame = NULL;
@@ -13136,10 +13141,7 @@
   /* do_pending_window_change could change the selected_window due to
      frame resizing which makes the selected window too small.  */
   if (WINDOWP (selected_window) && (w = XWINDOW (selected_window)) != sw)
-    {
-      sw = w;
-      reconsider_clip_changes (w, current_buffer);
-    }
+    goto retry;
 
   /* Clear frames marked as garbaged.  */
   clear_garbaged_frames ();

bug#13007: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Fri, 30 Nov 2012 19:50:57 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: 13007@debbugs.gnu.org, lekktu@gmail.com, drew.adams@oracle.com
> 
> There is one more similar thing: if we can enter redisplay_internal
> with different current_buffer and selected window's buffer, we can
> confuse reconsider_clip_changes, which comment explicitly assumes
> that W->buffer and B are the same buffer.

I don't see that.  That function checks if the buffer is the same as
the one recorded in window's matrix.

> What if we just delay the real redisplay action until current_buffer
> and selected window's buffer becomes synchronized, assuming that it
> happens in the very near future (when someone finally update current_buffer
> with selected window's buffer and then attract redisplay attention with
> ++windows_or_buffers_changed or similar)?

I don't think you can do that, since sometimes a non-selected window
needs to be redisplayed.

> IIUC pseudo-windows are always non-leaf; so, selected_window can't be
> a pseudo-window, and pseudo-window can't be passed to redisplay_window.

Are the menu-bar and tool-bar "windows" non-leaf?

>  static void
>  reconsider_clip_changes (struct window *w, struct buffer *b)
>  {
> +  eassert (XBUFFER (w->buffer) == b);
> +

How is this different from this:

>    if (b->clip_changed
>  	   && !NILP (w->window_end_valid)
>  	   && w->current_matrix->buffer == b
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> +  if (XBUFFER (w->buffer) != current_buffer)
> +    /* Out of sync, do nothing.  */
> +    goto end_of_redisplay;

I'm nervous about this, to tell the truth.  redisplay_internal never
dependent on current_buffer.

bug#13007: 24.3.50; emacs_backtrace.txt

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Function set_window_buffer (W, B, ...) is called where W is selected_window
>> and XBUFFER (B) != current_buffer. This function temporary sets current
>> buffer to XBUFFER (B) to run hooks, and then restore old current_buffer [1].
>> So, on exit we have XBUFFER (XWINDOW (selected_window)->buffer) != current_buffer,
>> and these gets _finally_ synchronized only when read_key_sequence is called with
>> fix_current_buffer == true [2]. If redisplay is invoked between [1] and [2],
>> its routines may see the condition which was eassert'ed; _finally_ means
>> that some redisplay routines may do the synchronization temporary and
>> then restore original value of current buffer (see pos_visible_p for example).
>
> OK.  So what do you suggest, in practical terms?  Are you saying that
> we should use BUF_MODIFF(XBUFFER (w->buffer)) instead of MODIFF and
> BUF_OVERLAY_MODIFF(XBUFFER (w->buffer)) instead of OVERLAY_MODIFF
> inside window_outdated?  Or do you suggest something else?
>
> I'm okay with using BUF_* macros in window_outdated.

It's unclear what the conclusion here was.  Is there anything more to be
done in this bug report?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#13007: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Dmitry Antipov <dmantipov@yandex.ru>,  13007@debbugs.gnu.org,  lekktu@gmail.com,  drew.adams@oracle.com
> Date: Tue, 29 Dec 2015 12:08:49 +0100
> 
> It's unclear what the conclusion here was.  Is there anything more to be
> done in this bug report?

Let me take another look at this.  Soon, I hope.

bug#13007: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Tue, 29 Dec 2015 19:37:32 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 13007@debbugs.gnu.org, lekktu@gmail.com, dmantipov@yandex.ru
> 
> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Cc: Dmitry Antipov <dmantipov@yandex.ru>,  13007@debbugs.gnu.org,  lekktu@gmail.com,  drew.adams@oracle.com
> > Date: Tue, 29 Dec 2015 12:08:49 +0100
> > 
> > It's unclear what the conclusion here was.  Is there anything more to be
> > done in this bug report?
> 
> Let me take another look at this.  Soon, I hope.

I see that Dmitry did modify window_outdated back in Aug 2013 (commit
170da1e) to use the BUF_MODIFF and BUF_OVERLAY_MODIFF macros that
accept a buffer as their arguments, and removed the offending
assertion.

So this bug was actually resolved back then, and I'm now marking it as
done.

Thanks.