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, <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.  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.
>