* bug#71929: 30.0.60; crash in mark_image_cache @ 2024-07-04 2:33 Sean Whitton 2024-07-04 2:44 ` Sean Whitton 0 siblings, 1 reply; 48+ messages in thread From: Sean Whitton @ 2024-07-04 2:33 UTC (permalink / raw) To: 71929 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-04 2:33 bug#71929: 30.0.60; crash in mark_image_cache Sean Whitton @ 2024-07-04 2:44 ` Sean Whitton 2024-07-04 5:53 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Sean Whitton @ 2024-07-04 2:44 UTC (permalink / raw) To: 71929 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-04 2:44 ` Sean Whitton @ 2024-07-04 5:53 ` Eli Zaretskii 2024-07-04 6:03 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2024-07-04 5:53 UTC (permalink / raw) To: Sean Whitton; +Cc: 71929 > 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? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-04 5:53 ` Eli Zaretskii @ 2024-07-04 6:03 ` Eli Zaretskii 2024-07-04 6:17 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-05 0:13 ` Sean Whitton 0 siblings, 2 replies; 48+ messages in thread From: Eli Zaretskii @ 2024-07-04 6:03 UTC (permalink / raw) To: spwhitton; +Cc: Po Lu, 71929 > 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? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-04 6:03 ` Eli Zaretskii @ 2024-07-04 6:17 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-04 6:42 ` Sean Whitton 2024-07-05 0:13 ` Sean Whitton 1 sibling, 1 reply; 48+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-04 6:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 71929, spwhitton 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-04 6:17 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-04 6:42 ` Sean Whitton 2024-07-04 6:59 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-04 7:40 ` Eli Zaretskii 0 siblings, 2 replies; 48+ messages in thread From: Sean Whitton @ 2024-07-04 6:42 UTC (permalink / raw) To: Po Lu, Eli Zaretskii; +Cc: 71929 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-04 6:42 ` Sean Whitton @ 2024-07-04 6:59 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-04 9:56 ` Sean Whitton 2024-07-04 7:40 ` Eli Zaretskii 1 sibling, 1 reply; 48+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-04 6:59 UTC (permalink / raw) To: Sean Whitton; +Cc: 71929, Eli Zaretskii 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? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-04 6:59 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-04 9:56 ` Sean Whitton 2024-07-04 12:28 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 48+ messages in thread From: Sean Whitton @ 2024-07-04 9:56 UTC (permalink / raw) To: Po Lu; +Cc: 71929, Eli Zaretskii 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-04 9:56 ` Sean Whitton @ 2024-07-04 12:28 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-05 7:52 ` Sean Whitton 0 siblings, 1 reply; 48+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-04 12:28 UTC (permalink / raw) To: Sean Whitton; +Cc: 71929, Eli Zaretskii 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-04 12:28 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-05 7:52 ` Sean Whitton 0 siblings, 0 replies; 48+ messages in thread From: Sean Whitton @ 2024-07-05 7:52 UTC (permalink / raw) To: Po Lu; +Cc: 71929, Eli Zaretskii 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-04 6:42 ` Sean Whitton 2024-07-04 6:59 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-04 7:40 ` Eli Zaretskii 2024-07-04 9:57 ` Sean Whitton 1 sibling, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2024-07-04 7:40 UTC (permalink / raw) To: Sean Whitton; +Cc: luangruo, 71929 > 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-04 7:40 ` Eli Zaretskii @ 2024-07-04 9:57 ` Sean Whitton 2024-07-04 12:48 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Sean Whitton @ 2024-07-04 9:57 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, 71929 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-04 9:57 ` Sean Whitton @ 2024-07-04 12:48 ` Eli Zaretskii 0 siblings, 0 replies; 48+ messages in thread From: Eli Zaretskii @ 2024-07-04 12:48 UTC (permalink / raw) To: Sean Whitton; +Cc: luangruo, 71929 > 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-04 6:03 ` Eli Zaretskii 2024-07-04 6:17 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-05 0:13 ` Sean Whitton 2024-07-05 6:27 ` Eli Zaretskii 1 sibling, 1 reply; 48+ messages in thread From: Sean Whitton @ 2024-07-05 0:13 UTC (permalink / raw) To: Eli Zaretskii, Po Lu; +Cc: 71929 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-05 0:13 ` Sean Whitton @ 2024-07-05 6:27 ` Eli Zaretskii 2024-07-05 6:41 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2024-07-05 6:27 UTC (permalink / raw) To: Sean Whitton; +Cc: luangruo, 71929 > 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? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-05 6:27 ` Eli Zaretskii @ 2024-07-05 6:41 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-05 7:37 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-05 6:41 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 71929, Sean Whitton 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++; } } ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-05 6:41 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-05 7:37 ` Eli Zaretskii 2024-07-05 9:36 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2024-07-05 7:37 UTC (permalink / raw) To: Po Lu; +Cc: 71929, spwhitton > 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? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-05 7:37 ` Eli Zaretskii @ 2024-07-05 9:36 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-05 11:10 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-05 9:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 71929, spwhitton 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-05 9:36 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-05 11:10 ` Eli Zaretskii 2024-07-05 11:40 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2024-07-05 11:10 UTC (permalink / raw) To: Po Lu; +Cc: 71929, spwhitton > 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-05 11:10 ` Eli Zaretskii @ 2024-07-05 11:40 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-05 12:46 ` Sean Whitton 2024-07-06 2:41 ` Sean Whitton 0 siblings, 2 replies; 48+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-05 11:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 71929, spwhitton 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-05 11:40 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-05 12:46 ` Sean Whitton 2024-07-06 2:41 ` Sean Whitton 1 sibling, 0 replies; 48+ messages in thread From: Sean Whitton @ 2024-07-05 12:46 UTC (permalink / raw) To: Po Lu; +Cc: 71929, Eli Zaretskii 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-05 11:40 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-05 12:46 ` Sean Whitton @ 2024-07-06 2:41 ` Sean Whitton 2024-07-06 6:08 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-06 6:40 ` Eli Zaretskii 1 sibling, 2 replies; 48+ messages in thread From: Sean Whitton @ 2024-07-06 2:41 UTC (permalink / raw) To: Po Lu; +Cc: 71929, Eli Zaretskii 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-06 2:41 ` Sean Whitton @ 2024-07-06 6:08 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-07 2:40 ` Sean Whitton 2024-07-07 2:43 ` Sean Whitton 2024-07-06 6:40 ` Eli Zaretskii 1 sibling, 2 replies; 48+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-06 6:08 UTC (permalink / raw) To: Sean Whitton; +Cc: 71929, Eli Zaretskii 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); ^ permalink raw reply related [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-06 6:08 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-07 2:40 ` Sean Whitton 2024-07-07 2:43 ` Sean Whitton 1 sibling, 0 replies; 48+ messages in thread From: Sean Whitton @ 2024-07-07 2:40 UTC (permalink / raw) To: Po Lu; +Cc: 71929, Eli Zaretskii 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-06 6:08 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-07 2:40 ` Sean Whitton @ 2024-07-07 2:43 ` Sean Whitton 2024-07-07 2:46 ` Sean Whitton 1 sibling, 1 reply; 48+ messages in thread From: Sean Whitton @ 2024-07-07 2:43 UTC (permalink / raw) To: Po Lu; +Cc: 71929, Eli Zaretskii 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-07 2:43 ` Sean Whitton @ 2024-07-07 2:46 ` Sean Whitton 2024-07-07 4:04 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 48+ messages in thread From: Sean Whitton @ 2024-07-07 2:46 UTC (permalink / raw) To: Po Lu; +Cc: 71929, Eli Zaretskii 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-07 2:46 ` Sean Whitton @ 2024-07-07 4:04 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-07 4:54 ` Sean Whitton 0 siblings, 1 reply; 48+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-07 4:04 UTC (permalink / raw) To: Sean Whitton; +Cc: 71929, Eli Zaretskii 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-07 4:04 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-07 4:54 ` Sean Whitton 2024-07-07 7:08 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Sean Whitton @ 2024-07-07 4:54 UTC (permalink / raw) To: Po Lu; +Cc: 71929, Eli Zaretskii 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-07 4:54 ` Sean Whitton @ 2024-07-07 7:08 ` Eli Zaretskii 2024-07-07 7:41 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2024-07-07 7:08 UTC (permalink / raw) To: luangruo, Sean Whitton; +Cc: 71929 > 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? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-07 7:08 ` Eli Zaretskii @ 2024-07-07 7:41 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-07 13:16 ` Sean Whitton 0 siblings, 1 reply; 48+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-07 7:41 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 71929, Sean Whitton 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); ^ permalink raw reply related [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-07 7:41 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-07 13:16 ` Sean Whitton 2024-07-07 13:47 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 48+ messages in thread From: Sean Whitton @ 2024-07-07 13:16 UTC (permalink / raw) To: Po Lu; +Cc: 71929, Eli Zaretskii 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-07 13:16 ` Sean Whitton @ 2024-07-07 13:47 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-07 14:45 ` Sean Whitton 2024-07-09 5:48 ` Sean Whitton 0 siblings, 2 replies; 48+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-07 13:47 UTC (permalink / raw) To: Sean Whitton; +Cc: 71929, Eli Zaretskii 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); } ^ permalink raw reply related [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-07 13:47 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-07 14:45 ` Sean Whitton 2024-07-09 5:48 ` Sean Whitton 1 sibling, 0 replies; 48+ messages in thread From: Sean Whitton @ 2024-07-07 14:45 UTC (permalink / raw) To: Po Lu; +Cc: 71929, Eli Zaretskii 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-07 13:47 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-07 14:45 ` Sean Whitton @ 2024-07-09 5:48 ` Sean Whitton 2024-07-09 11:37 ` Eli Zaretskii 2024-07-09 12:13 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 1 sibling, 2 replies; 48+ messages in thread From: Sean Whitton @ 2024-07-09 5:48 UTC (permalink / raw) To: Po Lu; +Cc: 71929, Eli Zaretskii 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-09 5:48 ` Sean Whitton @ 2024-07-09 11:37 ` Eli Zaretskii 2024-07-10 1:12 ` Sean Whitton 2024-07-09 12:13 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 1 sibling, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2024-07-09 11:37 UTC (permalink / raw) To: Sean Whitton; +Cc: luangruo, 71929 > 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? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-09 11:37 ` Eli Zaretskii @ 2024-07-10 1:12 ` Sean Whitton 0 siblings, 0 replies; 48+ messages in thread From: Sean Whitton @ 2024-07-10 1:12 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, 71929 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-09 5:48 ` Sean Whitton 2024-07-09 11:37 ` Eli Zaretskii @ 2024-07-09 12:13 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-09 13:44 ` Sean Whitton 1 sibling, 1 reply; 48+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-09 12:13 UTC (permalink / raw) To: Sean Whitton; +Cc: 71929, Eli Zaretskii 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? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-09 12:13 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-09 13:44 ` Sean Whitton 2024-07-09 14:03 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 48+ messages in thread From: Sean Whitton @ 2024-07-09 13:44 UTC (permalink / raw) To: Po Lu; +Cc: 71929, Eli Zaretskii 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-09 13:44 ` Sean Whitton @ 2024-07-09 14:03 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-09 14:18 ` Eli Zaretskii 2024-07-10 1:12 ` Sean Whitton 0 siblings, 2 replies; 48+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-09 14:03 UTC (permalink / raw) To: Sean Whitton; +Cc: 71929, Eli Zaretskii 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-09 14:03 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-09 14:18 ` Eli Zaretskii 2024-07-09 15:02 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-10 1:12 ` Sean Whitton 1 sibling, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2024-07-09 14:18 UTC (permalink / raw) To: Po Lu; +Cc: 71929, spwhitton > 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? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-09 14:18 ` Eli Zaretskii @ 2024-07-09 15:02 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-09 15:45 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-09 15:02 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 71929, spwhitton 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-09 15:02 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-09 15:45 ` Eli Zaretskii 0 siblings, 0 replies; 48+ messages in thread From: Eli Zaretskii @ 2024-07-09 15:45 UTC (permalink / raw) To: Po Lu; +Cc: 71929, spwhitton > 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-09 14:03 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-09 14:18 ` Eli Zaretskii @ 2024-07-10 1:12 ` Sean Whitton 2024-07-24 13:31 ` Basil L. Contovounesios 1 sibling, 1 reply; 48+ messages in thread From: Sean Whitton @ 2024-07-10 1:12 UTC (permalink / raw) To: Po Lu; +Cc: 71929, Eli Zaretskii 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-10 1:12 ` Sean Whitton @ 2024-07-24 13:31 ` Basil L. Contovounesios 2024-07-24 13:38 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Basil L. Contovounesios @ 2024-07-24 13:31 UTC (permalink / raw) To: Sean Whitton; +Cc: Po Lu, 71929, Eli Zaretskii 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-24 13:31 ` Basil L. Contovounesios @ 2024-07-24 13:38 ` Eli Zaretskii 2024-07-24 14:10 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2024-07-24 13:38 UTC (permalink / raw) To: Basil L. Contovounesios; +Cc: luangruo, 71929, spwhitton > 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). ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-24 13:38 ` Eli Zaretskii @ 2024-07-24 14:10 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 0 replies; 48+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-24 14:10 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 71929-done, Basil L. Contovounesios, spwhitton 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-06 2:41 ` Sean Whitton 2024-07-06 6:08 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-06 6:40 ` Eli Zaretskii 2024-07-07 2:39 ` Sean Whitton 1 sibling, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2024-07-06 6:40 UTC (permalink / raw) To: Sean Whitton; +Cc: luangruo, 71929 > 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? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#71929: 30.0.60; crash in mark_image_cache 2024-07-06 6:40 ` Eli Zaretskii @ 2024-07-07 2:39 ` Sean Whitton 0 siblings, 0 replies; 48+ messages in thread From: Sean Whitton @ 2024-07-07 2:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, 71929 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
end of thread, other threads:[~2024-07-24 14:10 UTC | newest] Thread overview: 48+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-07-04 2:33 bug#71929: 30.0.60; crash in mark_image_cache Sean Whitton 2024-07-04 2:44 ` Sean Whitton 2024-07-04 5:53 ` Eli Zaretskii 2024-07-04 6:03 ` Eli Zaretskii 2024-07-04 6:17 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-04 6:42 ` Sean Whitton 2024-07-04 6:59 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-04 9:56 ` Sean Whitton 2024-07-04 12:28 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-05 7:52 ` Sean Whitton 2024-07-04 7:40 ` Eli Zaretskii 2024-07-04 9:57 ` Sean Whitton 2024-07-04 12:48 ` Eli Zaretskii 2024-07-05 0:13 ` Sean Whitton 2024-07-05 6:27 ` Eli Zaretskii 2024-07-05 6:41 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-05 7:37 ` Eli Zaretskii 2024-07-05 9:36 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-05 11:10 ` Eli Zaretskii 2024-07-05 11:40 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-05 12:46 ` Sean Whitton 2024-07-06 2:41 ` Sean Whitton 2024-07-06 6:08 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-07 2:40 ` Sean Whitton 2024-07-07 2:43 ` Sean Whitton 2024-07-07 2:46 ` Sean Whitton 2024-07-07 4:04 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-07 4:54 ` Sean Whitton 2024-07-07 7:08 ` Eli Zaretskii 2024-07-07 7:41 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-07 13:16 ` Sean Whitton 2024-07-07 13:47 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-07 14:45 ` Sean Whitton 2024-07-09 5:48 ` Sean Whitton 2024-07-09 11:37 ` Eli Zaretskii 2024-07-10 1:12 ` Sean Whitton 2024-07-09 12:13 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-09 13:44 ` Sean Whitton 2024-07-09 14:03 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-09 14:18 ` Eli Zaretskii 2024-07-09 15:02 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-09 15:45 ` Eli Zaretskii 2024-07-10 1:12 ` Sean Whitton 2024-07-24 13:31 ` Basil L. Contovounesios 2024-07-24 13:38 ` Eli Zaretskii 2024-07-24 14:10 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-07-06 6:40 ` Eli Zaretskii 2024-07-07 2:39 ` Sean Whitton
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.