From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: --with-cairo Emacs server crash and fix Date: Sat, 10 Aug 2019 12:39:08 +0300 Message-ID: <83pnld8imb.fsf@gnu.org> References: Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="227332"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Liam Quinlan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 10 11:39:48 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 1hwNqm-000wuX-P6 for ged-emacs-devel@m.gmane.org; Sat, 10 Aug 2019 11:39:48 +0200 Original-Received: from localhost ([::1]:35574 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hwNql-0003QN-5s for ged-emacs-devel@m.gmane.org; Sat, 10 Aug 2019 05:39:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36636) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hwNqG-0003Q4-9U for emacs-devel@gnu.org; Sat, 10 Aug 2019 05:39:17 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51431) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hwNqE-0003hT-7q; Sat, 10 Aug 2019 05:39:15 -0400 Original-Received: from [176.228.60.248] (port=4752 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hwNqD-00083W-Ll; Sat, 10 Aug 2019 05:39:13 -0400 In-reply-to: (message from Liam Quinlan on Fri, 9 Aug 2019 11:40:21 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:239298 Archived-At: > 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.