... Whoops, I guess gdb doesn't log !cmd output.  Here's what should be in
that awkward empty spot.



set print pretty on
set print array on
set print array-indexes on
set style enabled off
set style sources off
set pagination off
set logging on

tbreak _start
commands
  set variable $bitmap_counter = 0
  continue
end

break fringe.c:1475 if once_p
commands
  set variable $bitmap_counter = (which > $bitmap_counter ? which :
$bitmap_counter)
  printf ">>>> init_fringe_bitmap(): end of function, once_p <<<<"
  if fringe_bitmaps
    set variable $loop = 0
    while $loop <=q $bitmap_counter
      printf "fringe_bitmaps[%d]: %p\n",$loop,fringe_bitmaps[$loop]
      set variable $loop = $loop + 1
    end
  else
    print "fringe_bitmaps == NULL"
  end
  printf "\n    which: %d\n\n",which
  continue
end

break fringe.c:1487
commands
  set variable $bitmap_counter = (which > $bitmap_counter ? which :
$bitmap_counter)
  printf "\n\n>>>> init_fringe_bitmap(): end of function, !once_p <<<<\n\n"
  if rif
    print "rif: exists"
    printf "define_fringe_bitmap: %s\n",rif->define_fringe_bitmap ?
"available" : "null"
  else
    print "rif: unavailable"
  end

  set variable $loop = 0
  while $loop <= $bitmap_counter
    printf "fringe_bitmaps[%d]: %p\n",$loop,fringe_bitmaps[$loop]
    set variable $loop = $loop + 1
  end
  if fringe_bmp
    print ""
    set variable $loop = 0
    while $loop <= $bitmap_counter
      printf "fringe_bmp[%d]: %p\n",$loop,fringe_bmp[$loop]
      set variable $loop = $loop + 1
    end
  else
    print "fringe_bmp == NULL"
  end
  printf "\n    which: %d\n\n",which
  continue
end

tbreak emacs.c:2086
commands
  printf "\n\n>>>> main(): emacs.c <<<<\n\n"
  printf "$bitmap_counter:  %d\n",$bitmap_counter
  set variable $loop = 0
  while $loop <= $bitmap_counter
    printf "fringe_bitmaps[%d]: %p\n",$loop,fringe_bitmaps[$loop]
    set variable $loop = $loop + 1
  end
  if fringe_bmp
    print ""
    set variable $loop = 0
    while $loop <= $bitmap_counter
      printf "fringe_bmp[%d]: %p\n",$loop,fringe_bmp[$loop]
      set variable $loop = $loop + 1
    end
  else
    printf "fringe_bmp == NULL\n\n"
  end
  printf "\n\n\n\
 >>>>>>>>>>>>>====================================<<<<<<<<<<<<<  \n\
      This is the end of the pre-local-load phase of startup.    \n\
      So far nothing has gone wrong.  Next, that changes.        \n\
 >>>>>>>>>>>>>====================================<<<<<<<<<<<<<  \n\n\n"
  tbreak pselect
  commands
    printf "\n\n\n\
 >>>>>>>>>>>>>====================================<<<<<<<<<<<<<  \n\
      Here's the *actual* end of what happens before connecting  \n\
      a client session.                                          \n\
      We've loaded three dynamic bitmaps from package files.     \n\
      They've been initialized into fringe_bitmaps, and so far as\n\
      emacs is concerned, are ready to use should GUI client     \n\
      connect later.  But our test for whether initializing those\n\
      bitmaps required calling rif->define_fringe_bitmap(), ie,  \n\
      'rif && rif->define_fringe_bitmap', came up false.         \n\
      Obviously that's not true; when we start a GUI frame we    \n\
      will need the cairo structures it creates.  The way things \n\
      stand, they won't be, but emacs will assume they are and   \n\
      try to use them.                                         \n\n\
      Connecting a client frame and opening a file that will     \n\
      cause us to try to draw the bitmaps...                     \n\
 >>>>>>>>>>>>>====================================<<<<<<<<<<<<<  \n\n\n"
    continue
  end
  continue
end

printf "\n\n ================================= \n\n\
   CWD: ~/self/workbench/emacs/master/src\n\
   CMDLINE: gdb -x ../../cairo_bug/gdb_script \\\n\
     --args ./emacs --fg-daemon=cairo \n\n\
   gdb_script contents: \n\n"

!cat ../../cairo_bug/gdb_script

printf "\n\nhere goes nothing...\n\n"


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