[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#34256: 27.0.50; Crash on draw_glyphs()

From: Kaushal Modi
Subject: bug#34256: 27.0.50; Crash on draw_glyphs()
Date: Thu, 31 Jan 2019 12:02:40 -0500

On Thu, Jan 31, 2019 at 11:52 AM Eli Zaretskii <address@hidden> 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)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]