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.