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 06:42:26 -0400 Message-ID: References: <83pnld8imb.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000c8a77b058fe92ed8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="184292"; 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 Mon Aug 12 12:42:52 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 1hx7mt-000loR-RL for ged-emacs-devel@m.gmane.org; Mon, 12 Aug 2019 12:42:51 +0200 Original-Received: from localhost ([::1]:44264 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hx7ms-0000zE-D6 for ged-emacs-devel@m.gmane.org; Mon, 12 Aug 2019 06:42:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55387) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hx7ml-0000yu-UO for emacs-devel@gnu.org; Mon, 12 Aug 2019 06:42:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hx7mk-0001so-EK for emacs-devel@gnu.org; Mon, 12 Aug 2019 06:42:43 -0400 Original-Received: from mail-ot1-x32f.google.com ([2607:f8b0:4864:20::32f]:44577) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hx7mi-0001rT-Eq; Mon, 12 Aug 2019 06:42:40 -0400 Original-Received: by mail-ot1-x32f.google.com with SMTP id b7so106724511otl.11; Mon, 12 Aug 2019 03:42:39 -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=ZEu9ME9FM8rnoI6rRi1TCB4+aWLUNiNXT+vg0Tzg1To=; b=I4w7O068Sd2Ub0dFvu9uJ+g4HDkqx93XoPJ3xs4l3w9xzbRr+COsPl8Ld+kBtwaRtE AaJz6HAJKZLVaiu26PbEgkNPXUgKAiUv6pyCMdCn/TGfeab9SPvapdSHP6BtF4f9YIAC AgIyxStopuwbsvPiVh87twYAdvNu2fj7JX53GtKy0bdDJBvA8ja0n8OZoSZvUs/qNP9w GBEor+JkeRxwC+rjbST9uDni3tDuYj/9KUobA7YmBLl8gTULx9GmVKkWPStV/vmekv18 FFwqSMpRHoy3WqqvwvqGU7zQJQ6DilxzaAuIc0jO+/HD1IMp02HoGEqP/uUd6DzcRciz ZSfw== 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=ZEu9ME9FM8rnoI6rRi1TCB4+aWLUNiNXT+vg0Tzg1To=; b=TWrrPh7zaJV8YAFFGohn+uxM673canyepyaI1C/31WNunvLfRCwrollBWvkTwyDkkh vyLB7ndHGzRi7r0QONWE39u9ggid8dEkRITgFTyZLn97qgOiMQOynIKLqhcuI97NbG1I GP/i346eRuCbd0E/EH1eD8/RAMyd4ALmlpTIIHI7Me70qtJBdo6+6c2lJQKqWeYB0e0i yQ9i7y5BHFZAgRMkUY7oGdI9x7C8i1aDTbW5DkeCxj9ngNheGwT1bO8bWXEywHBso97v BSkYKFTN1TZQcLoEwo6uRasrwHR0MO/4HRwbIu+CZodMz2PNWMBNtenYgHH5ycwps5vo i3zg== X-Gm-Message-State: APjAAAUVWKNHb1pWDAG7ZRL85cfQe9gWg768vdT6AvhaovCyuJGKJePj YSRy5hIb0yxX0c4a89oQGLvOsBlvCHTbuK+OFtDczA== X-Google-Smtp-Source: APXvYqyrvY5vxxS9D9epiY9g/Iah7MgPiW0kdlxjz/UObRqNuBpdz8xxofqWFbbULPNyrxgdoYJ3VXtRpAt8Zr+IBxg= X-Received: by 2002:a5e:c918:: with SMTP id z24mr15378438iol.234.1565606558605; Mon, 12 Aug 2019 03:42:38 -0700 (PDT) In-Reply-To: <83pnld8imb.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:239331 Archived-At: --000000000000c8a77b058fe92ed8 Content-Type: text/plain; charset="UTF-8" Sorry for the delay responding. It looks like you were right about the w32 version being related; I'd noticed it previously but as dismissed it as a different platform's private static. Something similar to my original suggestion should work for the windows build too, but I don't have a Windows box to test on. Here's an annotated log of a full debugging session (which includes the backtrace you asked for). I've tried to answer your questions that way; hopefully I'll have better luck communicating with the added context. https://pastebin.com/HBB46VC5 cheers On Sat, Aug 10, 2019, 05:39 Eli Zaretskii, wrote: > > From: Liam Quinlan > > Date: Fri, 9 Aug 2019 11:40:21 -0400 > > > > It is definitely specific to cairo builds. The 'fringe_bmp' array (not > to be confused with the 'fringe_bitmaps' > > array) has a cairo api type and is declared behind #ifdef USE_CAIRO. > > I see a similar (w32-specific) variable in the MS-Windows build, so > this is at least relevant to MS-Windows as well. > > > I *think* the minimal init file to reproduce is actually '-Q'... > provided you can get flymake to display its error > > fringe indicator, which embarrassingly I cannot (no backends will run... > definitely unrelated, probably self > > inflicted). Assuming you can accomplish this (flymake-error-bitmap > uses flymake-double-exclaimation-mark, > > flymake-fringe-indicator-position isn't nil, fringe-mode is on, etc), > the steps to reproduce are very simple: > > > > 1. build --with-cairo, using any x toolkit > > 2. start an emacs server with --daemon option (ie don't 'M-x > server-mode') > > 3: connect normally with emacsclient > > 4: open a file with syntax errors and more than one screen of text > > 5: get flymake to display its error indicators > > 6: scroll up and down. It won't take very long. > > Can you please show a C-level backtrace from the crash, and also the > result of xbacktrace (this will be automatic if you start GDB in the > Emacs src/ directory)? Without that, I'm not sure I understand the > scenario, since after the emacsclient connection Emacs already has a > fringe-capable frame, so fringe related code should work. I'm > probably missing something. > > Also, I'd like to be able to reproduce without flymake. There are > built-in features that define bitmaps, like indicate-buffer-boundaries > and indicate-empty-lines; can they be used to reproduce the problem > instead of flymake? > > > Should it prove easier somehow flycheck and sesman also define custom > bitmaps, either of which will do. It > > can be any fringe-bitmap defined in package that gets loaded during the > daemon process's own startup. > > Packages that don't load until emacsclient connects are fine, as by that > point an x frame exists and > > SELECTED_FRAME will work. > > See, you are talking about "packages loaded during startup", but > didn't show any init files to that effect. This makes it hard to > reproduce the problem and debug it independently. > > Thanks. > --000000000000c8a77b058fe92ed8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry for the delay responding.=C2=A0 It looks like you w= ere right about the w32 version being related; I'd noticed it previousl= y but as dismissed it as a different platform's private static.=C2=A0 S= omething similar to my original suggestion should work for the windows buil= d too, but I don't have a Windows box to test on.

=
Here's an annotated log of a full debugging ses= sion (which includes the backtrace you asked for).=C2=A0 I've tried to = answer your questions that way; hopefully I'll have better luck communi= cating with the added context.


cheers


On Sat, Aug 10, 2019, 05:39 Eli Zaretskii, <eliz@gnu.org> wrote:
> From: Liam Quinlan <liamkquinlan@gmail.com= >
> Date: Fri, 9 Aug 2019 11:40:21 -0400
>
> It is definitely specific to cairo builds.=C2=A0 The 'fringe_bmp&#= 39; array (not to be confused with the 'fringe_bitmaps'
> array) has a cairo api type and is declared behind #ifdef USE_CAIRO.
I see a similar (w32-specific) variable in the MS-Windows build, so
this is at least relevant to MS-Windows as well.

> I *think* the minimal init file to reproduce is actually '-Q'.= .. provided you can get flymake to display its error
> fringe indicator, which embarrassingly I cannot (no backends will run.= .. definitely unrelated, probably self
> inflicted).=C2=A0 =C2=A0Assuming you can accomplish this (flymake-erro= r-bitmap uses flymake-double-exclaimation-mark,
> flymake-fringe-indicator-position isn't nil, fringe-mode is on, et= c), the steps to reproduce are very simple:
>
> 1. build --with-cairo, using any x toolkit
> 2. start an emacs server with --daemon option=C2=A0 (ie don't '= ;M-x server-mode')
> 3: connect normally with emacsclient
> 4: open a file with syntax errors and more than one screen of text
> 5: get flymake to display its error indicators
> 6: scroll up and down.=C2=A0 It won't take very long.

Can you please show a C-level backtrace from the crash, and also the
result of xbacktrace (this will be automatic if you start GDB in the
Emacs src/ directory)?=C2=A0 Without that, I'm not sure I understand th= e
scenario, since after the emacsclient connection Emacs already has a
fringe-capable frame, so fringe related code should work.=C2=A0 I'm
probably missing something.

Also, I'd like to be able to reproduce without flymake.=C2=A0 There are=
built-in features that define bitmaps, like indicate-buffer-boundaries
and indicate-empty-lines; can they be used to reproduce the problem
instead of flymake?

> Should it prove easier somehow flycheck and sesman also define custom = bitmaps, either of which will do.=C2=A0 It
> can be any fringe-bitmap defined in package that gets loaded during th= e daemon process's own startup.
> Packages that don't load until emacsclient connects are fine, as b= y that point an x frame exists and
> SELECTED_FRAME will work.

See, you are talking about "packages loaded during startup", but<= br> didn't show any init files to that effect.=C2=A0 This makes it hard to<= br> reproduce the problem and debug it independently.

Thanks.
--000000000000c8a77b058fe92ed8--