bug#34256: 27.0.50; Crash on draw_glyphs()

[Kaushal Modi <kaushal.modi@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1397 bytes --]

On Thu, Jan 31, 2019 at 11:52 AM Eli Zaretskii <eliz@gnu.org> wrote:

>
> So if you start "emacs -Q", then disable the tool bar, perhaps you can
> reproduce the problem without your elaborate setup?
>

No, I cannot.

As I mentioned earlier, I cannot reproduce the issue with my whole config
if I comment out just the desktop loading setup.

So there's something to do with frame restoring that the desktop does that
messes up something?

Here's my entire desktop setup: https://ptpb.pw/Z8TC/elisp

- The "(setq desktop-restore-frames nil)" bit doesn't get evaluated as
emacs version is >= 25.0.
- The only other desktop/frame related setup that I have is "(setq
desktop-restore-forces-onscreen nil)" (changing from the default t to nil).

And then I basically call this 1 second after my init.el finishes loading:

(desktop-save-mode 1)
(desktop-read)

>    (gdb) p FRAME_IMAGE_CACHE (s->f)->used
> >    (gdb) p FRAME_IMAGE_CACHE (s->f)->images[0]
> >
> >  (gdb) p FRAME_IMAGE_CACHE (s->f)->used
> > $2 = 2
> > (gdb) p FRAME_IMAGE_CACHE (s->f)->images[0]
> > $3 = (struct image *) 0x0
>
> OK, so something sets the image in the cache to NULL.  When you
> reproduce this, is there just one frame, or more than one?
>

There's always one frame only. I never work with multiple frames. You can
see the saved frame info in my earlier message in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34256#17.

[-- Attachment #2: Type: text/html, Size: 2386 bytes --]