GNU bug report logs - #34256
27.0.50; Crash on draw_glyphs()

Previous Next

Full log

View this message in rfc822 format

From: Kaushal Modi <kaushal.modi <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34256 <at> debbugs.gnu.org
Subject: bug#34256: 27.0.50; Crash on draw_glyphs()
Date: Thu, 31 Jan 2019 12:02:40 -0500

[Message part 1 (text/plain, inline)]

On Thu, Jan 31, 2019 at 11:52 AM Eli Zaretskii <eliz <at> 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.

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.