bug#6540: 23.2; 23.2.1 (i386-mingw-nt6.1.7600) crashes too

[Eli Zaretskii]

> Date: Sat, 07 Jan 2012 10:24:10 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: camel322@gmail.com, 6540@debbugs.gnu.org
> 
> > From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> > Date: Sat, 07 Jan 2012 05:36:43 +0100
> > Cc: 6540@debbugs.gnu.org
> > 
> > Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> > 
> > > oCameLo <camel322@gmail.com> writes:
> > >
> > >> Steps to reproduce:
> > >>
> > >>  - emacs -q
> > >>
> > >>  - (setq cache-long-line-scans t)
> > >>    C-x C-e
> > >>
> > >>  - (insert (prin1-to-string (x-list-fonts "*")))
> > >>    C-j
> > >
> > > I'm unable to reproduce this with Emacs 24 under Linux.  Has this bug
> > > gone away in Emacs 24 for you, too?

I guess this couldn't be reproduced on GNU/Linux because all font
names there are pure ASCII.  On Windows, x-list-fonts includes several
non-ASCII characters, in font names such as this:

 "-outline-Counterfeit² B-normal-normal-normal-*-*-*-*-*-p-*-iso10646-1"

There are, indeed, such fonts on MS-Windows.

This bug is triggered only when non-ASCII text is inserted into a
buffer, because it used byte positions where character positions were
expected.

(Actually, I wonder how come we didn't see this until now, the bug
being so glaring; I guess the number of people using
cache-long-line-scans is nil.)

>   Breakpoint 1, w32_abort () at w32fns.c:7193
>   7193      button = MessageBox (NULL,
>   (gdb) bt
>   #0  w32_abort () at w32fns.c:7193
>   #1  0x012f7f19 in set_cache_region (c=0x357d1a0, start=269, end=110364,
>       value=1) at region-cache.c:387
>   #2  0x012f860b in know_region_cache (buf=0x32a6000, c=0x357d1a0, start=269,
>       end=110364) at region-cache.c:694
>   #3  0x010fbc5d in scan_buffer (target=10, start=110361, end=1, count=-1,
>       shortage=0x0, allow_quit=0) at search.c:793

Here, a buffer of 110361 characters was scanned back for a new line,
but know_region_cache is passed 110364 as the buffer end, which is the
value of ZV_BYTE, not of ZV.

Fixed in revision 106820 on the trunk.

I'm closing this bug report (again ;-).