From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: bug#21394: 25.0.50; Segfault when displaying unprintable character in echo area while frames are being created Date: Tue, 1 Sep 2015 20:19:58 +0000 Message-ID: References: <83y4gqaxhs.fsf@gnu.org> <83twreau6e.fsf@gnu.org> <83io7uaq37.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=047d7b10c8892c63fb051eb546f5 X-Trace: ger.gmane.org 1441138882 4711 80.91.229.3 (1 Sep 2015 20:21:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 1 Sep 2015 20:21:22 +0000 (UTC) Cc: 21394@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 01 22:21:13 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZWs3M-0008LQ-FS for geb-bug-gnu-emacs@m.gmane.org; Tue, 01 Sep 2015 22:21:12 +0200 Original-Received: from localhost ([::1]:58287 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWs3L-0006nJ-W1 for geb-bug-gnu-emacs@m.gmane.org; Tue, 01 Sep 2015 16:21:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57968) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWs3G-0006j2-Jo for bug-gnu-emacs@gnu.org; Tue, 01 Sep 2015 16:21:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZWs3C-00055m-DR for bug-gnu-emacs@gnu.org; Tue, 01 Sep 2015 16:21:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53229) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWs3C-00055e-AW for bug-gnu-emacs@gnu.org; Tue, 01 Sep 2015 16:21:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZWs3B-0006Jg-UH for bug-gnu-emacs@gnu.org; Tue, 01 Sep 2015 16:21:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Sep 2015 20:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21394 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21394-submit@debbugs.gnu.org id=B21394.144113880324204 (code B ref 21394); Tue, 01 Sep 2015 20:21:01 +0000 Original-Received: (at 21394) by debbugs.gnu.org; 1 Sep 2015 20:20:03 +0000 Original-Received: from localhost ([127.0.0.1]:45439 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWs2D-0006IA-Ss for submit@debbugs.gnu.org; Tue, 01 Sep 2015 16:20:03 -0400 Original-Received: from mail-ig0-f174.google.com ([209.85.213.174]:35557) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZWs2B-0006Hs-JW for 21394@debbugs.gnu.org; Tue, 01 Sep 2015 16:20:00 -0400 Original-Received: by igbkq10 with SMTP id kq10so10080390igb.0 for <21394@debbugs.gnu.org>; Tue, 01 Sep 2015 13:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6roMIKcz3Xr257MqxnEizd5b9Ag2u3DRSSyLKFS4BAs=; b=OHgP1p4/L8LeroPhWfKrkyEC0wh+aW838j3YiaIbUlt8wHxtL8DRrgNLQKiI7sVEVs uUqwSdBWedDNZaO16kR0sJC0DNFLGk05f2K8Ea8Hxi7Wno+ceD24ZKNAsMLFStIbkYuE 5Q8nV7AeYx1/tml0tWZhWfidhbARAZKE9M1V+ts4sATqZbJ9BJTrg69dMytc7/nMTJ48 HOcqIBiBYAT9Yz4msz8eDah/N+/umke8iQM0t+12HKjYynFGvfxIzCq0dSvOnpEW5S+7 7QYJyUpA/mfppHxC1hWrKEeGEaywIC4OCI5OrumpATY1G4rc4+YQiO4f18EMXuhFCdhT BbHA== X-Received: by 10.50.97.33 with SMTP id dx1mr36803igb.1.1441138798766; Tue, 01 Sep 2015 13:19:58 -0700 (PDT) Original-Received: by 10.79.78.66 with HTTP; Tue, 1 Sep 2015 13:19:58 -0700 (PDT) In-Reply-To: <83io7uaq37.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:106072 Archived-At: --047d7b10c8892c63fb051eb546f5 Content-Type: multipart/alternative; boundary=047d7b10c8892c63f7051eb546f3 --047d7b10c8892c63f7051eb546f3 Content-Type: text/plain; charset=UTF-8 This code in xdisp.c looks very suspicious to me: ------ static int last_escape_glyph_face_id = (1 << FACE_ID_BITS); static int last_escape_glyph_merged_face_id = 0; static int merge_escape_glyph_face (struct it *it) { int face_id; if (it->f == last_escape_glyph_frame && it->face_id == last_escape_glyph_face_id) face_id = last_escape_glyph_merged_face_id; else { /* Merge the `escape-glyph' face into the current face. */ face_id = merge_faces (it->f, Qescape_glyph, 0, it->face_id); last_escape_glyph_frame = it->f; last_escape_glyph_face_id = it->face_id; last_escape_glyph_merged_face_id = face_id; } return face_id; } ------ That caches a face id in last_escape_glyph_merged_face_id, which is cleared only in redisplay_internal(). But message() doesn't call redisplay_internal(), it calls try_window() directly (xdisp.c:10687) (and resize_window before that, which blows up). This patch appears, so far, to run without a segfault (I neglected to record timings so can't give you a p-value, but back of the envelope it's >99% that it fixes the segfault), and it fixes what I think is a possible explanation for the segfault, so my current plan is to leave it running overnight and ask for inclusion (of this or an equivalent, cleaner patch, of course) if it doesn't blow up. However, I have yet to look at the other bugs and doubt this is the whole story. On Tue, Sep 1, 2015 at 7:37 PM, Eli Zaretskii wrote: > > Date: Tue, 1 Sep 2015 18:52:44 +0000 > > From: Pip Cet > > Cc: 21394@debbugs.gnu.org > > > > I see the problematic face always has face ID of 18, and the 'used' > > field is always 15 when the segfault strikes. So I guess the next > > step is to make the breakpoint in cache_face conditional on i being > > 18, > > > > i is used in two different ways in that function, as a face hash and as > an > > index into faces_by_id. I assume you mean the latter? > > Yes. > > > and then see whether c->used is set to 19 during that call to > > cache_face. If it does, then a watchpoint (by location) on c->used > > should show which code makes the value smaller. > > > > So I wrote a perl script to set a watchpoint on c->used whenever we > allocate a > > new face cache c in make_face_cache, and clear the watchpoint when we hit > > free_face_cache. Output attached, but do let me know what else you would > like > > watched. I think that has all the information your approach would have > given > > us. > > Sounds like the face ID of 18 is "remembered" somewhere, and not > "forgotten" when the face cache is free'd? > --047d7b10c8892c63f7051eb546f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This code in xdisp.c looks very suspicious = to me:

------
static int last_escape_glyph_face_id =3D (1 <<= ; FACE_ID_BITS);
static int last_escape_glyph_merged_face_id =3D 0;
<= br>static int
merge_escape_glyph_face (struct it *it)
{
=C2=A0 int= face_id;

=C2=A0 if (it->f =3D=3D last_escape_glyph_frame
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 && it->face_id =3D=3D last_escape_gl= yph_face_id)
=C2=A0=C2=A0=C2=A0 face_id =3D last_escape_glyph_merged_fac= e_id;
=C2=A0 else
=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 /* Merge the `escape-glyph' face into the current face.=C2=A0 */=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 face_id =3D merge_faces (it->f, Qescape_= glyph, 0, it->face_id);
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 last_escape_gl= yph_frame =3D it->f;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 last_escape_glyph= _face_id =3D it->face_id;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 last_escape_= glyph_merged_face_id =3D face_id;
=C2=A0=C2=A0=C2=A0 }
=C2=A0 return = face_id;
}
------

That caches a face id in last_escape_g= lyph_merged_face_id, which is cleared only in redisplay_internal(). But mes= sage() doesn't call redisplay_internal(), it calls try_window() directl= y (xdisp.c:10687) (and resize_window before that, which blows up).

<= /div>This patch appears, so far, to run without a segfault (I neglected to = record timings so can't give you a p-value, but back of the envelope it= 's >99% that it fixes the segfault), and it fixes what I think is a = possible explanation for the segfault, so my current plan is to leave it ru= nning overnight and ask for inclusion (of this or an equivalent, cleaner pa= tch, of course) if it doesn't blow up.

However, I have yet= to look at the other bugs and doubt this is the whole story.

<= /div>

On Tue= , Sep 1, 2015 at 7:37 PM, Eli Zaretskii <eliz@gnu.org> wrote:
=
> Date: Tue, 1 Sep 2015 18:52:44 +0000 > From: Pip Cet <pipcet@gmail.com= >
> Cc: 21394@debbugs.gnu.org=
>
>=C2=A0 =C2=A0 =C2=A0I see the problematic face always has face ID of 18= , and the 'used'
>=C2=A0 =C2=A0 =C2=A0field is always 15 when the segfault strikes. So I = guess the next
>=C2=A0 =C2=A0 =C2=A0step is to make the breakpoint in cache_face condit= ional on i being
>=C2=A0 =C2=A0 =C2=A018,
>
> i is used in two different ways in that function, as a face hash and a= s an
> index into faces_by_id. I assume you mean the latter?

Yes.

>=C2=A0 =C2=A0 =C2=A0and then see whether c->used is set to 19 during= that call to
>=C2=A0 =C2=A0 =C2=A0cache_face. If it does, then a watchpoint (by locat= ion) on c->used
>=C2=A0 =C2=A0 =C2=A0should show which code makes the value smaller.
>
> So I wrote a perl script to set a watchpoint on c->used whenever we= allocate a
> new face cache c in make_face_cache, and clear the watchpoint when we = hit
> free_face_cache. Output attached, but do let me know what else you wou= ld like
> watched. I think that has all the information your approach would have= given
> us.

Sounds like the face ID of 18 is "remembered" somewhere, a= nd not
"forgotten" when the face cache is free'd?

--047d7b10c8892c63f7051eb546f3-- --047d7b10c8892c63fb051eb546f5 Content-Type: text/x-patch; charset=US-ASCII; name="0001-Forget-cached-face-ids-when-displaying-echo-area-mes.patch" Content-Disposition: attachment; filename="0001-Forget-cached-face-ids-when-displaying-echo-area-mes.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ie1srbo00 RnJvbSAwNGQ2ZmFhMzE0NmU1ODVhM2UzN2E4MDE5NTRhZDI1YjVkN2UxNzkyIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaGlsaXAgPHBpcGNldEBnbWFpbC5jb20+CkRhdGU6IFR1ZSwg MSBTZXAgMjAxNSAyMDoxMDowNiArMDAwMApTdWJqZWN0OiBbUEFUQ0hdIEZvcmdldCBjYWNoZWQg ZmFjZSBpZHMgd2hlbiBkaXNwbGF5aW5nIGVjaG8gYXJlYSBtZXNzYWdlcwogKEJ1ZyMyMTM5NCkK Ci0tLQogc3JjL3hkaXNwLmMgfCA5ICsrKysrKysrLQogMSBmaWxlIGNoYW5nZWQsIDggaW5zZXJ0 aW9ucygrKSwgMSBkZWxldGlvbigtKQoKZGlmZiAtLWdpdCBhL3NyYy94ZGlzcC5jIGIvc3JjL3hk aXNwLmMKaW5kZXggOWZmOWY2Yy4uODZiN2VhMiAxMDA2NDQKLS0tIGEvc3JjL3hkaXNwLmMKKysr IGIvc3JjL3hkaXNwLmMKQEAgLTEwNjc2LDcgKzEwNjc2LDE0IEBAIGRpc3BsYXlfZWNob19hcmVh XzEgKHB0cmRpZmZfdCBhMSwgTGlzcF9PYmplY3QgYTIpCiAgIC8qIERvIHRoaXMgYmVmb3JlIGRp c3BsYXlpbmcsIHNvIHRoYXQgd2UgaGF2ZSBhIGxhcmdlIGVub3VnaCBnbHlwaAogICAgICBtYXRy aXggZm9yIHRoZSBkaXNwbGF5LiAgSWYgd2UgY2FuJ3QgZ2V0IGVub3VnaCBzcGFjZSBmb3IgdGhl CiAgICAgIHdob2xlIHRleHQsIGRpc3BsYXkgdGhlIGxhc3QgTiBsaW5lcy4gIFRoYXQgd29ya3Mg Ynkgc2V0dGluZyB3LT5zdGFydC4gICovCi0gIGJvb2wgd2luZG93X2hlaWdodF9jaGFuZ2VkX3Ag PSByZXNpemVfbWluaV93aW5kb3cgKHcsIGZhbHNlKTsKKyAgYm9vbCB3aW5kb3dfaGVpZ2h0X2No YW5nZWRfcDsKKworICBsYXN0X2VzY2FwZV9nbHlwaF9mcmFtZSA9IE5VTEw7CisgIGxhc3RfZXNj YXBlX2dseXBoX2ZhY2VfaWQgPSAoMSA8PCBGQUNFX0lEX0JJVFMpOworICBsYXN0X2dseXBobGVz c19nbHlwaF9mcmFtZSA9IE5VTEw7CisgIGxhc3RfZ2x5cGhsZXNzX2dseXBoX2ZhY2VfaWQgPSAo MSA8PCBGQUNFX0lEX0JJVFMpOworCisgIHdpbmRvd19oZWlnaHRfY2hhbmdlZF9wID0gcmVzaXpl X21pbmlfd2luZG93ICh3LCBmYWxzZSk7CiAKICAgLyogVXNlIHRoZSBzdGFydGluZyBwb3NpdGlv biBjaG9zZW4gYnkgcmVzaXplX21pbmlfd2luZG93LiAgKi8KICAgU0VUX1RFWFRfUE9TX0ZST01f TUFSS0VSIChzdGFydCwgdy0+c3RhcnQpOwotLSAKMi41LjAKCg== --047d7b10c8892c63fb051eb546f5--