From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Liam Quinlan Newsgroups: gmane.emacs.devel Subject: Re: --with-cairo Emacs server crash and fix Date: Mon, 12 Aug 2019 22:52:31 -0400 Message-ID: References: <83pnld8imb.fsf@gnu.org> <83v9v2s4kf.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000001a5676058ff6bc59" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="160842"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 13 04:52:55 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hxMvf-000fiw-Me for ged-emacs-devel@m.gmane.org; Tue, 13 Aug 2019 04:52:55 +0200 Original-Received: from localhost ([::1]:49100 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hxMvd-000570-R5 for ged-emacs-devel@m.gmane.org; Mon, 12 Aug 2019 22:52:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55642) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hxMvY-00056i-DG for emacs-devel@gnu.org; Mon, 12 Aug 2019 22:52:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hxMvX-0006Sv-40 for emacs-devel@gnu.org; Mon, 12 Aug 2019 22:52:48 -0400 Original-Received: from mail-ot1-x32f.google.com ([2607:f8b0:4864:20::32f]:44076) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hxMvV-0006RP-8S; Mon, 12 Aug 2019 22:52:45 -0400 Original-Received: by mail-ot1-x32f.google.com with SMTP id b7so116748786otl.11; Mon, 12 Aug 2019 19:52:45 -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=BzSXwaC65ym9smgVu8w+9eDishrRsnj8r5j9b0+n+fs=; b=EDnoqFFA8qcD6F+INEJQs2fTORrcbXpVJYMkoFFfAFJF7zVvllb+oc65ZfRRuUzVpL geantE0tz2VP0/FLwHAbesaUoBVHJu/cxZmXQop3vDzpv83gzq1s02RFcfODybjBV500 6PZQxXHFn2ug6trFR6Nl/fSalq//8AncRNYWeREcMFrQf5+ikYjKkXmdd2WQhzoq8iXD oqaAkkdGLV3KY81d/FqZYvN/UCr0Boe1Z22NIRuW0avHYnYEJRxpsqrc1/fe/aqNsiQu TILRjgkMV1pOM7j2+SGQd2GXgxAo5Ay1RAR9tiPi/tpejwjK8NVEKvYNN3fyAb+tVoLX LnIQ== 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=BzSXwaC65ym9smgVu8w+9eDishrRsnj8r5j9b0+n+fs=; b=o2pDCfLnmMedUPUPe5b3GljEyoIN5qLl9G+zbpOof1jvItpfCK2seDFdCOhapjtJnd birL/2xSB6/DAoh5daT63Je271AjhRAMza5fuiuaVb4n9SxUBrBAoqd3QRQ5q/2GAq96 4r8upiB7AHU089NmYq2OuIYBrH721NtACZknz5A4vh8ghBNnfAZNYDUwjiGWLV48IKij 5NufJ/JsdKqqGg2o/D/AMk5cqu/KsrHPxnKFcAlxrkeqX0BEfr/umhZSseSz7KPh4aer QxqXK1BZG07RLQa4WOfer++sGW5KhGn6bDohQ5FrNIG4wh5ZIVO1jShX9ookn2/+OdqL dgWg== X-Gm-Message-State: APjAAAU3hIlxZLd7exodUR03lZD27bumSXz849bqJQ2QEFy/bQx/+34W iDJ35L5to9guLWqwJgLiwuSQw0RlTnWAHX9OdrtRTQ== X-Google-Smtp-Source: APXvYqz67FTDr8c6TObq38hIna0a+qYUtHLOdbolsFzdUC5g0RfWK+DPCzMNJgVcIIr5IpWDZpYFpgpKpnvuYGXv3+Y= X-Received: by 2002:a02:ca0c:: with SMTP id i12mr22724051jak.82.1565664764121; Mon, 12 Aug 2019 19:52:44 -0700 (PDT) In-Reply-To: <83v9v2s4kf.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::32f X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:239338 Archived-At: --0000000000001a5676058ff6bc59 Content-Type: text/plain; charset="UTF-8" Update: i think I've found the actual proper solution. Alternative patch on offer below; this time by checking for dynamic bitmaps already in place after finishing the static ones in x_cr_init_fringe. Note that that function also defines w32_init_fringe if HAVE_NTGUI, so windows is covered. Trying to be minimal so this example doesn't iterate to over fringe_bitmaps looking for sparse elements, just begin checking fringe_bitmaps for existing elements at the index following the standard bitmaps leaves off and continue until the first null. I'm not sure if it's too bold to trust that holes haven't had a chance to arise though. (perhaps if the server is initially used in console mode and packages get unloaded before a gui client connects...?). diff --git a/.gitignore b/.gitignore index e75df8b8b6..8711a2759b 100644 --- a/.gitignore +++ b/.gitignore @@ -290,3 +290,4 @@ nt/emacs.rc nt/emacsclient.rc src/gdb.ini /var/ +build/ diff --git a/src/fringe.c b/src/fringe.c index d0d599223d..82f2ad5d55 100644 --- a/src/fringe.c +++ b/src/fringe.c @@ -1774,16 +1774,19 @@ w32_init_fringe (struct redisplay_interface *rif) x_cr_init_fringe (struct redisplay_interface *rif) #endif { - int bt; - if (!rif) return; + int bt; + struct fringe_bitmap *fb; + for (bt = NO_FRINGE_BITMAP + 1; bt < MAX_STANDARD_FRINGE_BITMAPS; bt++) { - struct fringe_bitmap *fb = &standard_bitmaps[bt]; + fb = &standard_bitmaps[bt]; rif->define_fringe_bitmap (bt, fb->bits, fb->height, fb->width); } + while ((fb = fringe_bitmaps[bt])) + rif->define_fringe_bitmap (bt++, fb->bits, fb->height, fb->width); } #endif On Mon, Aug 12, 2019, 12:59 Eli Zaretskii, wrote: > > From: Liam Quinlan > > Date: Mon, 12 Aug 2019 06:48:25 -0400 > > Cc: emacs-devel@gnu.org > > > > ... Whoops, I guess gdb doesn't log !cmd output. Here's what should be > in that awkward empty spot. > > Thanks. This and the GDB session adds some important info, but > there's still a gap in my understanding of the problem. To close that > gap, please show the C and Lisp backtrace from the breakpoint at > fringe.c:1487 which prints "rif: unavailable". That will allow me to > understand which Lisp code tried to define fringe bitmaps when no GUI > frame is available. > --0000000000001a5676058ff6bc59 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Update: i think I've found the actual proper solution= .=C2=A0 Alternative patch on offer below; this time by checking for dynamic= bitmaps already in place after finishing the static ones in x_cr_init_frin= ge.=C2=A0 Note that that function also defines w32_init_fringe if HAVE_NTGU= I, so windows is covered.

Tryi= ng to be minimal so this example doesn't iterate to over fringe_bitmaps= looking for sparse elements, just begin checking fringe_bitmaps for existi= ng elements at the index following the standard bitmaps leaves off and cont= inue until the first null.=C2=A0 I'm not sure if it's too bold to t= rust that holes haven't had a chance to arise though. (perhaps if the s= erver is initially used in console mode and packages get unloaded before a = gui client connects...?).



diff = --git a/.gitignore b/.gitignore
index e75df8b8b6..87= 11a2759b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -290,3 +290,4 @@ nt/emacs.rc=
=C2=A0nt/emacsclient.rc
=C2= =A0src/gdb.ini
=C2=A0/var/
+b= uild/
diff --git a/src/fringe.c b/src/fringe.c
=
index d0d599223d..82f2ad5d55 100644
--- a/src/fringe.c
+++ b/src/fringe.c
@@ -1774,16 +1774,19 @@ w32_init_fringe (struct redisplay_interf= ace *rif)
=C2=A0x_cr_init_fringe (struct redisplay_i= nterface *rif)
=C2=A0#endif
= =C2=A0{
-=C2=A0 int bt;
-
=C2=A0 =C2=A0if (!rif)
=C2=A0 = =C2=A0 =C2=A0return;
=C2=A0
+= =C2=A0 int bt;
+=C2=A0 struct fringe_bitmap *fb;
+
=C2=A0 =C2=A0for (bt =3D NO_FR= INGE_BITMAP + 1; bt < MAX_STANDARD_FRINGE_BITMAPS; bt++)
=C2=A0 =C2=A0 =C2=A0{
-=C2=A0 =C2=A0 =C2= =A0 struct fringe_bitmap *fb =3D &standard_bitmaps[bt];
+=C2=A0 =C2=A0 =C2=A0 fb =3D &standard_bitmaps[bt];
=C2=A0 =C2=A0 =C2=A0 =C2=A0rif->define_fringe_bitmap (bt, = fb->bits, fb->height, fb->width);
=C2=A0 = =C2=A0 =C2=A0}
+=C2=A0 while ((fb =3D fringe_bitmaps= [bt]))
+=C2=A0 =C2=A0 =C2=A0 rif->define_fringe_b= itmap (bt++, fb->bits, fb->height, fb->width);
=C2=A0}
=C2=A0#endif


On Mon, Aug 12, 2019, 12:59 Eli Zaretskii, <eliz@gnu.org> wrote:
> From: Liam Quinlan <liamkquinlan@gmail.com&g= t;
> Date: Mon, 12 Aug 2019 06:48:25 -0400
> Cc: emacs-devel@gnu.org
>
> ... Whoops, I guess gdb doesn't log !cmd output.=C2=A0 Here's = what should be in that awkward empty spot.

Thanks.=C2=A0 This and the GDB session adds some important info, but
there's still a gap in my understanding of the problem.=C2=A0 To close = that
gap, please show the C and Lisp backtrace from the breakpoint at
fringe.c:1487 which prints "rif: unavailable".=C2=A0 That will al= low me to
understand which Lisp code tried to define fringe bitmaps when no GUI
frame is available.
--0000000000001a5676058ff6bc59--