bug#71929: 30.0.60; crash in mark_image_cache

bug#71929: 30.0.60; crash in mark_image_cache

[Sean Whitton]

My pgtk Emacs keeps crashing.  This time I think I caught it.
I see there was a recent commit to code around here; if this backtrace
is not sufficient, I can try bisecting, but I cannot currently reproduce
the crash reliably.

Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
0x00005555557a2c51 in mark_image_cache (c=0x55555729fc70) at image.c:3775
3775		if (c->images[i])
(gdb)

  0 in mark_image_cache of image.c:3775
  1 in mark_frame of alloc.c:7063
  2 in process_mark_stack of alloc.c:7303
  3 in mark_object of alloc.c:7504
  4 in mark_char_table of alloc.c:6920
  5 in mark_char_table of alloc.c:6917
  6 in process_mark_stack of alloc.c:7341
  7 in mark_object of alloc.c:7504
  8 in mark_char_table of alloc.c:6920
  9 in mark_char_table of alloc.c:6917
 10 in process_mark_stack of alloc.c:7341
 11 in mark_object of alloc.c:7504
 12 in mark_char_table of alloc.c:6920
 13 in mark_char_table of alloc.c:6917
 14 in process_mark_stack of alloc.c:7341
 15 in mark_object of alloc.c:7504
 16 in mark_interval_tree_1 of alloc.c:1529
 17 in traverse_intervals_noorder of intervals.c:243
 18 in mark_interval_tree of alloc.c:1538
 19 in process_mark_stack of alloc.c:7264
 20 in mark_object of alloc.c:7504
 21 in mark_interval_tree_1 of alloc.c:1529
 22 in traverse_intervals_noorder of intervals.c:243
 23 in traverse_intervals_noorder of intervals.c:248
 24 in traverse_intervals_noorder of intervals.c:248
 25 in traverse_intervals_noorder of intervals.c:248
 26 in traverse_intervals_noorder of intervals.c:248
 27 in mark_interval_tree of alloc.c:1538
 28 in mark_buffer of alloc.c:6958
 29 in process_mark_stack of alloc.c:7299
 30 in mark_object of alloc.c:7504
 31 in mark_interval_tree_1 of alloc.c:1529
 32 in traverse_intervals_noorder of intervals.c:243
 33 in mark_interval_tree of alloc.c:1538
 34 in process_mark_stack of alloc.c:7264
 35 in mark_objects of alloc.c:7512
 36 in mark_vectorlike of alloc.c:6891
 37 in mark_buffer of alloc.c:6954
 38 in process_mark_stack of alloc.c:7299
 39 in mark_object of alloc.c:7504
 40 in mark_discard_killed_buffers of alloc.c:7020
 41 in mark_window of alloc.c:7087
 42 in process_mark_stack of alloc.c:7307
 43 in mark_objects of alloc.c:7512
 44 in mark_vectorlike of alloc.c:6891
 45 in mark_window of alloc.c:7072
 46 in process_mark_stack of alloc.c:7307
 47 in mark_objects of alloc.c:7512
 48 in mark_vectorlike of alloc.c:6891
 49 in mark_frame of alloc.c:7037
 50 in process_mark_stack of alloc.c:7303
 51 in mark_objects of alloc.c:7512
 52 in mark_vectorlike of alloc.c:6891
 53 in mark_window of alloc.c:7072
 54 in process_mark_stack of alloc.c:7307
 55 in mark_object of alloc.c:7504
 56 in mark_char_table of alloc.c:6920
 57 in mark_char_table of alloc.c:6917
 58 in process_mark_stack of alloc.c:7341
 59 in mark_objects of alloc.c:7512
 60 in mark_vectorlike of alloc.c:6891
 61 in mark_buffer of alloc.c:6954
 62 in process_mark_stack of alloc.c:7299
 63 in mark_objects of alloc.c:7512
 64 in mark_vectorlike of alloc.c:6891
 65 in mark_buffer of alloc.c:6954
 66 in process_mark_stack of alloc.c:7299
 67 in mark_objects of alloc.c:7512
 68 in mark_vectorlike of alloc.c:6891
 69 in mark_buffer of alloc.c:6954
 70 in process_mark_stack of alloc.c:7299
 71 in mark_objects of alloc.c:7512
 72 in mark_vectorlike of alloc.c:6891
 73 in mark_buffer of alloc.c:6954
 74 in process_mark_stack of alloc.c:7299
 75 in mark_object of alloc.c:7504
 76 in mark_char_table of alloc.c:6920
 77 in mark_char_table of alloc.c:6917
 78 in process_mark_stack of alloc.c:7341
 79 in mark_object of alloc.c:7504
 80 in mark_char_table of alloc.c:6920
 81 in mark_char_table of alloc.c:6917
 82 in process_mark_stack of alloc.c:7341
 83 in mark_objects of alloc.c:7512
 84 in mark_vectorlike of alloc.c:6891
 85 in mark_buffer of alloc.c:6954
 86 in process_mark_stack of alloc.c:7299
 87 in mark_object of alloc.c:7504
 88 in mark_char_table of alloc.c:6920
 89 in mark_char_table of alloc.c:6917
 90 in process_mark_stack of alloc.c:7341
 91 in mark_objects of alloc.c:7512
 92 in mark_vectorlike of alloc.c:6891
 93 in mark_buffer of alloc.c:6954
 94 in process_mark_stack of alloc.c:7299
 95 in mark_objects of alloc.c:7512
 96 in mark_vectorlike of alloc.c:6891
 97 in mark_buffer of alloc.c:6954
 98 in process_mark_stack of alloc.c:7299
 99 in mark_objects of alloc.c:7512
100 in mark_vectorlike of alloc.c:6891
101 in mark_buffer of alloc.c:6954
102 in process_mark_stack of alloc.c:7299
103 in mark_objects of alloc.c:7512
104 in mark_vectorlike of alloc.c:6891
105 in mark_buffer of alloc.c:6954
106 in process_mark_stack of alloc.c:7299
107 in mark_object of alloc.c:7504
108 in mark_char_table of alloc.c:6920
109 in process_mark_stack of alloc.c:7341
110 in mark_object of alloc.c:7504
111 in mark_char_table of alloc.c:6920
112 in process_mark_stack of alloc.c:7341
113 in mark_object of alloc.c:7504
114 in mark_char_table of alloc.c:6920
115 in process_mark_stack of alloc.c:7341
116 in mark_object of alloc.c:7504
117 in mark_char_table of alloc.c:6920
118 in process_mark_stack of alloc.c:7341
119 in mark_objects of alloc.c:7512
120 in mark_vectorlike of alloc.c:6891
121 in mark_buffer of alloc.c:6954
122 in process_mark_stack of alloc.c:7299
123 in mark_objects of alloc.c:7512
124 in mark_vectorlike of alloc.c:6891
125 in mark_buffer of alloc.c:6954
126 in process_mark_stack of alloc.c:7299
127 in mark_objects of alloc.c:7512
128 in mark_vectorlike of alloc.c:6891
129 in mark_buffer of alloc.c:6954
130 in process_mark_stack of alloc.c:7299
131 in mark_objects of alloc.c:7512
132 in mark_vectorlike of alloc.c:6891
133 in mark_buffer of alloc.c:6954
134 in process_mark_stack of alloc.c:7299
135 in mark_objects of alloc.c:7512
136 in mark_vectorlike of alloc.c:6891
137 in mark_buffer of alloc.c:6954
138 in process_mark_stack of alloc.c:7299
139 in mark_objects of alloc.c:7512
140 in mark_vectorlike of alloc.c:6891
141 in mark_buffer of alloc.c:6954
142 in process_mark_stack of alloc.c:7299
143 in mark_objects of alloc.c:7512
144 in mark_vectorlike of alloc.c:6891
145 in mark_buffer of alloc.c:6954
146 in process_mark_stack of alloc.c:7299
147 in mark_objects of alloc.c:7512
148 in mark_vectorlike of alloc.c:6891
149 in mark_buffer of alloc.c:6954
150 in process_mark_stack of alloc.c:7299
151 in mark_object of alloc.c:7504
152 in mark_object_root_visitor of alloc.c:6396
153 in visit_vectorlike_root of alloc.c:6348
154 in visit_buffer_root of alloc.c:6362
155 in visit_static_gc_roots of alloc.c:6374
156 in garbage_collect of alloc.c:6598
157 in maybe_garbage_collect of alloc.c:6507
158 in maybe_gc of /home/spwhitton/src/emacs/primary/src/lisp.h:5929
159 in Ffuncall of eval.c:3088
160 in read_char of /home/spwhitton/src/emacs/primary/src/lisp.h:1178
161 in read_key_sequence of keyboard.c:10743
162 in command_loop_1 of /home/spwhitton/src/emacs/primary/src/lisp.h:1178
163 in internal_condition_case of eval.c:1613
164 in command_loop_2 of keyboard.c:1168
165 in internal_catch of eval.c:1292
166 in command_loop of /home/spwhitton/src/emacs/primary/src/lisp.h:1178
167 in recursive_edit_1 of keyboard.c:754
168 in Frecursive_edit of keyboard.c:837
169 in main of emacs.c:2631

-- 
Sean Whitton

bug#71929: 30.0.60; crash in mark_image_cache

[Sean Whitton]

Hello,

On Thu 04 Jul 2024 at 10:33am +08, Sean Whitton wrote:

> My pgtk Emacs keeps crashing.  This time I think I caught it.
> I see there was a recent commit to code around here; if this backtrace
> is not sufficient, I can try bisecting, but I cannot currently reproduce
> the crash reliably.
>
> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
> 0x00005555557a2c51 in mark_image_cache (c=0x55555729fc70) at image.c:3775
> 3775		if (c->images[i])
> (gdb)

... and i was 0, i.e. it crashes on the first iteration.

-- 
Sean Whitton

bug#71929: 30.0.60; crash in mark_image_cache

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Date: Thu, 04 Jul 2024 10:44:04 +0800
> 
> Hello,
> 
> On Thu 04 Jul 2024 at 10:33am +08, Sean Whitton wrote:
> 
> > My pgtk Emacs keeps crashing.  This time I think I caught it.
> > I see there was a recent commit to code around here; if this backtrace
> > is not sufficient, I can try bisecting, but I cannot currently reproduce
> > the crash reliably.
> >
> > Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
> > 0x00005555557a2c51 in mark_image_cache (c=0x55555729fc70) at image.c:3775
> > 3775		if (c->images[i])
> > (gdb)
> 
> ... and i was 0, i.e. it crashes on the first iteration.

What is the value of c->images?  IOW, why did this line segfault?

bug#71929: 30.0.60; crash in mark_image_cache

[Eli Zaretskii]

> Cc: 71929@debbugs.gnu.org
> Date: Thu, 04 Jul 2024 08:53:41 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Sean Whitton <spwhitton@spwhitton.name>
> > Date: Thu, 04 Jul 2024 10:44:04 +0800
> > 
> > Hello,
> > 
> > On Thu 04 Jul 2024 at 10:33am +08, Sean Whitton wrote:
> > 
> > > My pgtk Emacs keeps crashing.  This time I think I caught it.
> > > I see there was a recent commit to code around here; if this backtrace
> > > is not sufficient, I can try bisecting, but I cannot currently reproduce
> > > the crash reliably.
> > >
> > > Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
> > > 0x00005555557a2c51 in mark_image_cache (c=0x55555729fc70) at image.c:3775
> > > 3775		if (c->images[i])
> > > (gdb)
> > 
> > ... and i was 0, i.e. it crashes on the first iteration.
> 
> What is the value of c->images?  IOW, why did this line segfault?

Also, what is the value of c->refcount?

bug#71929: 30.0.60; crash in mark_image_cache

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: 71929@debbugs.gnu.org
>> Date: Thu, 04 Jul 2024 08:53:41 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> 
>> > From: Sean Whitton <spwhitton@spwhitton.name>
>> > Date: Thu, 04 Jul 2024 10:44:04 +0800
>> > 
>> > Hello,
>> > 
>> > On Thu 04 Jul 2024 at 10:33am +08, Sean Whitton wrote:
>> > 
>> > > My pgtk Emacs keeps crashing.  This time I think I caught it.
>> > > I see there was a recent commit to code around here; if this backtrace
>> > > is not sufficient, I can try bisecting, but I cannot currently reproduce
>> > > the crash reliably.
>> > >
>> > > Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
>> > > 0x00005555557a2c51 in mark_image_cache (c=0x55555729fc70) at image.c:3775
>> > > 3775		if (c->images[i])
>> > > (gdb)
>> > 
>> > ... and i was 0, i.e. it crashes on the first iteration.
>> 
>> What is the value of c->images?  IOW, why did this line segfault?
>
> Also, what is the value of c->refcount?

Please answer these questions, yes.

bug#71929: 30.0.60; crash in mark_image_cache

[Sean Whitton]

Hello,

On Thu 04 Jul 2024 at 02:17pm +08, Po Lu wrote:

>>> What is the value of c->images?  IOW, why did this line segfault?
>>
>> Also, what is the value of c->refcount?
>
> Please answer these questions, yes.

I don't know, but I will see if I can get information about these next
time I observe the crash.

I struggle to keep the Emacs instance running gdb around very long
because it keeps crashing too :)

-- 
Sean Whitton

bug#71929: 30.0.60; crash in mark_image_cache

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Sean Whitton <spwhitton@spwhitton.name> writes:

> I don't know, but I will see if I can get information about these next
> time I observe the crash.
>
> I struggle to keep the Emacs instance running gdb around very long
> because it keeps crashing too :)

What packages have you installed, and do they frequently create new
frames or adjust the font size of existing frames?

bug#71929: 30.0.60; crash in mark_image_cache

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: 71929@debbugs.gnu.org
> Date: Thu, 04 Jul 2024 14:42:01 +0800
> 
> Hello,
> 
> On Thu 04 Jul 2024 at 02:17pm +08, Po Lu wrote:
> 
> >>> What is the value of c->images?  IOW, why did this line segfault?
> >>
> >> Also, what is the value of c->refcount?
> >
> > Please answer these questions, yes.
> 
> I don't know, but I will see if I can get information about these next
> time I observe the crash.
> 
> I struggle to keep the Emacs instance running gdb around very long
> because it keeps crashing too :)

Do you mean GDB keeps crashing?

If you run GDB from Emacs, then try running it from the shell prompt
instead.

bug#71929: 30.0.60; crash in mark_image_cache

[Sean Whitton]

Hello,

On Thu 04 Jul 2024 at 02:59pm +08, Po Lu wrote:

> Sean Whitton <spwhitton@spwhitton.name> writes:
>
>> I don't know, but I will see if I can get information about these next
>> time I observe the crash.
>>
>> I struggle to keep the Emacs instance running gdb around very long
>> because it keeps crashing too :)
>
> What packages have you installed, and do they frequently create new
> frames or adjust the font size of existing frames?

The packages I have installed don't do that, but I have tonnes of custom
code in my init.el to create new frames and adjust font sizes.
I normally have >=three frames open for each of two instances of Emacs.

I have two entries in window-size-change-functions:

--8<---------------cut here---------------start------------->8---
(defun spw/maybe-scale-basic-faces (frame)
  "Entry for `window-size-change-functions' to increase font sizes,
relative to those set by the call to `custom-theme-set-faces' above, for
frames on wide monitors, except where doing so would itself prevent fitting
two 80-column windows side-by-side in the frame."
  (when (display-graphic-p frame)
   (let ((wide-monitor-p (> (cadddr (assoc 'geometry
					   (frame-monitor-attributes frame)))
			    1635)))
     (when (or wide-monitor-p
	       ;; Check whether a previous call made any changes we might need
	       ;; to undo if FRAME has moved to a smaller display.
	       (not (eq scroll-bar-mode
			(frame-parameter frame 'vertical-scroll-bars)))
	       (= (face-attribute 'default :height frame) 120)
	       (= (face-attribute 'variable-pitch :height frame) 151))
       (let* (;; Above 1635 you can scale up and still fit two 80-col windows.
	      ;; Below 1315 you can't fit the two windows even w/o scaling up.
	      (medium-p (> 1635 (frame-pixel-width frame) 1315))
	      (scale-up-p (and wide-monitor-p (not medium-p))))
	 (modify-frame-parameters
	  frame
	  `(;; Can fit two 80-col windows only if we disable scroll bars.
	    (vertical-scroll-bars . ,(and (not (and wide-monitor-p medium-p))
					  scroll-bar-mode))))
	 ;; Check Emacs found the relevant font on this window system, else
	 ;; our height values might be invalid.
	 (when (find-font (font-spec :foundry "SRC" :family "Hack") frame)
	   (set-face-attribute 'default frame
			       :height (if scale-up-p 120 105)))
	 (when (find-font (font-spec :foundry "bitstream"
				     :family "Bitstream Charter")
			  frame)
	   (set-face-attribute 'variable-pitch frame
			       :height (if scale-up-p 151 120))))))))
--8<---------------cut here---------------end--------------->8---

and

--8<---------------cut here---------------start------------->8---
(defun spw/maybe-toggle-split-after-resize (frame)
  (when (and (framep frame)
	     (frame-size-changed-p frame)
	     (= (count-windows nil frame) 2))
    (with-selected-frame frame
      (cl-labels ((toggleable-window-p (window)
		    (with-current-buffer (window-buffer window)
		      (not (derived-mode-p 'gnus-summary-mode))))
		  (window-info (window)
		    (and (toggleable-window-p window)
			 (cons (window-buffer window)
			       (cons (window-prev-buffers window)
				     (window-next-buffers window)))))
		  (set-window-info (window info)
		    (set-window-buffer window (car info))
		    (set-window-prev-buffers window (cadr info))
		    (set-window-next-buffers window (cddr info))))
	(when-let* ((this-info (window-info (selected-window)))
		    (next-info (window-info (next-window)))
		    (width (frame-width))
		    (this-edges (window-edges (selected-window)))
		    (next-edges (window-edges (next-window))))
	  (when (or (and (< width split-width-threshold)
			 (/= (car this-edges) (car next-edges)))
		    (and (>= width split-width-threshold)
			 (/= (cadr this-edges) (cadr next-edges))))
	    ;; Ensure we start with a fresh window.
	    (split-window)
	    (other-window 1)
	    (delete-other-windows)

	    (if (and (<= (car this-edges) (car next-edges))
		     (<= (cadr this-edges) (cadr next-edges)))
		;; Want to use `pop-to-buffer' for the second window s.t. my
		;; rule for REPLs in `display-buffer-alist' takes effect.
		(progn (set-window-info (selected-window) this-info)
		       (save-selected-window
			 (pop-to-buffer (car next-info))
			 (set-window-info (selected-window) next-info)))
	      (set-window-info (selected-window) next-info)
	      (pop-to-buffer (car this-info))
	      (set-window-info (selected-window) this-info))))))))
--8<---------------cut here---------------end--------------->8---

For completeness, though I doubt it is relevant, packages (installed
from Debian) are:

elpa-bongo
elpa-dash
elpa-debian-el
elpa-dpkg-dev-el
elpa-esxml
elpa-ggtags
elpa-git-annex
elpa-git-commit
elpa-git-modes
elpa-gitattributes-mode
elpa-gitconfig-mode
elpa-gitignore-mode
elpa-haskell-tab-indent
elpa-htmlize
elpa-ledger
elpa-magit
elpa-magit-section
elpa-mailscripts
elpa-markdown-mode
elpa-message-templ
elpa-notmuch
elpa-nov
elpa-org
elpa-org-contrib
elpa-org-d20
elpa-orgalist
elpa-paredit
elpa-pod-mode
elpa-rainbow-mode
elpa-s
elpa-seq
elpa-taxy
elpa-volume
elpa-with-editor
elpa-ws-butler
elpa-yasnippet
elpa-yasnippet-snippets

-- 
Sean Whitton

bug#71929: 30.0.60; crash in mark_image_cache

[Sean Whitton]

Hello,

On Thu 04 Jul 2024 at 10:40am +03, Eli Zaretskii wrote:

>> From: Sean Whitton <spwhitton@spwhitton.name>
>> Cc: 71929@debbugs.gnu.org
>> Date: Thu, 04 Jul 2024 14:42:01 +0800
>>
>> Hello,
>>
>> On Thu 04 Jul 2024 at 02:17pm +08, Po Lu wrote:
>>
>> >>> What is the value of c->images?  IOW, why did this line segfault?
>> >>
>> >> Also, what is the value of c->refcount?
>> >
>> > Please answer these questions, yes.
>>
>> I don't know, but I will see if I can get information about these next
>> time I observe the crash.
>>
>> I struggle to keep the Emacs instance running gdb around very long
>> because it keeps crashing too :)
>
> Do you mean GDB keeps crashing?
>
> If you run GDB from Emacs,

The latter.

> then try running it from the shell prompt instead.

I have running Emacs-under-GDB-under-Emacs all scripted and integrated
into my desktop environment, but yes, if I have to, I can figure out
running it from a terminal instead.

-- 
Sean Whitton

bug#71929: 30.0.60; crash in mark_image_cache

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Sean Whitton <spwhitton@spwhitton.name> writes:

> Hello,
>
> On Thu 04 Jul 2024 at 02:59pm +08, Po Lu wrote:
>
>> Sean Whitton <spwhitton@spwhitton.name> writes:
>>
>>> I don't know, but I will see if I can get information about these next
>>> time I observe the crash.
>>>
>>> I struggle to keep the Emacs instance running gdb around very long
>>> because it keeps crashing too :)
>>
>> What packages have you installed, and do they frequently create new
>> frames or adjust the font size of existing frames?
>
> The packages I have installed don't do that, but I have tonnes of custom
> code in my init.el to create new frames and adjust font sizes.
> I normally have >=three frames open for each of two instances of Emacs.
>
> I have two entries in window-size-change-functions:
>
> (defun spw/maybe-scale-basic-faces (frame)
>   "Entry for `window-size-change-functions' to increase font sizes,
> relative to those set by the call to `custom-theme-set-faces' above, for
> frames on wide monitors, except where doing so would itself prevent fitting
> two 80-column windows side-by-side in the frame."
>   (when (display-graphic-p frame)
>    (let ((wide-monitor-p (> (cadddr (assoc 'geometry
> 					   (frame-monitor-attributes frame)))
> 			    1635)))
>      (when (or wide-monitor-p
> 	       ;; Check whether a previous call made any changes we might need
> 	       ;; to undo if FRAME has moved to a smaller display.
> 	       (not (eq scroll-bar-mode
> 			(frame-parameter frame 'vertical-scroll-bars)))
> 	       (= (face-attribute 'default :height frame) 120)
> 	       (= (face-attribute 'variable-pitch :height frame) 151))
>        (let* (;; Above 1635 you can scale up and still fit two 80-col windows.
> 	      ;; Below 1315 you can't fit the two windows even w/o scaling up.
> 	      (medium-p (> 1635 (frame-pixel-width frame) 1315))
> 	      (scale-up-p (and wide-monitor-p (not medium-p))))
> 	 (modify-frame-parameters
> 	  frame
> 	  `(;; Can fit two 80-col windows only if we disable scroll bars.
> 	    (vertical-scroll-bars . ,(and (not (and wide-monitor-p medium-p))
> 					  scroll-bar-mode))))
> 	 ;; Check Emacs found the relevant font on this window system, else
> 	 ;; our height values might be invalid.
> 	 (when (find-font (font-spec :foundry "SRC" :family "Hack") frame)
> 	   (set-face-attribute 'default frame
> 			       :height (if scale-up-p 120 105)))
> 	 (when (find-font (font-spec :foundry "bitstream"
> 				     :family "Bitstream Charter")
> 			  frame)
> 	   (set-face-attribute 'variable-pitch frame
> 			       :height (if scale-up-p 151 120))))))))
>
>
> and
>
> (defun spw/maybe-toggle-split-after-resize (frame)
>   (when (and (framep frame)
> 	     (frame-size-changed-p frame)
> 	     (= (count-windows nil frame) 2))
>     (with-selected-frame frame
>       (cl-labels ((toggleable-window-p (window)
> 		    (with-current-buffer (window-buffer window)
> 		      (not (derived-mode-p 'gnus-summary-mode))))
> 		  (window-info (window)
> 		    (and (toggleable-window-p window)
> 			 (cons (window-buffer window)
> 			       (cons (window-prev-buffers window)
> 				     (window-next-buffers window)))))
> 		  (set-window-info (window info)
> 		    (set-window-buffer window (car info))
> 		    (set-window-prev-buffers window (cadr info))
> 		    (set-window-next-buffers window (cddr info))))
> 	(when-let* ((this-info (window-info (selected-window)))
> 		    (next-info (window-info (next-window)))
> 		    (width (frame-width))
> 		    (this-edges (window-edges (selected-window)))
> 		    (next-edges (window-edges (next-window))))
> 	  (when (or (and (< width split-width-threshold)
> 			 (/= (car this-edges) (car next-edges)))
> 		    (and (>= width split-width-threshold)
> 			 (/= (cadr this-edges) (cadr next-edges))))
> 	    ;; Ensure we start with a fresh window.
> 	    (split-window)
> 	    (other-window 1)
> 	    (delete-other-windows)
>
> 	    (if (and (<= (car this-edges) (car next-edges))
> 		     (<= (cadr this-edges) (cadr next-edges)))
> 		;; Want to use `pop-to-buffer' for the second window s.t. my
> 		;; rule for REPLs in `display-buffer-alist' takes effect.
> 		(progn (set-window-info (selected-window) this-info)
> 		       (save-selected-window
> 			 (pop-to-buffer (car next-info))
> 			 (set-window-info (selected-window) next-info)))
> 	      (set-window-info (selected-window) next-info)
> 	      (pop-to-buffer (car this-info))
> 	      (set-window-info (selected-window) this-info))))))))
>
> For completeness, though I doubt it is relevant, packages (installed
> from Debian) are:
>
> elpa-bongo
> elpa-dash
> elpa-debian-el
> elpa-dpkg-dev-el
> elpa-esxml
> elpa-ggtags
> elpa-git-annex
> elpa-git-commit
> elpa-git-modes
> elpa-gitattributes-mode
> elpa-gitconfig-mode
> elpa-gitignore-mode
> elpa-haskell-tab-indent
> elpa-htmlize
> elpa-ledger
> elpa-magit
> elpa-magit-section
> elpa-mailscripts
> elpa-markdown-mode
> elpa-message-templ
> elpa-notmuch
> elpa-nov
> elpa-org
> elpa-org-contrib
> elpa-org-d20
> elpa-orgalist
> elpa-paredit
> elpa-pod-mode
> elpa-rainbow-mode
> elpa-s
> elpa-seq
> elpa-taxy
> elpa-volume
> elpa-with-editor
> elpa-ws-butler
> elpa-yasnippet
> elpa-yasnippet-snippets

Thanks.  It may be of assistance if you were to run an Emacs configured
`--enable-checking=yes,all' for a while and report whether any
assertions fail.

bug#71929: 30.0.60; crash in mark_image_cache

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: luangruo@yahoo.com,  71929@debbugs.gnu.org
> Date: Thu, 04 Jul 2024 17:57:48 +0800
> 
> > Do you mean GDB keeps crashing?
> >
> > If you run GDB from Emacs,
> 
> The latter.
> 
> > then try running it from the shell prompt instead.
> 
> I have running Emacs-under-GDB-under-Emacs all scripted and integrated
> into my desktop environment, but yes, if I have to, I can figure out
> running it from a terminal instead.

If Emacs keeps crashing, then running GDB from such an Emacs will
endanger your chances of collecting useful information.  If you have
older and more stable Emacs installed, try running GDB from that older
version.  Or from the shell prompt.

bug#71929: 30.0.60; crash in mark_image_cache

[Sean Whitton]

Hello,

On Thu 04 Jul 2024 at 09:03am +03, Eli Zaretskii wrote:

>> What is the value of c->images?  IOW, why did this line segfault?
>
> Also, what is the value of c->refcount?

(gdb) p c
$1 = (struct image_cache *) 0x555557c89e20
(gdb) xpr
There is no member named i.

(gdb) p c->images
$2 = (struct image **) 0x35
(gdb) xpr
Cannot access memory at address 0x35

(gdb) p c->refcount
$4 = 93823560581177

-- 
Sean Whitton

bug#71929: 30.0.60; crash in mark_image_cache

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: 71929@debbugs.gnu.org
> Date: Fri, 05 Jul 2024 08:13:14 +0800
> 
> Hello,
> 
> On Thu 04 Jul 2024 at 09:03am +03, Eli Zaretskii wrote:
> 
> >> What is the value of c->images?  IOW, why did this line segfault?
> >
> > Also, what is the value of c->refcount?
> 
> (gdb) p c
> $1 = (struct image_cache *) 0x555557c89e20
> (gdb) xpr
> There is no member named i.
> 
> (gdb) p c->images
> $2 = (struct image **) 0x35
> (gdb) xpr
> Cannot access memory at address 0x35
> 
> (gdb) p c->refcount
> $4 = 93823560581177

So it's garbled.

Po Lu, how do we handle the "shared" image cache when a frame is
deleted?  Where's the code which frees the cache if the cache's
refcount is one when the frame is deleted?

bug#71929: 30.0.60; crash in mark_image_cache

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Sean Whitton <spwhitton@spwhitton.name>
>> Cc: 71929@debbugs.gnu.org
>> Date: Fri, 05 Jul 2024 08:13:14 +0800
>> 
>> Hello,
>> 
>> On Thu 04 Jul 2024 at 09:03am +03, Eli Zaretskii wrote:
>> 
>> >> What is the value of c->images?  IOW, why did this line segfault?
>> >
>> > Also, what is the value of c->refcount?
>> 
>> (gdb) p c
>> $1 = (struct image_cache *) 0x555557c89e20
>> (gdb) xpr
>> There is no member named i.
>> 
>> (gdb) p c->images
>> $2 = (struct image **) 0x35
>> (gdb) xpr
>> Cannot access memory at address 0x35
>> 
>> (gdb) p c->refcount
>> $4 = 93823560581177
>
> So it's garbled.
>
> Po Lu, how do we handle the "shared" image cache when a frame is
> deleted?  Where's the code which frees the cache if the cache's
> refcount is one when the frame is deleted?

There's only one caller of free_image_cache, free_frame_faces, which is
only called once in a frame's existence.  Cache refcounts are also
altered from gui_set_font, but this process never entails decrementing a
refcount to zero, as the caches under consideration are always retained
by one or more frames:

  iwidth = max (10, FRAME_COLUMN_WIDTH (f));
  if (FRAME_IMAGE_CACHE (f)
      && (iwidth != FRAME_IMAGE_CACHE (f)->scaling_col_width))
    {
      eassert (FRAME_IMAGE_CACHE (f)->refcount >= 1);
      if (FRAME_IMAGE_CACHE (f)->refcount == 1)
	{
	  /* This frame is the only user of this image cache.  */
	  FRAME_IMAGE_CACHE (f)->scaling_col_width = iwidth;
	  /* Clean F's image cache of images whose values are derived
	     from the font width.  */
	  clear_image_cache (f, Qauto);
	}
      else
	{
	  /* Release the current image cache, and reuse or allocate a
	     new image cache with IWIDTH.  */
	  FRAME_IMAGE_CACHE (f)->refcount--;
	  FRAME_IMAGE_CACHE (f) = share_image_cache (f);
	  FRAME_IMAGE_CACHE (f)->refcount++;
	}
    }

bug#71929: 30.0.60; crash in mark_image_cache

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Sean Whitton <spwhitton@spwhitton.name>,  71929@debbugs.gnu.org
> Date: Fri, 05 Jul 2024 14:41:31 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Sean Whitton <spwhitton@spwhitton.name>
> >> Cc: 71929@debbugs.gnu.org
> >> Date: Fri, 05 Jul 2024 08:13:14 +0800
> >> 
> >> Hello,
> >> 
> >> On Thu 04 Jul 2024 at 09:03am +03, Eli Zaretskii wrote:
> >> 
> >> >> What is the value of c->images?  IOW, why did this line segfault?
> >> >
> >> > Also, what is the value of c->refcount?
> >> 
> >> (gdb) p c
> >> $1 = (struct image_cache *) 0x555557c89e20
> >> (gdb) xpr
> >> There is no member named i.
> >> 
> >> (gdb) p c->images
> >> $2 = (struct image **) 0x35
> >> (gdb) xpr
> >> Cannot access memory at address 0x35
> >> 
> >> (gdb) p c->refcount
> >> $4 = 93823560581177
> >
> > So it's garbled.
> >
> > Po Lu, how do we handle the "shared" image cache when a frame is
> > deleted?  Where's the code which frees the cache if the cache's
> > refcount is one when the frame is deleted?
> 
> There's only one caller of free_image_cache, free_frame_faces, which is
> only called once in a frame's existence.  Cache refcounts are also
> altered from gui_set_font, but this process never entails decrementing a
> refcount to zero, as the caches under consideration are always retained
> by one or more frames:
> 
>   iwidth = max (10, FRAME_COLUMN_WIDTH (f));
>   if (FRAME_IMAGE_CACHE (f)
>       && (iwidth != FRAME_IMAGE_CACHE (f)->scaling_col_width))
>     {
>       eassert (FRAME_IMAGE_CACHE (f)->refcount >= 1);
>       if (FRAME_IMAGE_CACHE (f)->refcount == 1)
> 	{
> 	  /* This frame is the only user of this image cache.  */
> 	  FRAME_IMAGE_CACHE (f)->scaling_col_width = iwidth;
> 	  /* Clean F's image cache of images whose values are derived
> 	     from the font width.  */
> 	  clear_image_cache (f, Qauto);
> 	}
>       else
> 	{
> 	  /* Release the current image cache, and reuse or allocate a
> 	     new image cache with IWIDTH.  */
> 	  FRAME_IMAGE_CACHE (f)->refcount--;
> 	  FRAME_IMAGE_CACHE (f) = share_image_cache (f);
> 	  FRAME_IMAGE_CACHE (f)->refcount++;
> 	}
>     }

How does this answer my question?

The use case I was thinking of is that the image cache was shared,
then the last frame which shared the cache was deleted.  How do we
make sure the cache is freed and set to NULL in this situation?

IOW, we seem to have a cache that is not NULL but is also not a real
cache, as it cannot be accessed.  The question is how did that happen?

bug#71929: 30.0.60; crash in mark_image_cache

[Sean Whitton]

Hello,

On Thu 04 Jul 2024 at 08:28pm +08, Po Lu wrote:

> Thanks.  It may be of assistance if you were to run an Emacs configured
> `--enable-checking=yes,all' for a while and report whether any
> assertions fail.

Okay, rebuilding with that configuration option.

I tried removing my two custom functions from
window-size-change-functions.  This seems to mean that crashing is much
less frequent, but it still happens.

-- 
Sean Whitton

bug#71929: 30.0.60; crash in mark_image_cache

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> How does this answer my question?

I mentioned free_frame_faces.  That's the only function where image
caches are released.

> The use case I was thinking of is that the image cache was shared,
> then the last frame which shared the cache was deleted.  How do we
> make sure the cache is freed and set to NULL in this situation?

The cache (whose refcount is 1) is released in free_frame_faces when it
is called with this final frame, through free_image_cache, which also
resets its `FRAME_IMAGE_CACHE' to NULL.

> IOW, we seem to have a cache that is not NULL but is also not a real
> cache, as it cannot be accessed.  The question is how did that happen?

I don't know.  It can only be the case if its `refcount' was decremented
excessively for a reason not yet understood.

bug#71929: 30.0.60; crash in mark_image_cache

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: spwhitton@spwhitton.name,  71929@debbugs.gnu.org
> Date: Fri, 05 Jul 2024 17:36:49 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > How does this answer my question?
> 
> I mentioned free_frame_faces.  That's the only function where image
> caches are released.
> 
> > The use case I was thinking of is that the image cache was shared,
> > then the last frame which shared the cache was deleted.  How do we
> > make sure the cache is freed and set to NULL in this situation?
> 
> The cache (whose refcount is 1) is released in free_frame_faces when it
> is called with this final frame, through free_image_cache, which also
> resets its `FRAME_IMAGE_CACHE' to NULL.
> 
> > IOW, we seem to have a cache that is not NULL but is also not a real
> > cache, as it cannot be accessed.  The question is how did that happen?
> 
> I don't know.  It can only be the case if its `refcount' was decremented
> excessively for a reason not yet understood.

Can you suggest a GDB setup for Sean to use in order to try to find
this unknown code which causes this?

Please note that this affects the release branch, and the changeset
which seems to have caused it was installed a couple of days before
the release branch was cut.  So if we cannot find and solve the
problem soon enough, I'd revert that changeset and solve the original
problem which it was supposed to solve on master, rather than leave
such a serious problem on the release branch.

bug#71929: 30.0.60; crash in mark_image_cache

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> Can you suggest a GDB setup for Sean to use in order to try to find
> this unknown code which causes this?

I suggested compiling --enable-checking, as there is an assert which I
expect to be activated in these situations.

> Please note that this affects the release branch, and the changeset
> which seems to have caused it was installed a couple of days before
> the release branch was cut.  So if we cannot find and solve the
> problem soon enough, I'd revert that changeset and solve the original
> problem which it was supposed to solve on master, rather than leave
> such a serious problem on the release branch.

OK.

bug#71929: 30.0.60; crash in mark_image_cache

[Sean Whitton]

Hello,

On Fri 05 Jul 2024 at 07:40pm +08, Po Lu wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Can you suggest a GDB setup for Sean to use in order to try to find
>> this unknown code which causes this?
>
> I suggested compiling --enable-checking, as there is an assert which I
> expect to be activated in these situations.

Yeah, now running with this.  Probably I'll have a crash within a day.

-- 
Sean Whitton

bug#71929: 30.0.60; crash in mark_image_cache

[Sean Whitton]

Hello,

On Fri 05 Jul 2024 at 07:40pm +08, Po Lu wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Can you suggest a GDB setup for Sean to use in order to try to find
>> this unknown code which causes this?
>
> I suggested compiling --enable-checking, as there is an assert which I
> expect to be activated in these situations.

I recompiled with this.  It crashed again this morning.  Unfortunately
it just crashed in the same way, without hitting any other failed
assertions along the way.  Here is the backtrace.

  0 in mark_image_cache of image.c:3775
  1 in mark_frame of alloc.c:7063
  2 in process_mark_stack of alloc.c:7303
  3 in mark_objects of alloc.c:7512
  4 in mark_vectorlike of alloc.c:6891
  5 in mark_window of alloc.c:7072
  6 in process_mark_stack of alloc.c:7307
  7 in mark_objects of alloc.c:7512
  8 in mark_vectorlike of alloc.c:6891
  9 in mark_frame of alloc.c:7037
 10 in process_mark_stack of alloc.c:7303
 11 in mark_objects of alloc.c:7512
 12 in mark_vectorlike of alloc.c:6891
 13 in mark_window of alloc.c:7072
 14 in process_mark_stack of alloc.c:7307
 15 in mark_object of alloc.c:7504
 16 in mark_char_table of alloc.c:6920
 17 in mark_char_table of alloc.c:6917
 18 in process_mark_stack of alloc.c:7341
 19 in mark_object of alloc.c:7504
 20 in mark_char_table of alloc.c:6920
 21 in mark_char_table of alloc.c:6917
 22 in process_mark_stack of alloc.c:7341
 23 in mark_object of alloc.c:7504
 24 in mark_interval_tree_1 of alloc.c:1529
 25 in traverse_intervals_noorder of intervals.c:243
 26 in traverse_intervals_noorder of intervals.c:248
 27 in traverse_intervals_noorder of intervals.c:248
 28 in traverse_intervals_noorder of intervals.c:248
 29 in mark_interval_tree of alloc.c:1538
 30 in mark_buffer of alloc.c:6958
 31 in process_mark_stack of alloc.c:7299
 32 in mark_objects of alloc.c:7512
 33 in mark_vectorlike of alloc.c:6891
 34 in mark_buffer of alloc.c:6954
 35 in process_mark_stack of alloc.c:7299
 36 in mark_object of alloc.c:7504
 37 in mark_discard_killed_buffers of alloc.c:7020
 38 in mark_window of alloc.c:7087
 39 in process_mark_stack of alloc.c:7307
 40 in mark_objects of alloc.c:7512
 41 in mark_vectorlike of alloc.c:6891
 42 in mark_frame of alloc.c:7037
 43 in process_mark_stack of alloc.c:7303
 44 in mark_object of alloc.c:7504
 45 in mark_interval_tree_1 of alloc.c:1529
 46 in traverse_intervals_noorder of intervals.c:243
 47 in mark_interval_tree of alloc.c:1538
 48 in process_mark_stack of alloc.c:7264
 49 in mark_objects of alloc.c:7512
 50 in mark_vectorlike of alloc.c:6891
 51 in mark_buffer of alloc.c:6954
 52 in process_mark_stack of alloc.c:7299
 53 in mark_object of alloc.c:7504
 54 in mark_interval_tree_1 of alloc.c:1529
 55 in traverse_intervals_noorder of intervals.c:243
 56 in traverse_intervals_noorder of intervals.c:248
 57 in traverse_intervals_noorder of intervals.c:248
 58 in mark_interval_tree of alloc.c:1538
 59 in process_mark_stack of alloc.c:7264
 60 in mark_object of alloc.c:7504
 61 in mark_glyph_matrix of alloc.c:6847
 62 in mark_window of alloc.c:7079
 63 in process_mark_stack of alloc.c:7307
 64 in mark_objects of alloc.c:7512
 65 in mark_vectorlike of alloc.c:6891
 66 in mark_frame of alloc.c:7037
 67 in process_mark_stack of alloc.c:7303
 68 in mark_object of alloc.c:7504
 69 in mark_interval_tree_1 of alloc.c:1529
 70 in traverse_intervals_noorder of intervals.c:243
 71 in mark_interval_tree of alloc.c:1538
 72 in process_mark_stack of alloc.c:7264
 73 in mark_object of alloc.c:7504
 74 in mark_overlay of alloc.c:6933
 75 in process_mark_stack of alloc.c:7355
 76 in mark_objects of alloc.c:7512
 77 in mark_vectorlike of alloc.c:6891
 78 in mark_buffer of alloc.c:6954
 79 in process_mark_stack of alloc.c:7299
 80 in mark_object of alloc.c:7504
 81 in mark_interval_tree_1 of alloc.c:1529
 82 in traverse_intervals_noorder of intervals.c:243
 83 in mark_interval_tree of alloc.c:1538
 84 in process_mark_stack of alloc.c:7264
 85 in mark_object of alloc.c:7504
 86 in mark_char_table of alloc.c:6920
 87 in mark_char_table of alloc.c:6917
 88 in process_mark_stack of alloc.c:7341
 89 in mark_object of alloc.c:7504
 90 in mark_char_table of alloc.c:6920
 91 in mark_char_table of alloc.c:6917
 92 in process_mark_stack of alloc.c:7341
 93 in mark_objects of alloc.c:7512
 94 in mark_vectorlike of alloc.c:6891
 95 in mark_buffer of alloc.c:6954
 96 in process_mark_stack of alloc.c:7299
 97 in mark_objects of alloc.c:7512
 98 in mark_vectorlike of alloc.c:6891
 99 in mark_buffer of alloc.c:6954
100 in process_mark_stack of alloc.c:7299
101 in mark_object of alloc.c:7504
102 in mark_char_table of alloc.c:6920
103 in mark_char_table of alloc.c:6917
104 in process_mark_stack of alloc.c:7341
105 in mark_objects of alloc.c:7512
106 in mark_vectorlike of alloc.c:6891
107 in mark_buffer of alloc.c:6954
108 in process_mark_stack of alloc.c:7299
109 in mark_objects of alloc.c:7512
110 in mark_vectorlike of alloc.c:6891
111 in mark_buffer of alloc.c:6954
112 in process_mark_stack of alloc.c:7299
113 in mark_objects of alloc.c:7512
114 in mark_vectorlike of alloc.c:6891
115 in mark_buffer of alloc.c:6954
116 in process_mark_stack of alloc.c:7299
117 in mark_objects of alloc.c:7512
118 in mark_vectorlike of alloc.c:6891
119 in mark_buffer of alloc.c:6954
120 in process_mark_stack of alloc.c:7299
121 in mark_objects of alloc.c:7512
122 in mark_vectorlike of alloc.c:6891
123 in mark_buffer of alloc.c:6954
124 in process_mark_stack of alloc.c:7299
125 in mark_object of alloc.c:7504
126 in mark_object_root_visitor of alloc.c:6396
127 in visit_vectorlike_root of alloc.c:6348
128 in visit_buffer_root of alloc.c:6362
129 in visit_static_gc_roots of alloc.c:6374
130 in garbage_collect of alloc.c:6598
131 in maybe_garbage_collect of alloc.c:6507
132 in maybe_gc of /home/spwhitton/src/emacs/primary/src/lisp.h:5929
133 in exec_byte_code of bytecode.c:787
134 in funcall_lambda of eval.c:3252
135 in funcall_general of eval.c:3044
136 in Ffuncall of eval.c:3093
137 in Fapply of eval.c:2718
138 in funcall_subr of eval.c:3184
139 in exec_byte_code of bytecode.c:812
140 in funcall_lambda of eval.c:3252
141 in funcall_general of eval.c:3044
142 in Ffuncall of eval.c:3093
143 in timer_check_2 of /home/spwhitton/src/emacs/primary/src/lisp.h:1178
144 in timer_check of keyboard.c:4866
145 in readable_events of keyboard.c:3591
146 in get_input_pending of keyboard.c:7869
147 in detect_input_pending_run_timers of keyboard.c:11573
148 in wait_reading_process_output of process.c:5838
149 in kbd_buffer_get_event of /home/spwhitton/src/emacs/primary/src/lisp.h:1178
150 in read_event_from_main_queue of keyboard.c:2330
151 in read_decoded_event_from_main_queue of keyboard.c:2394
152 in read_char of keyboard.c:3015
153 in read_key_sequence of keyboard.c:10743
154 in command_loop_1 of /home/spwhitton/src/emacs/primary/src/lisp.h:1178
155 in internal_condition_case of eval.c:1613
156 in command_loop_2 of keyboard.c:1168
157 in internal_catch of eval.c:1292
158 in command_loop of /home/spwhitton/src/emacs/primary/src/lisp.h:1178
159 in recursive_edit_1 of keyboard.c:754
160 in Frecursive_edit of keyboard.c:837
161 in main of emacs.c:2631

-- 
Sean Whitton

bug#71929: 30.0.60; crash in mark_image_cache

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Sean Whitton <spwhitton@spwhitton.name> writes:

> I recompiled with this.  It crashed again this morning.  Unfortunately
> it just crashed in the same way, without hitting any other failed
> assertions along the way.  Here is the backtrace.
>
>   0 in mark_image_cache of image.c:3775
>   1 in mark_frame of alloc.c:7063
>   2 in process_mark_stack of alloc.c:7303
>   3 in mark_objects of alloc.c:7512
>   4 in mark_vectorlike of alloc.c:6891
>   5 in mark_window of alloc.c:7072
>   6 in process_mark_stack of alloc.c:7307
>   7 in mark_objects of alloc.c:7512
>   8 in mark_vectorlike of alloc.c:6891
>   9 in mark_frame of alloc.c:7037
>  10 in process_mark_stack of alloc.c:7303
>  11 in mark_objects of alloc.c:7512
>  12 in mark_vectorlike of alloc.c:6891
>  13 in mark_window of alloc.c:7072
>  14 in process_mark_stack of alloc.c:7307
>  15 in mark_object of alloc.c:7504
>  16 in mark_char_table of alloc.c:6920
>  17 in mark_char_table of alloc.c:6917
>  18 in process_mark_stack of alloc.c:7341
>  19 in mark_object of alloc.c:7504
>  20 in mark_char_table of alloc.c:6920
>  21 in mark_char_table of alloc.c:6917
>  22 in process_mark_stack of alloc.c:7341
>  23 in mark_object of alloc.c:7504
>  24 in mark_interval_tree_1 of alloc.c:1529
>  25 in traverse_intervals_noorder of intervals.c:243
>  26 in traverse_intervals_noorder of intervals.c:248
>  27 in traverse_intervals_noorder of intervals.c:248
>  28 in traverse_intervals_noorder of intervals.c:248
>  29 in mark_interval_tree of alloc.c:1538
>  30 in mark_buffer of alloc.c:6958
>  31 in process_mark_stack of alloc.c:7299
>  32 in mark_objects of alloc.c:7512
>  33 in mark_vectorlike of alloc.c:6891
>  34 in mark_buffer of alloc.c:6954
>  35 in process_mark_stack of alloc.c:7299
>  36 in mark_object of alloc.c:7504
>  37 in mark_discard_killed_buffers of alloc.c:7020
>  38 in mark_window of alloc.c:7087
>  39 in process_mark_stack of alloc.c:7307
>  40 in mark_objects of alloc.c:7512
>  41 in mark_vectorlike of alloc.c:6891
>  42 in mark_frame of alloc.c:7037
>  43 in process_mark_stack of alloc.c:7303
>  44 in mark_object of alloc.c:7504
>  45 in mark_interval_tree_1 of alloc.c:1529
>  46 in traverse_intervals_noorder of intervals.c:243
>  47 in mark_interval_tree of alloc.c:1538
>  48 in process_mark_stack of alloc.c:7264
>  49 in mark_objects of alloc.c:7512
>  50 in mark_vectorlike of alloc.c:6891
>  51 in mark_buffer of alloc.c:6954
>  52 in process_mark_stack of alloc.c:7299
>  53 in mark_object of alloc.c:7504
>  54 in mark_interval_tree_1 of alloc.c:1529
>  55 in traverse_intervals_noorder of intervals.c:243
>  56 in traverse_intervals_noorder of intervals.c:248
>  57 in traverse_intervals_noorder of intervals.c:248
>  58 in mark_interval_tree of alloc.c:1538
>  59 in process_mark_stack of alloc.c:7264
>  60 in mark_object of alloc.c:7504
>  61 in mark_glyph_matrix of alloc.c:6847
>  62 in mark_window of alloc.c:7079
>  63 in process_mark_stack of alloc.c:7307
>  64 in mark_objects of alloc.c:7512
>  65 in mark_vectorlike of alloc.c:6891
>  66 in mark_frame of alloc.c:7037
>  67 in process_mark_stack of alloc.c:7303
>  68 in mark_object of alloc.c:7504
>  69 in mark_interval_tree_1 of alloc.c:1529
>  70 in traverse_intervals_noorder of intervals.c:243
>  71 in mark_interval_tree of alloc.c:1538
>  72 in process_mark_stack of alloc.c:7264
>  73 in mark_object of alloc.c:7504
>  74 in mark_overlay of alloc.c:6933
>  75 in process_mark_stack of alloc.c:7355
>  76 in mark_objects of alloc.c:7512
>  77 in mark_vectorlike of alloc.c:6891
>  78 in mark_buffer of alloc.c:6954
>  79 in process_mark_stack of alloc.c:7299
>  80 in mark_object of alloc.c:7504
>  81 in mark_interval_tree_1 of alloc.c:1529
>  82 in traverse_intervals_noorder of intervals.c:243
>  83 in mark_interval_tree of alloc.c:1538
>  84 in process_mark_stack of alloc.c:7264
>  85 in mark_object of alloc.c:7504
>  86 in mark_char_table of alloc.c:6920
>  87 in mark_char_table of alloc.c:6917
>  88 in process_mark_stack of alloc.c:7341
>  89 in mark_object of alloc.c:7504
>  90 in mark_char_table of alloc.c:6920
>  91 in mark_char_table of alloc.c:6917
>  92 in process_mark_stack of alloc.c:7341
>  93 in mark_objects of alloc.c:7512
>  94 in mark_vectorlike of alloc.c:6891
>  95 in mark_buffer of alloc.c:6954
>  96 in process_mark_stack of alloc.c:7299
>  97 in mark_objects of alloc.c:7512
>  98 in mark_vectorlike of alloc.c:6891
>  99 in mark_buffer of alloc.c:6954
> 100 in process_mark_stack of alloc.c:7299
> 101 in mark_object of alloc.c:7504
> 102 in mark_char_table of alloc.c:6920
> 103 in mark_char_table of alloc.c:6917
> 104 in process_mark_stack of alloc.c:7341
> 105 in mark_objects of alloc.c:7512
> 106 in mark_vectorlike of alloc.c:6891
> 107 in mark_buffer of alloc.c:6954
> 108 in process_mark_stack of alloc.c:7299
> 109 in mark_objects of alloc.c:7512
> 110 in mark_vectorlike of alloc.c:6891
> 111 in mark_buffer of alloc.c:6954
> 112 in process_mark_stack of alloc.c:7299
> 113 in mark_objects of alloc.c:7512
> 114 in mark_vectorlike of alloc.c:6891
> 115 in mark_buffer of alloc.c:6954
> 116 in process_mark_stack of alloc.c:7299
> 117 in mark_objects of alloc.c:7512
> 118 in mark_vectorlike of alloc.c:6891
> 119 in mark_buffer of alloc.c:6954
> 120 in process_mark_stack of alloc.c:7299
> 121 in mark_objects of alloc.c:7512
> 122 in mark_vectorlike of alloc.c:6891
> 123 in mark_buffer of alloc.c:6954
> 124 in process_mark_stack of alloc.c:7299
> 125 in mark_object of alloc.c:7504
> 126 in mark_object_root_visitor of alloc.c:6396
> 127 in visit_vectorlike_root of alloc.c:6348
> 128 in visit_buffer_root of alloc.c:6362
> 129 in visit_static_gc_roots of alloc.c:6374
> 130 in garbage_collect of alloc.c:6598
> 131 in maybe_garbage_collect of alloc.c:6507
> 132 in maybe_gc of /home/spwhitton/src/emacs/primary/src/lisp.h:5929
> 133 in exec_byte_code of bytecode.c:787
> 134 in funcall_lambda of eval.c:3252
> 135 in funcall_general of eval.c:3044
> 136 in Ffuncall of eval.c:3093
> 137 in Fapply of eval.c:2718
> 138 in funcall_subr of eval.c:3184
> 139 in exec_byte_code of bytecode.c:812
> 140 in funcall_lambda of eval.c:3252
> 141 in funcall_general of eval.c:3044
> 142 in Ffuncall of eval.c:3093
> 143 in timer_check_2 of /home/spwhitton/src/emacs/primary/src/lisp.h:1178
> 144 in timer_check of keyboard.c:4866
> 145 in readable_events of keyboard.c:3591
> 146 in get_input_pending of keyboard.c:7869
> 147 in detect_input_pending_run_timers of keyboard.c:11573
> 148 in wait_reading_process_output of process.c:5838
> 149 in kbd_buffer_get_event of /home/spwhitton/src/emacs/primary/src/lisp.h:1178
> 150 in read_event_from_main_queue of keyboard.c:2330
> 151 in read_decoded_event_from_main_queue of keyboard.c:2394
> 152 in read_char of keyboard.c:3015
> 153 in read_key_sequence of keyboard.c:10743
> 154 in command_loop_1 of /home/spwhitton/src/emacs/primary/src/lisp.h:1178
> 155 in internal_condition_case of eval.c:1613
> 156 in command_loop_2 of keyboard.c:1168
> 157 in internal_catch of eval.c:1292
> 158 in command_loop of /home/spwhitton/src/emacs/primary/src/lisp.h:1178
> 159 in recursive_edit_1 of keyboard.c:754
> 160 in Frecursive_edit of keyboard.c:837
> 161 in main of emacs.c:2631

Thanks.  Would you mind running Emacs with this patch installed and
configured with the aforesaid option, and responding with backtraces
from any triggered assertion?

diff --git a/src/frame.c b/src/frame.c
index 7f4bf274ad9..a4b8ca207ee 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -4831,14 +4831,18 @@ gui_set_font (struct frame *f, Lisp_Object arg, Lisp_Object oldval)
 	  /* Clean F's image cache of images whose values are derived
 	     from the font width.  */
 	  clear_image_cache (f, Qauto);
+	  verify_image_cache_refcount (f);
 	}
       else
 	{
 	  /* Release the current image cache, and reuse or allocate a
 	     new image cache with IWIDTH.  */
 	  FRAME_IMAGE_CACHE (f)->refcount--;
+	  FRAME_IMAGE_CACHE (f) = NULL;
+	  verify_image_cache_refcount (f);
 	  FRAME_IMAGE_CACHE (f) = share_image_cache (f);
 	  FRAME_IMAGE_CACHE (f)->refcount++;
+	  verify_image_cache_refcount (f);
 	}
     }
 
diff --git a/src/frame.h b/src/frame.h
index 1d920d1a6bc..eee694d6920 100644
--- a/src/frame.h
+++ b/src/frame.h
@@ -1682,6 +1682,34 @@ IMAGE_OPT_FROM_ID (struct frame *f, int id)
   eassume (0 <= used);
   return 0 <= id && id < used ? FRAME_IMAGE_CACHE (f)->images[id] : NULL;
 }
+
+/* Abort if F's image cache's `refcount' field disagrees with the number
+   of frames holding references to the same.  */
+
+INLINE void
+verify_image_cache_refcount (f)
+     struct frame *f;
+{
+#ifdef ENABLE_CHECKING
+  int expected;
+  Lisp_Object tail, frame;
+
+  if (FRAME_IMAGE_CACHE (f))
+    {
+      expected = 0;
+
+      FOR_EACH_FRAME (tail, frame)
+	{
+	  if (FRAME_IMAGE_CACHE (XFRAME (frame))
+	      == FRAME_IMAGE_CACHE (f))
+	    expected++;
+	}
+
+      eassert (expected == FRAME_IMAGE_CACHE (f)->refcount);
+    }
+#endif /* ENABLE_CHECKING */
+}
+
 #endif
 \f
 /***********************************************************************
diff --git a/src/image.c b/src/image.c
index 2945447b962..9420c579d7b 100644
--- a/src/image.c
+++ b/src/image.c
@@ -3625,6 +3625,7 @@ cache_image (struct frame *f, struct image *img)
     {
       c = FRAME_IMAGE_CACHE (f) = share_image_cache (f);
       c->refcount++;
+      verify_image_cache_refcount (f);
     }
 
   /* Find a free slot in c->images.  */
diff --git a/src/xfaces.c b/src/xfaces.c
index 188dd4778bc..0e0172e1984 100644
--- a/src/xfaces.c
+++ b/src/xfaces.c
@@ -680,6 +680,7 @@ init_frame_faces (struct frame *f)
     {
       FRAME_IMAGE_CACHE (f) = share_image_cache (f);
       ++FRAME_IMAGE_CACHE (f)->refcount;
+      verify_image_cache_refcount (f);
     }
 #endif /* HAVE_WINDOW_SYSTEM */
 
@@ -709,6 +710,7 @@ free_frame_faces (struct frame *f)
       struct image_cache *image_cache = FRAME_IMAGE_CACHE (f);
       if (image_cache)
 	{
+	  verify_image_cache_refcount (f);
 	  --image_cache->refcount;
 	  if (image_cache->refcount == 0)
 	    free_image_cache (f);

bug#71929: 30.0.60; crash in mark_image_cache

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: Eli Zaretskii <eliz@gnu.org>,  71929@debbugs.gnu.org
> Date: Sat, 06 Jul 2024 10:41:15 +0800
> 
> I recompiled with this.  It crashed again this morning.  Unfortunately
> it just crashed in the same way, without hitting any other failed
> assertions along the way.  Here is the backtrace.
> 
>   0 in mark_image_cache of image.c:3775
>   1 in mark_frame of alloc.c:7063
>   2 in process_mark_stack of alloc.c:7303

Do you still have this crashes session in GDB, so I could ask you to
look around and show values of some variables?

bug#71929: 30.0.60; crash in mark_image_cache

[Sean Whitton]

Hello,

On Sat 06 Jul 2024 at 09:40am +03, Eli Zaretskii wrote:

>> From: Sean Whitton <spwhitton@spwhitton.name>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  71929@debbugs.gnu.org
>> Date: Sat, 06 Jul 2024 10:41:15 +0800
>>
>> I recompiled with this.  It crashed again this morning.  Unfortunately
>> it just crashed in the same way, without hitting any other failed
>> assertions along the way.  Here is the backtrace.
>>
>>   0 in mark_image_cache of image.c:3775
>>   1 in mark_frame of alloc.c:7063
>>   2 in process_mark_stack of alloc.c:7303
>
> Do you still have this crashes session in GDB, so I could ask you to
> look around and show values of some variables?

Unfortunately not.  I'll try to keep it aronud next time, and please let
me know as many variables as you have already thought of as soon as you
can.

-- 
Sean Whitton

bug#71929: 30.0.60; crash in mark_image_cache

[Sean Whitton]

Hello,

On Sat 06 Jul 2024 at 02:08pm +08, Po Lu wrote:

>
> Thanks.  Would you mind running Emacs with this patch installed and
> configured with the aforesaid option, and responding with backtraces
> from any triggered assertion?

Will do.

-- 
Sean Whitton

bug#71929: 30.0.60; crash in mark_image_cache

[Sean Whitton]

Hello,

On Sat 06 Jul 2024 at 02:08pm +08, Po Lu wrote:

> Thanks.  Would you mind running Emacs with this patch installed and
> configured with the aforesaid option, and responding with backtraces
> from any triggered assertion?

I launch it with emacs --fg-daemon under gdb and it crashes immediately,
before I've had chance to open any frames with emacsclient:

 0 in terminate_due_to_signal of emacs.c:442
 1 in die of alloc.c:8083
 2 in verify_image_cache_refcount of /home/spwhitton/src/emacs/primary/src/frame.h:1708
 3 in init_frame_faces of xfaces.c:683
 4 in Fx_create_frame of pgtkfns.c:1467
 5 in funcall_subr of eval.c:3161
 6 in exec_byte_code of bytecode.c:812
 7 in funcall_lambda of eval.c:3252
 8 in funcall_general of eval.c:3044
 9 in Ffuncall of eval.c:3093
10 in Fapply of eval.c:2722
11 in funcall_subr of eval.c:3184
12 in exec_byte_code of bytecode.c:812
13 in funcall_lambda of eval.c:3252
14 in funcall_general of eval.c:3044
15 in Ffuncall of eval.c:3093
16 in Fapply of eval.c:2765
17 in apply1 of eval.c:2981
18 in read_process_output_call of process.c:6129
19 in internal_condition_case_1 of eval.c:1637
20 in read_and_dispose_of_process_output of process.c:6498
21 in read_process_output of process.c:6266
22 in wait_reading_process_output of process.c:5947
23 in kbd_buffer_get_event of /home/spwhitton/src/emacs/primary/src/lisp.h:1178
24 in read_event_from_main_queue of keyboard.c:2330
25 in read_decoded_event_from_main_queue of keyboard.c:2394
26 in read_char of keyboard.c:3015
27 in read_key_sequence of keyboard.c:10743
28 in command_loop_1 of /home/spwhitton/src/emacs/primary/src/lisp.h:1178
29 in internal_condition_case of eval.c:1613
30 in command_loop_2 of keyboard.c:1168
31 in internal_catch of eval.c:1292
32 in command_loop of /home/spwhitton/src/emacs/primary/src/lisp.h:1178
33 in recursive_edit_1 of keyboard.c:754
34 in Frecursive_edit of keyboard.c:837
35 in main of emacs.c:2631

-- 
Sean Whitton

bug#71929: 30.0.60; crash in mark_image_cache

[Sean Whitton]

Hello,

On Sun 07 Jul 2024 at 10:43am +08, Sean Whitton wrote:

> Hello,
>
> On Sat 06 Jul 2024 at 02:08pm +08, Po Lu wrote:
>
>> Thanks.  Would you mind running Emacs with this patch installed and
>> configured with the aforesaid option, and responding with backtraces
>> from any triggered assertion?
>
> I launch it with emacs --fg-daemon under gdb and it crashes immediately,
> before I've had chance to open any frames with emacsclient:

Not quite.  It crashes when I try to use 'emacsclient -c' to open the
first graphical frame.

-- 
Sean Whitton

bug#71929: 30.0.60; crash in mark_image_cache

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Sean Whitton <spwhitton@spwhitton.name> writes:

> Hello,
>
> On Sun 07 Jul 2024 at 10:43am +08, Sean Whitton wrote:
>
>> Hello,
>>
>> On Sat 06 Jul 2024 at 02:08pm +08, Po Lu wrote:
>>
>>> Thanks.  Would you mind running Emacs with this patch installed and
>>> configured with the aforesaid option, and responding with backtraces
>>> from any triggered assertion?
>>
>> I launch it with emacs --fg-daemon under gdb and it crashes immediately,
>> before I've had chance to open any frames with emacsclient:
>
> Not quite.  It crashes when I try to use 'emacsclient -c' to open the
> first graphical frame.

Please move into verify_image_cache_refcount and execute:

  (gdb) p expected
  (gdb) p FRAME_IMAGE_CACHE (f)
  (gdb) p FRAME_IMAGE_CACHE (f)->refcount
  (gdb) set $cons = Vframe_list
  (gdb) while $cons
   >xgetptr $cons
   >p ((struct Lisp_Cons *) $ptr)->u.s.car
   >xframe
   >p *$
   >xgetptr $cons
   >set $cons = ((struct Lisp_Cons *) $ptr)->u.s.u.cdr
   >end

bug#71929: 30.0.60; crash in mark_image_cache

[Sean Whitton]

Hello,

On Sun 07 Jul 2024 at 12:04pm +08, Po Lu wrote:

> Sean Whitton <spwhitton@spwhitton.name> writes:
>
>> Hello,
>>
>> On Sun 07 Jul 2024 at 10:43am +08, Sean Whitton wrote:
>>
>>> Hello,
>>>
>>> On Sat 06 Jul 2024 at 02:08pm +08, Po Lu wrote:
>>>
>>>> Thanks.  Would you mind running Emacs with this patch installed and
>>>> configured with the aforesaid option, and responding with backtraces
>>>> from any triggered assertion?
>>>
>>> I launch it with emacs --fg-daemon under gdb and it crashes immediately,
>>> before I've had chance to open any frames with emacsclient:
>>
>> Not quite.  It crashes when I try to use 'emacsclient -c' to open the
>> first graphical frame.
>
> Please move into verify_image_cache_refcount and execute:
>
>   (gdb) p expected
>   (gdb) p FRAME_IMAGE_CACHE (f)
>   (gdb) p FRAME_IMAGE_CACHE (f)->refcount
>   (gdb) set $cons = Vframe_list
>   (gdb) while $cons
>    >xgetptr $cons
>    >p ((struct Lisp_Cons *) $ptr)->u.s.car
>    >xframe
>    >p *$
>    >xgetptr $cons
>    >set $cons = ((struct Lisp_Cons *) $ptr)->u.s.u.cdr
>    >end

(gdb) p expected
$1 = 0
(gdb) p FRAME_IMAGE_CACHE (f)
$2 = (struct image_cache *) 0x555557f29270
(gdb) p FRAME_IMAGE_CACHE (f)->refcount
$3 = 1
(gdb) set $cons = Vframe_list
[...]
$4 = XIL(0x555555f3dfd5)
$5 = (struct frame *) 0x555555f3dfd0
"F1"
$6 = {
  header = {
    size = 4611686018595352602
  },
  name = XIL(0x55555587c944),
  icon_name = XIL(0),
  title = XIL(0),
  parent_frame = XIL(0),
  last_mouse_device = XIL(0),
  focus_frame = XIL(0),
  root_window = XIL(0x555555f3e225),
  selected_window = XIL(0x555555f3e225),
  old_selected_window = XIL(0),
  minibuffer_window = XIL(0x555555f3e4cd),
  param_alist = XIL(0x555557a23523),
  scroll_bars = XIL(0),
  condemned_scroll_bars = XIL(0),
  menu_bar_items = XIL(0),
  face_hash_table = XIL(0x555555f3e775),
  menu_bar_vector = XIL(0),
  buffer_predicate = XIL(0),
  buffer_list = XIL(0x555557a23503),
  buried_buffer_list = XIL(0),
  tab_bar_window = XIL(0),
  desired_tab_bar_string = XIL(0),
  current_tab_bar_string = XIL(0),
  tool_bar_position = XIL(0x11d00),
  font_data = XIL(0),
  tab_bar_items = XIL(0),
  tool_bar_items = XIL(0),
  face_cache = 0x555555f741d0,
  image_cache = 0x0,
  last_tab_bar_item = -1,
  menu_bar_items_used = 0,
  current_pool = 0x555555f3f4b0,
  desired_pool = 0x555555f3f490,
  desired_matrix = 0x555555f3f4d0,
  current_matrix = 0x555555f3f740,
  glyphs_initialized_p = true,
  resized_p = true,
  default_face_done_p = false,
  already_hscrolled_p = false,
  updated_p = false,
  minimize_tab_bar_window_p = false,
  external_tool_bar = false,
  fonts_changed = false,
  cursor_type_changed = false,
  redisplay = true,
  external_menu_bar = false,
  visible = 1,
  iconified = false,
  garbaged = true,
  wants_modeline = true,
  auto_raise = false,
  auto_lower = false,
  no_split = false,
  explicit_name = false,
  window_change = true,
  window_state_change = false,
  mouse_moved = false,
  pointer_invisible = false,
  frozen_window_starts = false,
  output_method = output_initial,
  tooltip = false,
  want_fullscreen = FULLSCREEN_NONE,
  vertical_scroll_bar_type = vertical_scroll_bar_none,
  horizontal_scroll_bars = false,
  undecorated = false,
  override_redirect = false,
  skip_taskbar = false,
  no_focus_on_map = false,
  no_accept_focus = false,
  z_group = z_group_none,
  no_special_glyphs = false,
  can_set_window_size = true,
  after_make_frame = true,
  tab_bar_redisplayed = false,
  tab_bar_resized = false,
  tool_bar_redisplayed = false,
  tool_bar_resized = false,
  inhibit_horizontal_resize = false,
  inhibit_vertical_resize = false,
  face_change = true,
  inhibit_clear_image_cache = false,
  new_size_p = false,
  was_invisible = false,
  select_mini_window_flag = false,
  change_stamp = 1,
  number_of_windows = 0,
  tab_bar_lines = 0,
  tab_bar_height = 0,
  n_tab_bar_rows = 0,
  n_tab_bar_items = 0,
  tool_bar_lines = 0,
  tool_bar_height = 0,
  n_tool_bar_rows = 0,
  n_tool_bar_items = 0,
  decode_mode_spec_buffer = 0x555555f3f340 "",
  insert_line_cost = 0x0,
  delete_line_cost = 0x0,
  insert_n_lines_cost = 0x0,
  delete_n_lines_cost = 0x0,
  text_cols = 80,
  text_lines = 24,
  text_width = 80,
  text_height = 24,
  total_cols = 80,
  total_lines = 25,
  pixel_width = 80,
  pixel_height = 25,
  new_width = -1,
  new_height = -1,
  left_pos = 0,
  top_pos = 0,
  win_gravity = 0,
  size_hint_flags = 0,
  border_width = 0,
  child_frame_border_width = -1,
  internal_border_width = 0,
  right_divider_width = 0,
  bottom_divider_width = 0,
  left_fringe_width = 0,
  right_fringe_width = 0,
  fringe_cols = 0,
  menu_bar_lines = 1,
  menu_bar_height = 1,
  column_width = 1,
  line_height = 1,
  terminal = 0x555555f3ddb0,
  output_data = {
    tty = 0x0,
    x = 0x0,
    w32 = 0x0,
    ns = 0x0,
    pgtk = 0x0,
    haiku = 0x0,
    android = 0x0
  },
  font_driver_list = 0x0,
  desired_cursor = FILLED_BOX_CURSOR,
  cursor_width = 0,
  blink_off_cursor = FILLED_BOX_CURSOR,
  blink_off_cursor_width = 0,
  config_scroll_bar_width = 0,
  config_scroll_bar_cols = 0,
  config_scroll_bar_height = 0,
  config_scroll_bar_lines = 0,
  cost_calculation_baud_rate = 0,
  alpha = {0, 0},
  alpha_background = 0,
  gamma = 0,
  extra_line_spacing = 0,
  background_pixel = 18446744073709551613,
  foreground_pixel = 18446744073709551614
}

-- 
Sean Whitton

bug#71929: 30.0.60; crash in mark_image_cache

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: 71929@debbugs.gnu.org,  Eli Zaretskii <eliz@gnu.org>
> Date: Sun, 07 Jul 2024 12:54:13 +0800
> 
> > Please move into verify_image_cache_refcount and execute:
> >
> >   (gdb) p expected
> >   (gdb) p FRAME_IMAGE_CACHE (f)
> >   (gdb) p FRAME_IMAGE_CACHE (f)->refcount
> >   (gdb) set $cons = Vframe_list
> >   (gdb) while $cons
> >    >xgetptr $cons
> >    >p ((struct Lisp_Cons *) $ptr)->u.s.car
> >    >xframe
> >    >p *$
> >    >xgetptr $cons
> >    >set $cons = ((struct Lisp_Cons *) $ptr)->u.s.u.cdr
> >    >end
> 
> (gdb) p expected
> $1 = 0
> (gdb) p FRAME_IMAGE_CACHE (f)
> $2 = (struct image_cache *) 0x555557f29270
> (gdb) p FRAME_IMAGE_CACHE (f)->refcount
> $3 = 1
> (gdb) set $cons = Vframe_list
> [...]
> $4 = XIL(0x555555f3dfd5)
> $5 = (struct frame *) 0x555555f3dfd0
> "F1"
> $6 = {
>   header = {
>     size = 4611686018595352602
>   },
> [...]
>   terminal = 0x555555f3ddb0,
>   output_data = {
>     tty = 0x0,
>     x = 0x0,
>     w32 = 0x0,
>     ns = 0x0,
>     pgtk = 0x0,
>     haiku = 0x0,
>     android = 0x0
>   },

This is the initial frame of the daemon.  It is not a GUI frame, and
so it should not have a valid image cache.  I guess some change is
needed in verify_image_cache_refcount?

bug#71929: 30.0.60; crash in mark_image_cache

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> This is the initial frame of the daemon.  It is not a GUI frame, and
> so it should not have a valid image cache.  I guess some change is
> needed in verify_image_cache_refcount?

Not quite: init_frame_faces is apparently called before the frame is
entered into Vframe_list, so, likewise, the face cache's reference count
should be verified before it is incremented.

Sean, please retry with this patch substituted for the previous:

diff --git a/src/frame.c b/src/frame.c
index 7f4bf274ad9..9793b9f5cbe 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -4831,14 +4831,20 @@ gui_set_font (struct frame *f, Lisp_Object arg, Lisp_Object oldval)
 	  /* Clean F's image cache of images whose values are derived
 	     from the font width.  */
 	  clear_image_cache (f, Qauto);
+	  verify_image_cache_refcount (FRAME_IMAGE_CACHE (f));
 	}
       else
 	{
+	  struct image_cache *old_cache = FRAME_IMAGE_CACHE (f);
+
 	  /* Release the current image cache, and reuse or allocate a
 	     new image cache with IWIDTH.  */
 	  FRAME_IMAGE_CACHE (f)->refcount--;
+	  FRAME_IMAGE_CACHE (f) = NULL;
+	  verify_image_cache_refcount (old_cache);
 	  FRAME_IMAGE_CACHE (f) = share_image_cache (f);
 	  FRAME_IMAGE_CACHE (f)->refcount++;
+	  verify_image_cache_refcount (FRAME_IMAGE_CACHE (f));
 	}
     }
 
diff --git a/src/frame.h b/src/frame.h
index 1d920d1a6bc..8a636c56643 100644
--- a/src/frame.h
+++ b/src/frame.h
@@ -1682,6 +1682,31 @@ IMAGE_OPT_FROM_ID (struct frame *f, int id)
   eassume (0 <= used);
   return 0 <= id && id < used ? FRAME_IMAGE_CACHE (f)->images[id] : NULL;
 }
+
+/* Abort if C is non-NULL and C's `refcount' field disagrees with the
+   number of frames holding references to the same.  */
+
+INLINE void
+verify_image_cache_refcount (struct image_cache *c)
+{
+  int expected;
+  Lisp_Object tail, frame;
+
+  if (c)
+    {
+      expected = 0;
+
+      FOR_EACH_FRAME (tail, frame)
+	{
+	  if (FRAME_IMAGE_CACHE (XFRAME (frame)) == c)
+	    expected++;
+	}
+
+      if (expected != c->refcount)
+	emacs_abort ();
+    }
+}
+
 #endif
 \f
 /***********************************************************************
diff --git a/src/image.c b/src/image.c
index 2945447b962..9387c78408b 100644
--- a/src/image.c
+++ b/src/image.c
@@ -3625,6 +3625,7 @@ cache_image (struct frame *f, struct image *img)
     {
       c = FRAME_IMAGE_CACHE (f) = share_image_cache (f);
       c->refcount++;
+      verify_image_cache_refcount (c);
     }
 
   /* Find a free slot in c->images.  */
diff --git a/src/xfaces.c b/src/xfaces.c
index 188dd4778bc..ed4d404fbf3 100644
--- a/src/xfaces.c
+++ b/src/xfaces.c
@@ -678,7 +678,10 @@ init_frame_faces (struct frame *f)
   /* Make or share an image cache.  */
   if (FRAME_WINDOW_P (f))
     {
-      FRAME_IMAGE_CACHE (f) = share_image_cache (f);
+      struct image_cache *c = share_image_cache (f);
+
+      verify_image_cache_refcount (c);
+      FRAME_IMAGE_CACHE (f) = c;
       ++FRAME_IMAGE_CACHE (f)->refcount;
     }
 #endif /* HAVE_WINDOW_SYSTEM */
@@ -709,6 +712,7 @@ free_frame_faces (struct frame *f)
       struct image_cache *image_cache = FRAME_IMAGE_CACHE (f);
       if (image_cache)
 	{
+	  verify_image_cache_refcount (image_cache);
 	  --image_cache->refcount;
 	  if (image_cache->refcount == 0)
 	    free_image_cache (f);

bug#71929: 30.0.60; crash in mark_image_cache

[Sean Whitton]

Hello,

On Sun 07 Jul 2024 at 03:41pm +08, Po Lu wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> This is the initial frame of the daemon.  It is not a GUI frame, and
>> so it should not have a valid image cache.  I guess some change is
>> needed in verify_image_cache_refcount?
>
> Not quite: init_frame_faces is apparently called before the frame is
> entered into Vframe_list, so, likewise, the face cache's reference count
> should be verified before it is incremented.
>
> Sean, please retry with this patch substituted for the previous:

This time it doesn't crash until I open and close a frame, as can be
seen in the backtrace:

 0 in terminate_due_to_signal of emacs.c:442
 1 in emacs_abort of sysdep.c:2391
 2 in verify_image_cache_refcount of /home/spwhitton/src/emacs/primary/src/frame.h:1706
 3 in free_frame_faces of xfaces.c:715
 4 in pgtk_free_frame_resources of pgtkterm.c:443
 5 in pgtk_destroy_window of pgtkterm.c:539
 6 in delete_frame of frame.c:2318
 7 in Fdelete_frame of frame.c:2527
 8 in funcall_subr of eval.c:3163
 9 in exec_byte_code of bytecode.c:812
10 in funcall_lambda of eval.c:3252
11 in funcall_general of eval.c:3044
12 in Ffuncall of eval.c:3093
13 in Ffuncall_interactively of callint.c:250
14 in funcall_subr of eval.c:3184
15 in funcall_general of eval.c:3040
16 in Ffuncall of eval.c:3093
17 in Fcall_interactively of callint.c:789
18 in funcall_subr of eval.c:3165
19 in exec_byte_code of bytecode.c:812
20 in funcall_lambda of eval.c:3252
21 in funcall_general of eval.c:3044
22 in Ffuncall of eval.c:3093
23 in read_char of /home/spwhitton/src/emacs/primary/src/lisp.h:1178
24 in read_key_sequence of keyboard.c:10743
25 in command_loop_1 of /home/spwhitton/src/emacs/primary/src/lisp.h:1178
26 in internal_condition_case of eval.c:1613
27 in command_loop_2 of keyboard.c:1168
28 in internal_catch of eval.c:1292
29 in command_loop of /home/spwhitton/src/emacs/primary/src/lisp.h:1178
30 in recursive_edit_1 of keyboard.c:754
31 in Frecursive_edit of keyboard.c:837
32 in main of emacs.c:2631

(gdb) p expected
$3 = 0
(gdb) p c
$4 = (struct image_cache *) 0x555557f65370
(gdb) p c->refcount
$5 = 1
(gdb) set $cons = Vframe_list
(gdb) while $cons
 >xgetptr $cons
 >p ((struct Lisp_Cons *) $ptr)->u.s.car
 >xframe
 >p *$
 >xgetptr $cons
 >set $cons = ((struct Lisp_Cons *) $ptr)->u.s.u.cdr
 >end
$6 = XIL(0x555555f3dfd5)
$7 = (struct frame *) 0x555555f3dfd0
"F1"
$8 = {
  header = {
    size = 4611686018595352602
  },
  name = XIL(0x55555587c944),
  icon_name = XIL(0),
  title = XIL(0),
  parent_frame = XIL(0),
  last_mouse_device = XIL(0),
  focus_frame = XIL(0),
  root_window = XIL(0x555555f3e225),
  selected_window = XIL(0x555555f3e225),
  old_selected_window = XIL(0x555555f3e225),
  minibuffer_window = XIL(0x555555f3e4cd),
  param_alist = XIL(0x555557a23c73),
  scroll_bars = XIL(0),
  condemned_scroll_bars = XIL(0),
  menu_bar_items = XIL(0x555558f8b705),
  face_hash_table = XIL(0x555555f3e775),
  menu_bar_vector = XIL(0),
  buffer_predicate = XIL(0),
  buffer_list = XIL(0x55555934f053),
  buried_buffer_list = XIL(0),
  tab_bar_window = XIL(0),
  desired_tab_bar_string = XIL(0),
  current_tab_bar_string = XIL(0),
  tool_bar_position = XIL(0x11d00),
  font_data = XIL(0),
  tab_bar_items = XIL(0),
  tool_bar_items = XIL(0),
  face_cache = 0x555555f741d0,
  image_cache = 0x0,
  last_tab_bar_item = -1,
  menu_bar_items_used = 0,
  current_pool = 0x555555f3f4b0,
  desired_pool = 0x555555f3f490,
  desired_matrix = 0x555555f3f4d0,
  current_matrix = 0x555555f3f740,
  glyphs_initialized_p = true,
  resized_p = false,
  default_face_done_p = false,
  already_hscrolled_p = false,
  updated_p = false,
  minimize_tab_bar_window_p = false,
  external_tool_bar = false,
  fonts_changed = false,
  cursor_type_changed = false,
  redisplay = true,
  external_menu_bar = false,
  visible = 1,
  iconified = false,
  garbaged = false,
  wants_modeline = true,
  auto_raise = false,
  auto_lower = false,
  no_split = false,
  explicit_name = false,
  window_change = false,
  window_state_change = false,
  mouse_moved = false,
  pointer_invisible = false,
  frozen_window_starts = false,
  output_method = output_initial,
  tooltip = false,
  want_fullscreen = FULLSCREEN_NONE,
  vertical_scroll_bar_type = vertical_scroll_bar_none,
  horizontal_scroll_bars = false,
  undecorated = false,
  override_redirect = false,
  skip_taskbar = false,
  no_focus_on_map = false,
  no_accept_focus = false,
  z_group = z_group_none,
  no_special_glyphs = false,
  can_set_window_size = true,
  after_make_frame = true,
  tab_bar_redisplayed = false,
  tab_bar_resized = false,
  tool_bar_redisplayed = false,
  tool_bar_resized = false,
  inhibit_horizontal_resize = false,
  inhibit_vertical_resize = false,
  face_change = false,
  inhibit_clear_image_cache = false,
  new_size_p = false,
  was_invisible = false,
  select_mini_window_flag = false,
  change_stamp = 7,
  number_of_windows = 2,
  tab_bar_lines = 0,
  tab_bar_height = 0,
  n_tab_bar_rows = 0,
  n_tab_bar_items = 0,
  tool_bar_lines = 0,
  tool_bar_height = 0,
  n_tool_bar_rows = 0,
  n_tool_bar_items = 0,
  decode_mode_spec_buffer = 0x555555f3f340 "",
  insert_line_cost = 0x0,
  delete_line_cost = 0x0,
  insert_n_lines_cost = 0x0,
  delete_n_lines_cost = 0x0,
  text_cols = 80,
  text_lines = 24,
  text_width = 80,
  text_height = 24,
  total_cols = 80,
  total_lines = 25,
  pixel_width = 80,
  pixel_height = 25,
  new_width = -1,
  new_height = -1,
  left_pos = 0,
  top_pos = 0,
  win_gravity = 0,
  size_hint_flags = 0,
  border_width = 0,
  child_frame_border_width = -1,
  internal_border_width = 0,
  right_divider_width = 0,
  bottom_divider_width = 0,
  left_fringe_width = 0,
  right_fringe_width = 0,
  fringe_cols = 0,
  menu_bar_lines = 1,
  menu_bar_height = 1,
  column_width = 1,
  line_height = 1,
  terminal = 0x555555f3ddb0,
  output_data = {
    tty = 0x0,
    x = 0x0,
    w32 = 0x0,
    ns = 0x0,
    pgtk = 0x0,
    haiku = 0x0,
    android = 0x0
  },
  font_driver_list = 0x0,
  desired_cursor = FILLED_BOX_CURSOR,
  cursor_width = 0,
  blink_off_cursor = FILLED_BOX_CURSOR,
  blink_off_cursor_width = 0,
  config_scroll_bar_width = 0,
  config_scroll_bar_cols = 0,
  config_scroll_bar_height = 0,
  config_scroll_bar_lines = 0,
  cost_calculation_baud_rate = 0,
  alpha = {0, 0},
  alpha_background = 0,
  gamma = 0,
  extra_line_spacing = 0,
  background_pixel = 18446744073709551613,
  foreground_pixel = 18446744073709551614
}

-- 
Sean Whitton

bug#71929: 30.0.60; crash in mark_image_cache

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Sean Whitton <spwhitton@spwhitton.name> writes:

> Hello,
>
> On Sun 07 Jul 2024 at 03:41pm +08, Po Lu wrote:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>> This is the initial frame of the daemon.  It is not a GUI frame, and
>>> so it should not have a valid image cache.  I guess some change is
>>> needed in verify_image_cache_refcount?
>>
>> Not quite: init_frame_faces is apparently called before the frame is
>> entered into Vframe_list, so, likewise, the face cache's reference count
>> should be verified before it is incremented.
>>
>> Sean, please retry with this patch substituted for the previous:
>
> This time it doesn't crash until I open and close a frame, as can be
> seen in the backtrace:

I must ask you to bear with me again, as another detail was not
correctly accounted for in the last patch.  Please retry with this:

diff --git a/src/frame.c b/src/frame.c
index 7f4bf274ad9..9793b9f5cbe 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -4831,14 +4831,20 @@ gui_set_font (struct frame *f, Lisp_Object arg, Lisp_Object oldval)
 	  /* Clean F's image cache of images whose values are derived
 	     from the font width.  */
 	  clear_image_cache (f, Qauto);
+	  verify_image_cache_refcount (FRAME_IMAGE_CACHE (f));
 	}
       else
 	{
+	  struct image_cache *old_cache = FRAME_IMAGE_CACHE (f);
+
 	  /* Release the current image cache, and reuse or allocate a
 	     new image cache with IWIDTH.  */
 	  FRAME_IMAGE_CACHE (f)->refcount--;
+	  FRAME_IMAGE_CACHE (f) = NULL;
+	  verify_image_cache_refcount (old_cache);
 	  FRAME_IMAGE_CACHE (f) = share_image_cache (f);
 	  FRAME_IMAGE_CACHE (f)->refcount++;
+	  verify_image_cache_refcount (FRAME_IMAGE_CACHE (f));
 	}
     }
 
diff --git a/src/frame.h b/src/frame.h
index 1d920d1a6bc..8a636c56643 100644
--- a/src/frame.h
+++ b/src/frame.h
@@ -1682,6 +1682,31 @@ IMAGE_OPT_FROM_ID (struct frame *f, int id)
   eassume (0 <= used);
   return 0 <= id && id < used ? FRAME_IMAGE_CACHE (f)->images[id] : NULL;
 }
+
+/* Abort if C is non-NULL and C's `refcount' field disagrees with the
+   number of frames holding references to the same.  */
+
+INLINE void
+verify_image_cache_refcount (struct image_cache *c)
+{
+  int expected;
+  Lisp_Object tail, frame;
+
+  if (c)
+    {
+      expected = 0;
+
+      FOR_EACH_FRAME (tail, frame)
+	{
+	  if (FRAME_IMAGE_CACHE (XFRAME (frame)) == c)
+	    expected++;
+	}
+
+      if (expected != c->refcount)
+	emacs_abort ();
+    }
+}
+
 #endif
 \f
 /***********************************************************************
diff --git a/src/image.c b/src/image.c
index 2945447b962..9387c78408b 100644
--- a/src/image.c
+++ b/src/image.c
@@ -3625,6 +3625,7 @@ cache_image (struct frame *f, struct image *img)
     {
       c = FRAME_IMAGE_CACHE (f) = share_image_cache (f);
       c->refcount++;
+      verify_image_cache_refcount (c);
     }
 
   /* Find a free slot in c->images.  */
diff --git a/src/xfaces.c b/src/xfaces.c
index 188dd4778bc..372c36634d1 100644
--- a/src/xfaces.c
+++ b/src/xfaces.c
@@ -678,7 +678,10 @@ init_frame_faces (struct frame *f)
   /* Make or share an image cache.  */
   if (FRAME_WINDOW_P (f))
     {
-      FRAME_IMAGE_CACHE (f) = share_image_cache (f);
+      struct image_cache *c = share_image_cache (f);
+
+      verify_image_cache_refcount (c);
+      FRAME_IMAGE_CACHE (f) = c;
       ++FRAME_IMAGE_CACHE (f)->refcount;
     }
 #endif /* HAVE_WINDOW_SYSTEM */
@@ -710,6 +713,7 @@ free_frame_faces (struct frame *f)
       if (image_cache)
 	{
 	  --image_cache->refcount;
+	  verify_image_cache_refcount (image_cache);
 	  if (image_cache->refcount == 0)
 	    free_image_cache (f);
 	}

bug#71929: 30.0.60; crash in mark_image_cache

[Sean Whitton]

Hello,

On Sun 07 Jul 2024 at 09:47pm +08, Po Lu wrote:

> I must ask you to bear with me again, as another detail was not
> correctly accounted for in the last patch.  Please retry with this:

No problem.  It doesn't crash right away this time, but I'll get back to
you when it does.

-- 
Sean Whitton

bug#71929: 30.0.60; crash in mark_image_cache

[Sean Whitton]

On Sun, Jul 07, 2024 at 09:47:28PM +0800, Po Lu wrote:

> I must ask you to bear with me again, as another detail was not
> correctly accounted for in the last patch.  Please retry with this:

This just crashed.  Apparent trigger was 'emacsclient -t', this time.

verify_image_cache_refcount is not in the backtrace.

I should be able to keep it open in a stable build of Emacs for at least 24h
if you'd like to ask for more.

Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
0x00005555557a21cd in mark_image_cache (c=0x55555672cc50) at image.c:3776
3776		if (c->images[i])

  0 in mark_image_cache of image.c:3776
  1 in mark_frame of alloc.c:7063
  2 in process_mark_stack of alloc.c:7303
  3 in mark_objects of alloc.c:7512
  4 in mark_vectorlike of alloc.c:6891
  5 in mark_frame of alloc.c:7037
  6 in process_mark_stack of alloc.c:7303
  7 in mark_objects of alloc.c:7512
  8 in mark_vectorlike of alloc.c:6891
  9 in mark_window of alloc.c:7072
 10 in process_mark_stack of alloc.c:7307
 11 in mark_object of alloc.c:7504
 12 in mark_char_table of alloc.c:6920
 13 in mark_char_table of alloc.c:6917
 14 in process_mark_stack of alloc.c:7341
 15 in mark_objects of alloc.c:7512
 16 in mark_vectorlike of alloc.c:6891
 17 in mark_buffer of alloc.c:6954
 18 in process_mark_stack of alloc.c:7299
 19 in mark_object of alloc.c:7504
 20 in mark_interval_tree_1 of alloc.c:1529
 21 in traverse_intervals_noorder of intervals.c:243
 22 in traverse_intervals_noorder of intervals.c:248
 23 in mark_interval_tree of alloc.c:1538
 24 in process_mark_stack of alloc.c:7264
 25 in mark_objects of alloc.c:7512
 26 in mark_vectorlike of alloc.c:6891
 27 in mark_buffer of alloc.c:6954
 28 in process_mark_stack of alloc.c:7299
 29 in mark_object of alloc.c:7504
 30 in mark_interval_tree_1 of alloc.c:1529
 31 in traverse_intervals_noorder of intervals.c:243
 32 in mark_interval_tree of alloc.c:1538
 33 in process_mark_stack of alloc.c:7264
 34 in mark_object of alloc.c:7504
 35 in mark_char_table of alloc.c:6920
 36 in mark_char_table of alloc.c:6917
 37 in process_mark_stack of alloc.c:7341
 38 in mark_objects of alloc.c:7512
 39 in mark_vectorlike of alloc.c:6891
 40 in mark_buffer of alloc.c:6954
 41 in process_mark_stack of alloc.c:7299
 42 in mark_object of alloc.c:7504
 43 in mark_char_table of alloc.c:6920
 44 in mark_char_table of alloc.c:6917
 45 in process_mark_stack of alloc.c:7341
 46 in mark_object of alloc.c:7504
 47 in mark_char_table of alloc.c:6920
 48 in mark_char_table of alloc.c:6917
 49 in process_mark_stack of alloc.c:7341
 50 in mark_object of alloc.c:7504
 51 in mark_char_table of alloc.c:6920
 52 in mark_char_table of alloc.c:6917
 53 in process_mark_stack of alloc.c:7341
 54 in mark_objects of alloc.c:7512
 55 in mark_vectorlike of alloc.c:6891
 56 in mark_buffer of alloc.c:6954
 57 in process_mark_stack of alloc.c:7299
 58 in mark_object of alloc.c:7504
 59 in mark_char_table of alloc.c:6920
 60 in mark_char_table of alloc.c:6917
 61 in process_mark_stack of alloc.c:7341
 62 in mark_objects of alloc.c:7512
 63 in mark_vectorlike of alloc.c:6891
 64 in mark_buffer of alloc.c:6954
 65 in process_mark_stack of alloc.c:7299
 66 in mark_objects of alloc.c:7512
 67 in mark_vectorlike of alloc.c:6891
 68 in mark_buffer of alloc.c:6954
 69 in process_mark_stack of alloc.c:7299
 70 in mark_object of alloc.c:7504
 71 in mark_char_table of alloc.c:6920
 72 in mark_char_table of alloc.c:6917
 73 in process_mark_stack of alloc.c:7341
 74 in mark_objects of alloc.c:7512
 75 in mark_vectorlike of alloc.c:6891
 76 in mark_buffer of alloc.c:6954
 77 in process_mark_stack of alloc.c:7299
 78 in mark_objects of alloc.c:7512
 79 in mark_vectorlike of alloc.c:6891
 80 in mark_window of alloc.c:7072
 81 in process_mark_stack of alloc.c:7307
 82 in mark_objects of alloc.c:7512
 83 in mark_vectorlike of alloc.c:6891
 84 in mark_frame of alloc.c:7037
 85 in process_mark_stack of alloc.c:7303
 86 in mark_objects of alloc.c:7512
 87 in mark_vectorlike of alloc.c:6891
 88 in mark_window of alloc.c:7072
 89 in process_mark_stack of alloc.c:7307
 90 in mark_objects of alloc.c:7512
 91 in mark_vectorlike of alloc.c:6891
 92 in mark_buffer of alloc.c:6954
 93 in process_mark_stack of alloc.c:7299
 94 in mark_objects of alloc.c:7512
 95 in mark_vectorlike of alloc.c:6891
 96 in mark_buffer of alloc.c:6954
 97 in process_mark_stack of alloc.c:7299
 98 in mark_objects of alloc.c:7512
 99 in mark_vectorlike of alloc.c:6891
100 in mark_buffer of alloc.c:6954
101 in process_mark_stack of alloc.c:7299
102 in mark_object of alloc.c:7504
103 in mark_interval_tree_1 of alloc.c:1529
104 in traverse_intervals_noorder of intervals.c:243
105 in mark_interval_tree of alloc.c:1538
106 in process_mark_stack of alloc.c:7264
107 in mark_objects of alloc.c:7512
108 in mark_vectorlike of alloc.c:6891
109 in mark_buffer of alloc.c:6954
110 in process_mark_stack of alloc.c:7299
111 in mark_object of alloc.c:7504
112 in mark_interval_tree_1 of alloc.c:1529
113 in traverse_intervals_noorder of intervals.c:243
114 in mark_interval_tree of alloc.c:1538
115 in process_mark_stack of alloc.c:7264
116 in mark_objects of alloc.c:7512
117 in mark_vectorlike of alloc.c:6891
118 in mark_buffer of alloc.c:6954
119 in process_mark_stack of alloc.c:7299
120 in mark_objects of alloc.c:7512
121 in mark_vectorlike of alloc.c:6891
122 in mark_buffer of alloc.c:6954
123 in process_mark_stack of alloc.c:7299
124 in mark_object of alloc.c:7504
125 in mark_interval_tree_1 of alloc.c:1529
126 in traverse_intervals_noorder of intervals.c:243
127 in mark_interval_tree of alloc.c:1538
128 in process_mark_stack of alloc.c:7264
129 in mark_objects of alloc.c:7512
130 in mark_vectorlike of alloc.c:6891
131 in mark_buffer of alloc.c:6954
132 in process_mark_stack of alloc.c:7299
133 in mark_object of alloc.c:7504
134 in mark_char_table of alloc.c:6920
135 in process_mark_stack of alloc.c:7341
136 in mark_object of alloc.c:7504
137 in mark_char_table of alloc.c:6920
138 in process_mark_stack of alloc.c:7341
139 in mark_object of alloc.c:7504
140 in mark_char_table of alloc.c:6920
141 in process_mark_stack of alloc.c:7341
142 in mark_object of alloc.c:7504
143 in mark_char_table of alloc.c:6920
144 in process_mark_stack of alloc.c:7341
145 in mark_objects of alloc.c:7512
146 in mark_vectorlike of alloc.c:6891
147 in mark_buffer of alloc.c:6954
148 in process_mark_stack of alloc.c:7299
149 in mark_objects of alloc.c:7512
150 in mark_vectorlike of alloc.c:6891
151 in mark_buffer of alloc.c:6954
152 in process_mark_stack of alloc.c:7299
153 in mark_objects of alloc.c:7512
154 in mark_vectorlike of alloc.c:6891
155 in mark_buffer of alloc.c:6954
156 in process_mark_stack of alloc.c:7299
157 in mark_objects of alloc.c:7512
158 in mark_vectorlike of alloc.c:6891
159 in mark_buffer of alloc.c:6954
160 in process_mark_stack of alloc.c:7299
161 in mark_objects of alloc.c:7512
162 in mark_vectorlike of alloc.c:6891
163 in mark_buffer of alloc.c:6954
164 in process_mark_stack of alloc.c:7299
165 in mark_object of alloc.c:7504
166 in mark_object_root_visitor of alloc.c:6396
167 in visit_vectorlike_root of alloc.c:6348
168 in visit_buffer_root of alloc.c:6362
169 in visit_static_gc_roots of alloc.c:6374
170 in garbage_collect of alloc.c:6598
171 in maybe_garbage_collect of alloc.c:6507
172 in maybe_gc of /home/spwhitton/src/emacs/primary/src/lisp.h:5929
173 in Ffuncall of eval.c:3088
174 in Fmaphash of fns.c:5974
175 in funcall_subr of eval.c:3163
176 in exec_byte_code of bytecode.c:812
177 in funcall_lambda of eval.c:3252
178 in funcall_general of eval.c:3044
179 in Ffuncall of eval.c:3093
180 in Fapply of eval.c:2722
181 in funcall_subr of eval.c:3184
182 in exec_byte_code of bytecode.c:812
183 in funcall_lambda of eval.c:3252
184 in funcall_general of eval.c:3044
185 in Ffuncall of eval.c:3093
186 in Fapply of eval.c:2765
187 in apply1 of eval.c:2981
188 in read_process_output_call of process.c:6129
189 in internal_condition_case_1 of eval.c:1637
190 in read_and_dispose_of_process_output of process.c:6498
191 in read_process_output of process.c:6266
192 in wait_reading_process_output of process.c:5947
193 in sit_for of dispnew.c:6335
194 in read_char of keyboard.c:2923
195 in read_key_sequence of keyboard.c:10743
196 in command_loop_1 of /home/spwhitton/src/emacs/primary/src/lisp.h:1178
197 in internal_condition_case of eval.c:1613
198 in command_loop_2 of keyboard.c:1168
199 in internal_catch of eval.c:1292
200 in command_loop of /home/spwhitton/src/emacs/primary/src/lisp.h:1178
201 in recursive_edit_1 of keyboard.c:754
202 in Frecursive_edit of keyboard.c:837
203 in main of emacs.c:2631

-- 
Sean Whitton

bug#71929: 30.0.60; crash in mark_image_cache

[Eli Zaretskii]

> Date: Tue, 9 Jul 2024 13:48:32 +0800
> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: 71929@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> 
> On Sun, Jul 07, 2024 at 09:47:28PM +0800, Po Lu wrote:
> 
> > I must ask you to bear with me again, as another detail was not
> > correctly accounted for in the last patch.  Please retry with this:
> 
> This just crashed.  Apparent trigger was 'emacsclient -t', this time.
> 
> verify_image_cache_refcount is not in the backtrace.
> 
> I should be able to keep it open in a stable build of Emacs for at least 24h
> if you'd like to ask for more.

Thanks.  How many frames, approximately, were alive in this session
when it crashed?

bug#71929: 30.0.60; crash in mark_image_cache

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Sean Whitton <spwhitton@spwhitton.name> writes:

> On Sun, Jul 07, 2024 at 09:47:28PM +0800, Po Lu wrote:
>
>> I must ask you to bear with me again, as another detail was not
>> correctly accounted for in the last patch.  Please retry with this:
>
> This just crashed.  Apparent trigger was 'emacsclient -t', this time.
>
> verify_image_cache_refcount is not in the backtrace.
>
> I should be able to keep it open in a stable build of Emacs for at least 24h
> if you'd like to ask for more.
>
> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
> 0x00005555557a21cd in mark_image_cache (c=0x55555672cc50) at image.c:3776
> 3776		if (c->images[i])

And this is a segmentation fault, not a trap.  Can you establish when
the frame in question was created, how and where it received its current
image cache, and whether this frame exists in Vframe_list?

If the answer to the final question is no, can anyone surmise how it is
that a live frame's image cache might be prematurely deleted without its
references being detected by verify_image_cache_refcount?

bug#71929: 30.0.60; crash in mark_image_cache

[Sean Whitton]

On Tue, Jul 09, 2024 at 08:13:28PM +0800, Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote:
> Sean Whitton <spwhitton@spwhitton.name> writes:
> 
> > On Sun, Jul 07, 2024 at 09:47:28PM +0800, Po Lu wrote:
> >
> >> I must ask you to bear with me again, as another detail was not
> >> correctly accounted for in the last patch.  Please retry with this:
> >
> > This just crashed.  Apparent trigger was 'emacsclient -t', this time.
> >
> > verify_image_cache_refcount is not in the backtrace.
> >
> > I should be able to keep it open in a stable build of Emacs for at least 24h
> > if you'd like to ask for more.
> >
> > Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
> > 0x00005555557a21cd in mark_image_cache (c=0x55555672cc50) at image.c:3776
> > 3776		if (c->images[i])
> 
> And this is a segmentation fault, not a trap.  Can you establish when
> the frame in question was created, how and where it received its current
> image cache, and whether this frame exists in Vframe_list?

I'm afraid I'm not familiar with any of these data structures.  I don't know
what these image caches are.

In the mark_frame stack frame I did "p f" to obtain the address
0x555559f61330.  I then did the "while $cons" thing you posted in another
message, and searched its output for this address, and it is not present.

So perhaps this means the frame is not present in Vframe_list.



-- 
Sean Whitton

bug#71929: 30.0.60; crash in mark_image_cache

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Sean Whitton <spwhitton@spwhitton.name> writes:

> On Tue, Jul 09, 2024 at 08:13:28PM +0800, Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote:
>> Sean Whitton <spwhitton@spwhitton.name> writes:
>> 
>> > On Sun, Jul 07, 2024 at 09:47:28PM +0800, Po Lu wrote:
>> >
>> >> I must ask you to bear with me again, as another detail was not
>> >> correctly accounted for in the last patch.  Please retry with this:
>> >
>> > This just crashed.  Apparent trigger was 'emacsclient -t', this time.
>> >
>> > verify_image_cache_refcount is not in the backtrace.
>> >
>> > I should be able to keep it open in a stable build of Emacs for at least 24h
>> > if you'd like to ask for more.
>> >
>> > Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
>> > 0x00005555557a21cd in mark_image_cache (c=0x55555672cc50) at image.c:3776
>> > 3776		if (c->images[i])
>> 
>> And this is a segmentation fault, not a trap.  Can you establish when
>> the frame in question was created, how and where it received its current
>> image cache, and whether this frame exists in Vframe_list?
>
> I'm afraid I'm not familiar with any of these data structures.  I don't know
> what these image caches are.
>
> In the mark_frame stack frame I did "p f" to obtain the address
> 0x555559f61330.  I then did the "while $cons" thing you posted in another
> message, and searched its output for this address, and it is not present.
>
> So perhaps this means the frame is not present in Vframe_list.

OK, I believe I understand the source of these crashes.  A frame whose
image cache is shared among several frames is destroyed, but its
`image_cache' field is never cleared after it is destroyed, as its cache
continues to be referenced, and, if references to the dead frame remain,
GC attempts to mark the said image cache although its validity is no
longer guaranteed.  In earlier Emacs versions, this problem would have
appeared if references to dead frames were preserved beyond the
destruction of a display structure.  This has been corrected on the
emacs-30 branch, and therefore if the crashes do not resurface in a few
days, I will close this ticket.

Thanks.

bug#71929: 30.0.60; crash in mark_image_cache

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: 71929@debbugs.gnu.org,  Eli Zaretskii <eliz@gnu.org>
> Date: Tue, 09 Jul 2024 22:03:34 +0800
> 
> OK, I believe I understand the source of these crashes.  A frame whose
> image cache is shared among several frames is destroyed, but its
> `image_cache' field is never cleared after it is destroyed, as its cache
> continues to be referenced, and, if references to the dead frame remain,
> GC attempts to mark the said image cache although its validity is no
> longer guaranteed.  In earlier Emacs versions, this problem would have
> appeared if references to dead frames were preserved beyond the
> destruction of a display structure.  This has been corrected on the
> emacs-30 branch, and therefore if the crashes do not resurface in a few
> days, I will close this ticket.

Thanks, but I don't think I understand this part of the change you
installed:

  --- a/src/image.c
  +++ b/src/image.c
  @@ -2304,23 +2304,18 @@ uncache_image (struct frame *f, Lisp_Object spec)
   free_image_cache (struct frame *f)
   {
     struct image_cache *c = FRAME_IMAGE_CACHE (f);
  -  if (c)
  -    {
  -      ptrdiff_t i;
  +  ptrdiff_t i;

  -      /* Cache should not be referenced by any frame when freed.  */
  -      eassert (c->refcount == 0);
  +  /* Cache should not be referenced by any frame when freed.  */
  +  eassert (c->refcount == 0);

  -      for (i = 0; i < c->used; ++i)
  -       free_image (f, c->images[i]);
  -      xfree (c->images);
  -      xfree (c->buckets);
  -      xfree (c);
  -      FRAME_IMAGE_CACHE (f) = NULL;
  -    }
  +  for (i = 0; i < c->used; ++i)
  +    free_image (f, c->images[i]);
  +  xfree (c->images);
  +  xfree (c->buckets);
  +  xfree (c);
   }

This basically removes the test of 'c' being non-NULL, leaving the
rest of the code unchanged.  But if 'c' is NULL, dereferencing it in
the following code will segfault, so why remove the test?  In
particular, what about frames that were not yet allocated the image
cache (could this happen with TTY frames, for example)?

What am I missing here?

bug#71929: 30.0.60; crash in mark_image_cache

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: 71929@debbugs.gnu.org,  Eli Zaretskii <eliz@gnu.org>
>> Date: Tue, 09 Jul 2024 22:03:34 +0800
>> 
>> OK, I believe I understand the source of these crashes.  A frame
>> whose
>> image cache is shared among several frames is destroyed, but its
>> `image_cache' field is never cleared after it is destroyed, as its
>> cache
>> continues to be referenced, and, if references to the dead frame
>> remain,
>> GC attempts to mark the said image cache although its validity is no
>> longer guaranteed.  In earlier Emacs versions, this problem would
>> have
>> appeared if references to dead frames were preserved beyond the
>> destruction of a display structure.  This has been corrected on the
>> emacs-30 branch, and therefore if the crashes do not resurface in a
>> few
>> days, I will close this ticket.
>
> Thanks, but I don't think I understand this part of the change you
> installed:
>
>   --- a/src/image.c
>   +++ b/src/image.c
>   @@ -2304,23 +2304,18 @@ uncache_image (struct frame *f, Lisp_Object spec)
>    free_image_cache (struct frame *f)
>    {
>      struct image_cache *c = FRAME_IMAGE_CACHE (f);
>   -  if (c)
>   -    {
>   -      ptrdiff_t i;
>   +  ptrdiff_t i;
>
>   -      /* Cache should not be referenced by any frame when freed.  */
>   -      eassert (c->refcount == 0);
>   +  /* Cache should not be referenced by any frame when freed.  */
>   +  eassert (c->refcount == 0);
>
>   -      for (i = 0; i < c->used; ++i)
>   -       free_image (f, c->images[i]);
>   -      xfree (c->images);
>   -      xfree (c->buckets);
>   -      xfree (c);
>   -      FRAME_IMAGE_CACHE (f) = NULL;
>   -    }
>   +  for (i = 0; i < c->used; ++i)
>   +    free_image (f, c->images[i]);
>   +  xfree (c->images);
>   +  xfree (c->buckets);
>   +  xfree (c);
>    }
>
> This basically removes the test of 'c' being non-NULL, leaving the
> rest of the code unchanged.  But if 'c' is NULL, dereferencing it in
> the following code will segfault, so why remove the test?  In
> particular, what about frames that were not yet allocated the image
> cache (could this happen with TTY frames, for example)?
>
> What am I missing here?

That free_frame_faces has been the sole caller of this function for
quite some time, and it already performs the same test around its call
to free_image_cache.

bug#71929: 30.0.60; crash in mark_image_cache

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: spwhitton@spwhitton.name,  71929@debbugs.gnu.org
> Date: Tue, 09 Jul 2024 23:02:22 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Po Lu <luangruo@yahoo.com>
> >> Cc: 71929@debbugs.gnu.org,  Eli Zaretskii <eliz@gnu.org>
> >> Date: Tue, 09 Jul 2024 22:03:34 +0800
> >> 
> >> OK, I believe I understand the source of these crashes.  A frame
> >> whose
> >> image cache is shared among several frames is destroyed, but its
> >> `image_cache' field is never cleared after it is destroyed, as its
> >> cache
> >> continues to be referenced, and, if references to the dead frame
> >> remain,
> >> GC attempts to mark the said image cache although its validity is no
> >> longer guaranteed.  In earlier Emacs versions, this problem would
> >> have
> >> appeared if references to dead frames were preserved beyond the
> >> destruction of a display structure.  This has been corrected on the
> >> emacs-30 branch, and therefore if the crashes do not resurface in a
> >> few
> >> days, I will close this ticket.
> >
> > Thanks, but I don't think I understand this part of the change you
> > installed:
> >
> >   --- a/src/image.c
> >   +++ b/src/image.c
> >   @@ -2304,23 +2304,18 @@ uncache_image (struct frame *f, Lisp_Object spec)
> >    free_image_cache (struct frame *f)
> >    {
> >      struct image_cache *c = FRAME_IMAGE_CACHE (f);
> >   -  if (c)
> >   -    {
> >   -      ptrdiff_t i;
> >   +  ptrdiff_t i;
> >
> >   -      /* Cache should not be referenced by any frame when freed.  */
> >   -      eassert (c->refcount == 0);
> >   +  /* Cache should not be referenced by any frame when freed.  */
> >   +  eassert (c->refcount == 0);
> >
> >   -      for (i = 0; i < c->used; ++i)
> >   -       free_image (f, c->images[i]);
> >   -      xfree (c->images);
> >   -      xfree (c->buckets);
> >   -      xfree (c);
> >   -      FRAME_IMAGE_CACHE (f) = NULL;
> >   -    }
> >   +  for (i = 0; i < c->used; ++i)
> >   +    free_image (f, c->images[i]);
> >   +  xfree (c->images);
> >   +  xfree (c->buckets);
> >   +  xfree (c);
> >    }
> >
> > This basically removes the test of 'c' being non-NULL, leaving the
> > rest of the code unchanged.  But if 'c' is NULL, dereferencing it in
> > the following code will segfault, so why remove the test?  In
> > particular, what about frames that were not yet allocated the image
> > cache (could this happen with TTY frames, for example)?
> >
> > What am I missing here?
> 
> That free_frame_faces has been the sole caller of this function for
> quite some time, and it already performs the same test around its call
> to free_image_cache.

Such dependencies are not a good idea, IME, for public (non-static)
functions, if at all, not in the long run.  At the very least, please
add an assertion at entry to the function which verifies that the
cache is not NULL.  That will at least serve as prominent
documentation of the function's contract.

bug#71929: 30.0.60; crash in mark_image_cache

[Sean Whitton]

Hello,

On Tue 09 Jul 2024 at 02:37pm +03, Eli Zaretskii wrote:

>> Date: Tue, 9 Jul 2024 13:48:32 +0800
>> From: Sean Whitton <spwhitton@spwhitton.name>
>> Cc: 71929@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
>>
>> On Sun, Jul 07, 2024 at 09:47:28PM +0800, Po Lu wrote:
>>
>> > I must ask you to bear with me again, as another detail was not
>> > correctly accounted for in the last patch.  Please retry with this:
>>
>> This just crashed.  Apparent trigger was 'emacsclient -t', this time.
>>
>> verify_image_cache_refcount is not in the backtrace.
>>
>> I should be able to keep it open in a stable build of Emacs for at least 24h
>> if you'd like to ask for more.
>
> Thanks.  How many frames, approximately, were alive in this session
> when it crashed?

Sorry I missed replying to this.  I think there were three or four.

-- 
Sean Whitton

bug#71929: 30.0.60; crash in mark_image_cache

[Sean Whitton]

Hello,

On Tue 09 Jul 2024 at 10:03pm +08, Po Lu wrote:

> OK, I believe I understand the source of these crashes.  A frame whose
> image cache is shared among several frames is destroyed, but its
> `image_cache' field is never cleared after it is destroyed, as its cache
> continues to be referenced, and, if references to the dead frame remain,
> GC attempts to mark the said image cache although its validity is no
> longer guaranteed.  In earlier Emacs versions, this problem would have
> appeared if references to dead frames were preserved beyond the
> destruction of a display structure.  This has been corrected on the
> emacs-30 branch, and therefore if the crashes do not resurface in a few
> days, I will close this ticket.

Thanks for the fix, running it now.

-- 
Sean Whitton

bug#71929: 30.0.60; crash in mark_image_cache

[Basil L. Contovounesios]

FWIW I can no longer get master to crash.

Previously (few weeks ago) I could fairly reliably get a crash by
closing the last remaining graphical emacsclient frame.

This happens often in my typical workflow where EDITOR is effectively
'emacsclient -c' and pop-up-frames is non-nil, so frames are constantly
being created and then all deleted.

Thanks for fixing this,
-- 
Basil

bug#71929: 30.0.60; crash in mark_image_cache

[Eli Zaretskii]

> From: "Basil L. Contovounesios" <basil@contovou.net>
> Cc: Po Lu <luangruo@yahoo.com>,  71929@debbugs.gnu.org,  Eli Zaretskii
>  <eliz@gnu.org>
> Date: Wed, 24 Jul 2024 15:31:03 +0200
> 
> FWIW I can no longer get master to crash.
> 
> Previously (few weeks ago) I could fairly reliably get a crash by
> closing the last remaining graphical emacsclient frame.
> 
> This happens often in my typical workflow where EDITOR is effectively
> 'emacsclient -c' and pop-up-frames is non-nil, so frames are constantly
> being created and then all deleted.
> 
> Thanks for fixing this,

Thanks for telling us.  I think we should close this bug now (and
reopen if it turns out it was not fixed).

bug#71929: 30.0.60; crash in mark_image_cache

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Basil L. Contovounesios" <basil@contovou.net>
>> Cc: Po Lu <luangruo@yahoo.com>,  71929@debbugs.gnu.org,  Eli Zaretskii
>>  <eliz@gnu.org>
>> Date: Wed, 24 Jul 2024 15:31:03 +0200
>> 
>> FWIW I can no longer get master to crash.
>> 
>> Previously (few weeks ago) I could fairly reliably get a crash by
>> closing the last remaining graphical emacsclient frame.
>> 
>> This happens often in my typical workflow where EDITOR is effectively
>> 'emacsclient -c' and pop-up-frames is non-nil, so frames are constantly
>> being created and then all deleted.
>> 
>> Thanks for fixing this,
>
> Thanks for telling us.  I think we should close this bug now (and
> reopen if it turns out it was not fixed).

I agree, now done.