bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#34256: 27.0.50; Crash on draw_glyphs()


From: Eli Zaretskii
Subject: bug#34256: 27.0.50; Crash on draw_glyphs()
Date: Thu, 31 Jan 2019 22:26:21 +0200

> From: Kaushal Modi <address@hidden>
> Date: Thu, 31 Jan 2019 12:02:40 -0500
> Cc: address@hidden
> 
> 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. 

OK, so here's a way that could potentially find the culprit:

  $ cd /path/to/emacs/src
  $ gdb ./emacs
  ...
  (gdb) source ./.gdbinit
  (gdb) break fill_image_glyph_string
  (gdb) run

When this breakpoint breaks, type:

  (gdb) disable
  (gdb) print s->f->terminal->image_cache->images[0]
  (gdb) watch -l s->f->terminal->image_cache->images[0] if 
s->f->terminal->image_cache->images[0] == 0
  (gdb) continue

Then invoke the rest of your recipe.  (It could be that the breakpoint
breaks only after you invoke the last two lines of the recipe.)

Each time the watchpoint breaks, type

 (gdb) bt

The result should include the Lisp backtrace as well.  If the "print"
command above shows that images[0] is already NULL, type "bt" right
there and then, before continuing with the rest.

Each time the watchpoint breaks, type "continue" until the program
segfaults, I want to see all the cases where the image in the cache
gets nullified.

I hope this will allow us to find which code causes this trouble.

Thanks.





reply via email to

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