[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#6540: 23.2; 23.2.1 (i386-mingw-nt6.1.7600) crashes too
From: |
Eli Zaretskii |
Subject: |
bug#6540: 23.2; 23.2.1 (i386-mingw-nt6.1.7600) crashes too |
Date: |
Sat, 07 Jan 2012 14:09:24 +0200 |
> 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 ;-).