Re: --with-cairo Emacs server crash and fix

[Eli Zaretskii <eliz@gnu.org>]

> From: Liam Quinlan <liamkquinlan@gmail.com>
> 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.