From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Kaushal Modi Newsgroups: gmane.emacs.bugs Subject: bug#35429: 27.0.50; Arbitrary xdisp.c related crashes when working with overlay-using packages Date: Fri, 26 Apr 2019 14:22:51 -0400 Message-ID: References: <83r29pygqk.fsf@gnu.org> <83ef5pxmjc.fsf@gnu.org> <83r29owsev.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000003a33f05877308b1" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="228100"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 35429@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Apr 26 20:26:18 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hK5Y9-000x8T-Dg for geb-bug-gnu-emacs@m.gmane.org; Fri, 26 Apr 2019 20:26:17 +0200 Original-Received: from localhost ([127.0.0.1]:50588 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hK5Y8-0000wp-F2 for geb-bug-gnu-emacs@m.gmane.org; Fri, 26 Apr 2019 14:26:16 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:59914) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hK5Vz-0007gM-Cp for bug-gnu-emacs@gnu.org; Fri, 26 Apr 2019 14:24:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hK5Vx-0007aW-UX for bug-gnu-emacs@gnu.org; Fri, 26 Apr 2019 14:24:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48213) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hK5Vx-0007aK-RM for bug-gnu-emacs@gnu.org; Fri, 26 Apr 2019 14:24:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hK5Vx-0005KA-KN for bug-gnu-emacs@gnu.org; Fri, 26 Apr 2019 14:24:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Kaushal Modi Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 26 Apr 2019 18:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35429 X-GNU-PR-Package: emacs Original-Received: via spool by 35429-submit@debbugs.gnu.org id=B35429.155630301820425 (code B ref 35429); Fri, 26 Apr 2019 18:24:01 +0000 Original-Received: (at 35429) by debbugs.gnu.org; 26 Apr 2019 18:23:38 +0000 Original-Received: from localhost ([127.0.0.1]:33524 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hK5VZ-0005JM-OC for submit@debbugs.gnu.org; Fri, 26 Apr 2019 14:23:38 -0400 Original-Received: from mail-lf1-f41.google.com ([209.85.167.41]:45615) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hK5VX-0005J3-BX for 35429@debbugs.gnu.org; Fri, 26 Apr 2019 14:23:36 -0400 Original-Received: by mail-lf1-f41.google.com with SMTP id t11so3018798lfl.12 for <35429@debbugs.gnu.org>; Fri, 26 Apr 2019 11:23:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=llStKRlgB7D6LVzP0TQtdEfFQYbCEwi5RUNf4L8bzzs=; b=Z0kpYqSbIzz3shXSXdNrwBuRQvX9kAVtum1r9PdBOw65LJb5+8Ls8I00zu+0RvBbcg VP9KWQ2AACmR1ipImQWzgAfP2AmjwN1JfYzV72mVLXoO53+C1YtFYIfs5bPd696nKVjx mqjlQ24JXTwF9qfGZEVf+O0Y4wxOkbxEzIFqWio8q0YSY+yYG787TGuqwV03bfTcx0k5 KoS9sNqzX9McSJkTdPRXLXfpg1MkM5MMXe+KAW7hMsJzj8jsH/CHC9aQEFZPjREIPE8n +Ka0NXr9AE8HoqcWFi51uNQ72zvJVfN/rlnPQAzeqjm73xAufmYE/nd/xQpv9huN8sO6 WtgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=llStKRlgB7D6LVzP0TQtdEfFQYbCEwi5RUNf4L8bzzs=; b=d0xcHC8aXNwwk7MNtahGFHdj1BIE7X28Ze3NoeoRkaKZTGNaSTACr5RoIaMke+JvlZ dk5Z2Pxmu010BkPlViwEKJmJB+tnfsfsQq8AVbgp3SLHZr4KqsFxFkh0bSwPRY/81JJX DSVgtTdEMWF9GeS3ZTBklYfpx4fxXcwUNqBU71tNVjjMduU1caPLFlkI2JdBd8Hg8jbk hvk56GvCsEYe51WD5z5dZ6AqcX8rRnPDep3acCJJGDYvnYd3L7THOvxeNjSRsNN1Bs5g ht9DfnD1DSrGcN7MEAH34DW313J+wv5AeDh8HGdF3Y38Xqb3SGzJkLvCAmqBEJ0IrYLA UPeA== X-Gm-Message-State: APjAAAXkVUQ3Z7jBOlK0A2+r8ltz91n9bRoy8E+UHNUWAN4wgAte3V5V MeeRlXgW2ju61qYhYb0iisu+rq09e6RE8ItlwnQ= X-Google-Smtp-Source: APXvYqwe7yix7pSsQ/CLUL58dF3qzMcPgOsvN48b3EGDvoPrlqIOE/S9YirnRMOewd1y1rMKMJn5H61BlFESF1OhD6s= X-Received: by 2002:a19:20c8:: with SMTP id g191mr26600798lfg.122.1556303008996; Fri, 26 Apr 2019 11:23:28 -0700 (PDT) In-Reply-To: <83r29owsev.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:158306 Archived-At: --00000000000003a33f05877308b1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 26, 2019 at 2:09 PM Eli Zaretskii wrote: > > Those characters are in the buffer, not overlay. And they are not in th= e > first 2874 characters. > > Here are the roughly first 3000 chars of that Org buffer: > http://ix.io/1Hgv > > That's strange, because the data you printed in GDB says there's at > least one non-ASCII character within the first 1406 character > positions. > The results of the gdb commands explains this confusion :) > Character code properties: customize what to show > > general-category: Co (Other, Private Use) > > decomposition: (59428) ('=EE=A0=A4') > > Why are you using PU characters? They will only work with specific > fonts, not in general. I advise against that. But I don't think this > is the reason, as no valid Unicode point should ever cause a crash. > > > (gdb) p current_buffer->pt > > $1 =3D 1406 > > (gdb) p current_buffer->pt_byte > > $2 =3D 1418 > > This is inconsistent both with the image of the buffer you posted > above and with the fact that character position 2874 corresponds to a > byte position 2874. > Yes, this mapping is only for PragmataPro font. It's just because I did not know of any other way to map to the ligature codes provided by the font. Are you sure the current buffer is your Org buffer? I was .. until now .. I most likely had the frame split in two windows with one showing that Org file and the other showing ascii-art-to-unicode.el. Here is that file: http://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/packages/ascii-art-to-= unicode/ascii-art-to-unicode.el And that file definitely has a lot of unicode characters in the first 2k lines. (That ties back to the box characters which I was trying to add to the Org file.) > What do the > following commands display? > > (gdb) p current_buffer->name_ > (gdb) xstring > (gdb) fr 2 > (gdb) p w->contents > (gdb) xtype > (gdb) xbuffer > (gdb) p current_buffer->name_ $9 =3D XIL(0xc35be44) (gdb) xstring $10 =3D (struct Lisp_String *) 0xc35be40 "ascii-art-to-unicode.el" (gdb) fr 2 #2 0x0000000000456b44 in init_iterator (it=3Dit@entry=3D0x7fffffff3040, w=3Dw@entry=3D0x89da880, charpos=3D2874, bytepos=3D, row=3D, base_face_id=3Dbase_face_id@entry=3DDEFAULT_FACE_ID) at xdisp.c:3047 3047 eassert (charpos =3D=3D BYTE_TO_CHAR (bytepos)); (gdb) p w->contents $11 =3D XIL(0xc35be95) (gdb) xtype Lisp_Vectorlike PVEC_BUFFER (gdb) xbuffer $12 =3D (struct buffer *) 0xc35be90 (unsigned char *) 0xb6e97a0 "ascii-art-to-unicode.el" (gdb) I hope this helps. This debug is turning out to be interesting with each update :) Thanks. Kaushal --00000000000003a33f05877308b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Apr 26, 2019 at 2:09 PM El= i Zaretskii <eliz@gnu.org> wrote:=
> Those char= acters are in the buffer, not overlay. And they are not in the first 2874 c= haracters.
> Here are the roughly first 3000 chars of that Org buffer: http://ix.io/1Hgv

That's strange, because the data you printed in GDB says there's at=
least one non-ASCII character within the first 1406 character
positions.

> Character code properties: customize what to show
>=C2=A0 =C2=A0general-category: Co (Other, Private Use)
>=C2=A0 =C2=A0decomposition: (59428) ('=EE=A0=A4')

Why are you using PU characters?=C2=A0 They will only work with specific fonts, not in general.=C2=A0 I advise against that.=C2=A0 But I don't t= hink this
is the reason, as no valid Unicode point should ever cause a crash.

> (gdb) p current_buffer->pt
> $1 =3D 1406
> (gdb) p current_buffer->pt_byte
> $2 =3D 1418

This is inconsistent both with the image of the buffer you posted
above and with the fact that character position 2874 corresponds to a
byte position 2874.


Are you sure the current buffer is your Org buffer?

I was .. until now .. I most likely had the frame split in two win= dows with one showing that Org file and the other showing=20 ascii-art-to-unicode.el.

And that file definitely has a lot of unicode characters in the fi= rst 2k lines.

(That ties back to the box character= s which I was trying to add to the Org file.)
=C2=A0
= =C2=A0 What do the
following commands display?

=C2=A0(gdb) p current_buffer->name_
=C2=A0(gdb) xstring
=C2=A0(gdb) fr 2
=C2=A0(gdb) p w->contents
=C2=A0(gdb) xtype
=C2=A0(gdb) xbuffer

(gdb) p current_buf= fer->name_
$9 =3D XIL(0xc35be44)
(gdb) xstring
$10 =3D (struct = Lisp_String *) 0xc35be40
"ascii-art-to-unicode.el"
(gdb) fr= 2
#2=C2=A0 0x0000000000456b44 in init_iterator (it=3Dit@entry=3D0x7ffff= fff3040, w=3Dw@entry=3D0x89da880, charpos=3D2874,
=C2=A0=C2=A0=C2=A0 byt= epos=3D<optimized out>, row=3D<optimized out>, base_face_id=3Db= ase_face_id@entry=3DDEFAULT_FACE_ID)
=C2=A0=C2=A0=C2=A0 at xdisp.c:3047<= br>3047=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 eassert (char= pos =3D=3D BYTE_TO_CHAR (bytepos));
(gdb) p w->contents
$11 =3D XI= L(0xc35be95)
(gdb) xtype
Lisp_Vectorlike
PVEC_BUFFER
(gdb) xbuf= fer
$12 =3D (struct buffer *) 0xc35be90
(unsigned char *) 0xb6e97a0 &= quot;ascii-art-to-unicode.el"
(gdb)

I= hope this helps.

This debug is turning out to be inter= esting with each update :)

Thanks.

Kaushal
--00000000000003a33f05877308b1--