GNU bug report logs - #75292
31.0.50; igc: (file-error "Doing vfork" "Bad address")

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 75292 in the body.
You can then email your comments to 75292 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Thu, 02 Jan 2025 17:54:45 +0000

I am getting the belo error regularly, when Emacs is spawning external
process. Not every time though.

See the full backtrace below.
Please advice what I can do to debug further.

Debugger entered--Lisp error: (file-error "Doing vfork" "Bad address")
  (call-process-shell-command "grep -anE '^:(Sourc.URL\\+?):[ \11[]+https://curiouscoding\\.nl/posts/static-search-tree/[]]*$' '/home/yantar92/Org/rss_archive_2019.org'" nil t)
  (#<subr shell-command> "grep -anE '^:(Sourc.URL\\+?):[ \11[]+https://curiouscoding\\.nl/posts/static-search-tree/[]]*$' '/home/yantar92/Org/rss_archive_2019.org'" t nil)
  (shell-command <at> shell-command-with-editor-mode #<subr shell-command> "grep -anE '^:(Sourc.URL\\+?):[ \11[]+https://curiouscoding\\.nl/posts/static-search-tree/[]]*$' '/home/yantar92/Org/rss_archive_2019.org'" t nil)
  (apply shell-command <at> shell-command-with-editor-mode #<subr shell-command> ("grep -anE '^:(Sourc.URL\\+?):[ \11[]+https://curiouscoding\\.nl/posts/static-search-tree/[]]*$' '/home/yantar92/Org/rss_archive_2019.org'" t))
  (shell-command "grep -anE '^:(Sourc.URL\\+?):[ \11[]+https://curiouscoding\\.nl/posts/static-search-tree/[]]*$' '/home/yantar92/Org/rss_archive_2019.org'" t)
  (shell-command-to-string "grep -anE '^:(Sourc.URL\\+?):[ \11[]+https://curiouscoding\\.nl/posts/static-search-tree/[]]*$' '/home/yantar92/Org/rss_archive_2019.org'")
  (let ((ans (shell-command-to-string (format "grep -anE '%s' '%s'" regexp file)))) (if (string-empty-p ans) nil (setq matches (append matches (mapcar #'(lambda (str) (if ... ...)) (string-lines ans))))))
  (progn (let ((ans (shell-command-to-string (format "grep -anE '%s' '%s'" regexp file)))) (if (string-empty-p ans) nil (setq matches (append matches (mapcar #'(lambda ... ...) (string-lines ans)))))))
  (if (file-exists-p file) (progn (let ((ans (shell-command-to-string (format "grep -anE '%s' '%s'" regexp file)))) (if (string-empty-p ans) nil (setq matches (append matches (mapcar #'... (string-lines ans))))))))
  (let ((file (car tail))) (if (file-exists-p file) (progn (let ((ans (shell-command-to-string (format "grep -anE '%s' '%s'" regexp file)))) (if (string-empty-p ans) nil (setq matches (append matches (mapcar ... ...))))))) (setq tail (cdr tail)))
  (while tail (let ((file (car tail))) (if (file-exists-p file) (progn (let ((ans (shell-command-to-string ...))) (if (string-empty-p ans) nil (setq matches (append matches ...)))))) (setq tail (cdr tail))))
  (let ((tail files)) (while tail (let ((file (car tail))) (if (file-exists-p file) (progn (let ((ans ...)) (if (string-empty-p ans) nil (setq matches ...))))) (setq tail (cdr tail)))))
  (let (files matches) (if (eq org-capture-ref--org-agenda-files-cached org-agenda-files) (setq files org-capture-ref--org-agenda-files-and-archives-cached) (setq files (org-agenda-files t t)) (setq org-capture-ref--org-agenda-files-cached org-agenda-files) (setq org-capture-ref--org-agenda-files-and-archives-cached files)) (if (eq (car org-agenda-text-search-extra-files) 'agenda-archives) (progn (car-safe (prog1 org-agenda-text-search-extra-files (setq org-agenda-text-search-extra-files (cdr org-agenda-text-search-extra-files)))))) (setq files (append files org-agenda-text-search-extra-files)) (let ((inhibit-message t)) (org-save-all-org-buffers)) (let ((tail files)) (while tail (let ((file (car tail))) (if (file-exists-p file) (progn (let (...) (if ... nil ...)))) (setq tail (cdr tail))))) (setq matches (remove nil matches)) (if matches (progn (if dont-show-match-p nil (save-excursion (save-restriction (switch-to-buffer (marker-buffer ...)) (goto-char (car matches)) (org-back-to-heading t) (org-show-set-visibility 'lineage) (org-show-entry) (jit-lock-fontify-now (point) (save-excursion ...)) (if (yes-or-no-p "Update the entry according to the new capture? ") (progn ... ... ...))))) (if dont-show-match-p (org-capture-ref-message (string-join (mapcar #'org-capture-ref-get-message-string matches) "\n") 'error) (user-error "")))))
  (org-capture-ref-check-regexp-grep "^:(Sourc.URL\\+?):[ \11[]+https://curiouscoding\\.nl/posts/static-search-tree/[]]*$" t)
  (let nil (org-capture-ref-check-regexp-grep (seq-reduce #'(lambda (str repl-pair) (replace-regexp-in-string (car repl-pair) (cdr repl-pair) str)) '(("\\(^\\|[^\\]\\)|" . ".") ("\\\\|" . "|") ("\\\\\\." . "\\\\.") ("'" . ".") ("\\\\(" . "(") ("\\\\)" . ")")) regexp) dont-show-match-p))
  (cond ((eq org-capture-ref-check-regexp-method 'grep) (let nil (org-capture-ref-check-regexp-grep (seq-reduce #'(lambda (str repl-pair) (replace-regexp-in-string ... ... str)) '(("\\(^\\|[^\\]\\)|" . ".") ("\\\\|" . "|") ("\\\\\\." . "\\\\.") ("'" . ".") ("\\\\(" . "(") ("\\\\)" . ")")) regexp) dont-show-match-p))) ((eq org-capture-ref-check-regexp-method 'org-search-view) (let nil (org-capture-ref-check-regexp-search-view regexp dont-show-match-p))) (t (let nil (org-capture-ref-message (format "Invalid value of org-capture-ref-check-regexp-method: %s" org-capture-ref-check-regexp-method) 'error))))
  (org-capture-ref-check-regexp "^:(Source|URL\\+?):[ \11[]+https://curiouscoding\\.nl/posts/static-search-tree/[]]*$" t)
  (progn (org-capture-ref-check-regexp (format (alist-get org-capture-ref-check-regexp-method org-capture-ref-check-link-regexp) (regexp-quote (org-capture-ref-get-capture-info :link))) (org-capture-ref-get-capture-template-info :immediate-finish)))
  (if (org-capture-ref-get-capture-info :link) (progn (org-capture-ref-check-regexp (format (alist-get org-capture-ref-check-regexp-method org-capture-ref-check-link-regexp) (regexp-quote (org-capture-ref-get-capture-info :link))) (org-capture-ref-get-capture-template-info :immediate-finish))))
  (org-capture-ref-check-link)
  (run-hooks org-capture-ref-check-bibtex-functions)
  (catch :finish (run-hooks 'org-capture-ref-check-bibtex-functions))
  (if (org-capture-ref-get-bibtex-field :org-hd-marker) nil (catch :finish (run-hooks 'org-capture-ref-check-bibtex-functions)))
  (org-capture-ref-check-bibtex)
  (if (org-capture-ref-get-capture-info '(:query :force)) nil (org-capture-ref-check-bibtex))
  (progn (org-capture-ref-reset-state) (add-hook 'org-capture-after-finalize-hook #'org-capture-ref-fetch-collection-maybe 100) (if org-capture-ref-quiet-verbosity nil (org-capture-ref-message "Capturing BiBTeX...")) (if (org-capture-ref-get-capture-info '(:query :force)) nil (org-capture-ref-check-bibtex)) (org-capture-ref-get-bibtex) (if (and (org-capture-ref-get-bibtex-field :key) (not (string-match-p "[a-zA-Z]+_[0-9]+" (org-capture-ref-get-bibtex-field :key))) (< 10 (length (org-capture-ref-get-bibtex-field :key)))) nil (org-capture-ref-set-bibtex-field :key nil 'force) (org-capture-ref-set-bibtex-field :key (org-capture-ref-generate-key))) (org-capture-ref-set-bibtex-field :bibtex-string (org-capture-ref-format-bibtex)) (if (or (org-capture-ref-get-capture-info '(:query :org-hd-marker)) (org-capture-ref-get-bibtex-field :org-hd-marker)) (progn (let ((--mepom (or (org-capture-ref-get-capture-info ...) (org-capture-ref-get-bibtex-field :org-hd-marker)))) (save-excursion (cond ((markerp --mepom) (set-buffer ...)) ((numberp --mepom)) (t (if ... ...) (setq --mepom ...))) (save-excursion (save-restriction (widen) (goto-char ...) (org-back-to-heading) (org-capture-ref-get-bibtex-org-heading) (add-hook ... ... 100))))))) (if (org-capture-ref-get-capture-info '(:query :force)) nil (org-capture-ref-check-bibtex)) (if org-capture-ref-quiet-verbosity nil (org-capture-ref-message "Capturing BiBTeX... done")) (org-capture-ref-message (format "Captured: %s" (string-trim-right (org-capture-ref-get-org-entry) "\n[^z-a]*")) 'info))
  (unwind-protect (progn (org-capture-ref-reset-state) (add-hook 'org-capture-after-finalize-hook #'org-capture-ref-fetch-collection-maybe 100) (if org-capture-ref-quiet-verbosity nil (org-capture-ref-message "Capturing BiBTeX...")) (if (org-capture-ref-get-capture-info '(:query :force)) nil (org-capture-ref-check-bibtex)) (org-capture-ref-get-bibtex) (if (and (org-capture-ref-get-bibtex-field :key) (not (string-match-p "[a-zA-Z]+_[0-9]+" (org-capture-ref-get-bibtex-field :key))) (< 10 (length (org-capture-ref-get-bibtex-field :key)))) nil (org-capture-ref-set-bibtex-field :key nil 'force) (org-capture-ref-set-bibtex-field :key (org-capture-ref-generate-key))) (org-capture-ref-set-bibtex-field :bibtex-string (org-capture-ref-format-bibtex)) (if (or (org-capture-ref-get-capture-info '(:query :org-hd-marker)) (org-capture-ref-get-bibtex-field :org-hd-marker)) (progn (let ((--mepom (or ... ...))) (save-excursion (cond (... ...) (...) (t ... ...)) (save-excursion (save-restriction ... ... ... ... ...)))))) (if (org-capture-ref-get-capture-info '(:query :force)) nil (org-capture-ref-check-bibtex)) (if org-capture-ref-quiet-verbosity nil (org-capture-ref-message "Capturing BiBTeX... done")) (org-capture-ref-message (format "Captured: %s" (string-trim-right (org-capture-ref-get-org-entry) "\n[^z-a]*")) 'info)) (if (buffer-live-p org-capture-ref--buffer) (progn (kill-buffer org-capture-ref--buffer))))
  (org-capture-ref-process-capture)
  ((lambda nil (org-capture-ref-process-capture)))
  (doct--replace-template-strings "%{fetch-bibtex}* TODO %?%{space}%{org-entry}")
  (doct--fill-template "%{fetch-bibtex}* TODO %?%{space}%{org-entry}")
  (#<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_16> "%{fetch-bibtex}* TODO %?%{space}%{org-entry}")
  (doct--fill-template)
  (org-capture-get-template)
  (#f(compiled-function (&optional goto keys) "Capture something.\n\\<org-capture-mode-map>\nThis will let you select a template from `org-capture-templates', and\nthen file the newly captured information.  The text is immediately\ninserted at the target location, and an indirect buffer is shown where\nyou can edit it.  Pressing `\\[org-capture-finalize]' brings you back to the previous\nstate of Emacs, so that you can continue your work.\n\nWhen called interactively with a `\\[universal-argument]' prefix argument GOTO, don't\ncapture anything, just go to the file/headline where the selected\ntemplate stores its notes.\n\nWith a `\\[universal-argument] \\[universal-argument]' prefix argument, go to the last note stored.\n\nWhen called with a `C-0' (zero) prefix, insert a template at point.\n\nWhen called with a `C-1' (one) prefix, force prompting for a date when\na datetree entry is made.\n\nELisp programs can set KEYS to a string associated with a template\nin `org-capture-templates'.  In this case, interactive selection\nwill be bypassed.\n\nIf `org-capture-use-agenda-date' is non-nil, capturing from the\nagenda will use the date at point as the default date.  Then, a\n`C-1' prefix will tell the capture process to use the HH:MM time\nof the day at point (if any) or the current HH:MM time." (interactive "P") #<bytecode 0x18ab8d26c4a26010>) nil "B")
  (funcall #f(compiled-function (&optional goto keys) "Capture something.\n\\<org-capture-mode-map>\nThis will let you select a template from `org-capture-templates', and\nthen file the newly captured information.  The text is immediately\ninserted at the target location, and an indirect buffer is shown where\nyou can edit it.  Pressing `\\[org-capture-finalize]' brings you back to the previous\nstate of Emacs, so that you can continue your work.\n\nWhen called interactively with a `\\[universal-argument]' prefix argument GOTO, don't\ncapture anything, just go to the file/headline where the selected\ntemplate stores its notes.\n\nWith a `\\[universal-argument] \\[universal-argument]' prefix argument, go to the last note stored.\n\nWhen called with a `C-0' (zero) prefix, insert a template at point.\n\nWhen called with a `C-1' (one) prefix, force prompting for a date when\na datetree entry is made.\n\nELisp programs can set KEYS to a string associated with a template\nin `org-capture-templates'.  In this case, interactive selection\nwill be bypassed.\n\nIf `org-capture-use-agenda-date' is non-nil, capturing from the\nagenda will use the date at point as the default date.  Then, a\n`C-1' prefix will tell the capture process to use the HH:MM time\nof the day at point (if any) or the current HH:MM time." (interactive "P") #<bytecode 0x18ab8d26c4a26010>) nil "B")
  (if (or (and (boundp 'yant/suppress-pop-frame) yant/suppress-pop-frame) (member :immediate-finish (assoc keys org-capture-templates))) (funcall orig-fun goto keys) (funcall old-fun orig-fun goto keys))
  (ocpf--org-capture <at> suppress-pop-frame-maybe #f(lambda (orig-fun &optional goto keys) :dynbind "Create a new frame and run org-capture." (interactive nil) (let ((frame-window-system (cond ((eq system-type ...) 'ns) ((eq system-type ...) 'x) ((eq system-type ...) 'w32))) (after-make-frame-functions #'(lambda (frame) (let ... ...)))) (make-frame (cons (cons 'window-system frame-window-system) ocpf-frame-parameters)))) #f(compiled-function (&optional goto keys) "Capture something.\n\\<org-capture-mode-map>\nThis will let you select a template from `org-capture-templates', and\nthen file the newly captured information.  The text is immediately\ninserted at the target location, and an indirect buffer is shown where\nyou can edit it.  Pressing `\\[org-capture-finalize]' brings you back to the previous\nstate of Emacs, so that you can continue your work.\n\nWhen called interactively with a `\\[universal-argument]' prefix argument GOTO, don't\ncapture anything, just go to the file/headline where the selected\ntemplate stores its notes.\n\nWith a `\\[universal-argument] \\[universal-argument]' prefix argument, go to the last note stored.\n\nWhen called with a `C-0' (zero) prefix, insert a template at point.\n\nWhen called with a `C-1' (one) prefix, force prompting for a date when\na datetree entry is made.\n\nELisp programs can set KEYS to a string associated with a template\nin `org-capture-templates'.  In this case, interactive selection\nwill be bypassed.\n\nIf `org-capture-use-agenda-date' is non-nil, capturing from the\nagenda will use the date at point as the default date.  Then, a\n`C-1' prefix will tell the capture process to use the HH:MM time\nof the day at point (if any) or the current HH:MM time." (interactive "P") #<bytecode 0x18ab8d26c4a26010>) nil "B")
  (apply ocpf--org-capture <at> suppress-pop-frame-maybe #f(lambda (orig-fun &optional goto keys) :dynbind "Create a new frame and run org-capture." (interactive nil) (let ((frame-window-system (cond ((eq system-type ...) 'ns) ((eq system-type ...) 'x) ((eq system-type ...) 'w32))) (after-make-frame-functions #'(lambda (frame) (let ... ...)))) (make-frame (cons (cons 'window-system frame-window-system) ocpf-frame-parameters)))) (#f(compiled-function (&optional goto keys) "Capture something.\n\\<org-capture-mode-map>\nThis will let you select a template from `org-capture-templates', and\nthen file the newly captured information.  The text is immediately\ninserted at the target location, and an indirect buffer is shown where\nyou can edit it.  Pressing `\\[org-capture-finalize]' brings you back to the previous\nstate of Emacs, so that you can continue your work.\n\nWhen called interactively with a `\\[universal-argument]' prefix argument GOTO, don't\ncapture anything, just go to the file/headline where the selected\ntemplate stores its notes.\n\nWith a `\\[universal-argument] \\[universal-argument]' prefix argument, go to the last note stored.\n\nWhen called with a `C-0' (zero) prefix, insert a template at point.\n\nWhen called with a `C-1' (one) prefix, force prompting for a date when\na datetree entry is made.\n\nELisp programs can set KEYS to a string associated with a template\nin `org-capture-templates'.  In this case, interactive selection\nwill be bypassed.\n\nIf `org-capture-use-agenda-date' is non-nil, capturing from the\nagenda will use the date at point as the default date.  Then, a\n`C-1' prefix will tell the capture process to use the HH:MM time\nof the day at point (if any) or the current HH:MM time." (interactive "P") #<bytecode 0x18ab8d26c4a26010>) nil "B"))
  (ocpf--org-capture #f(compiled-function (&optional goto keys) "Capture something.\n\\<org-capture-mode-map>\nThis will let you select a template from `org-capture-templates', and\nthen file the newly captured information.  The text is immediately\ninserted at the target location, and an indirect buffer is shown where\nyou can edit it.  Pressing `\\[org-capture-finalize]' brings you back to the previous\nstate of Emacs, so that you can continue your work.\n\nWhen called interactively with a `\\[universal-argument]' prefix argument GOTO, don't\ncapture anything, just go to the file/headline where the selected\ntemplate stores its notes.\n\nWith a `\\[universal-argument] \\[universal-argument]' prefix argument, go to the last note stored.\n\nWhen called with a `C-0' (zero) prefix, insert a template at point.\n\nWhen called with a `C-1' (one) prefix, force prompting for a date when\na datetree entry is made.\n\nELisp programs can set KEYS to a string associated with a template\nin `org-capture-templates'.  In this case, interactive selection\nwill be bypassed.\n\nIf `org-capture-use-agenda-date' is non-nil, capturing from the\nagenda will use the date at point as the default date.  Then, a\n`C-1' prefix will tell the capture process to use the HH:MM time\nof the day at point (if any) or the current HH:MM time." (interactive "P") #<bytecode 0x18ab8d26c4a26010>) nil "B")
  (apply ocpf--org-capture #f(compiled-function (&optional goto keys) "Capture something.\n\\<org-capture-mode-map>\nThis will let you select a template from `org-capture-templates', and\nthen file the newly captured information.  The text is immediately\ninserted at the target location, and an indirect buffer is shown where\nyou can edit it.  Pressing `\\[org-capture-finalize]' brings you back to the previous\nstate of Emacs, so that you can continue your work.\n\nWhen called interactively with a `\\[universal-argument]' prefix argument GOTO, don't\ncapture anything, just go to the file/headline where the selected\ntemplate stores its notes.\n\nWith a `\\[universal-argument] \\[universal-argument]' prefix argument, go to the last note stored.\n\nWhen called with a `C-0' (zero) prefix, insert a template at point.\n\nWhen called with a `C-1' (one) prefix, force prompting for a date when\na datetree entry is made.\n\nELisp programs can set KEYS to a string associated with a template\nin `org-capture-templates'.  In this case, interactive selection\nwill be bypassed.\n\nIf `org-capture-use-agenda-date' is non-nil, capturing from the\nagenda will use the date at point as the default date.  Then, a\n`C-1' prefix will tell the capture process to use the HH:MM time\nof the day at point (if any) or the current HH:MM time." (interactive "P") #<bytecode 0x18ab8d26c4a26010>) (nil "B"))
  (org-capture nil "B")
  (org-protocol-capture (:template "B" :url "https://curiouscoding.nl/posts/static-search-tree/" :title "Hacker News: Static search trees: faster than binary search" :elfeed-data #s(elfeed-entry :id ("news.ycombinator.com" . "https://curiouscoding.nl/posts/static-search-tree/") :title "Static search trees: faster than binary search" :link "https://curiouscoding.nl/posts/static-search-tree/" :date 1735690083.0 :content #s(elfeed-ref :id "8e2e9d3bf05bcac3908e187a096bb899ea3dfefc") :content-type html :enclosures nil :tags (opened) :feed-id "https://news.ycombinator.com/rss" :meta (:elfeed-score/score 0))))
  (let ((yant/suppress-pop-frame t)) (org-protocol-capture (list :template "B" :url it :title (format "%s: %s" (elfeed-feed-title (elfeed-entry-feed entry)) (elfeed-entry-title entry)) :elfeed-data entry)))
  (progn (fset 'raise-frame vnew) (let ((yant/suppress-pop-frame t)) (org-protocol-capture (list :template "B" :url it :title (format "%s: %s" (elfeed-feed-title (elfeed-entry-feed entry)) (elfeed-entry-title entry)) :elfeed-data entry))))
  (unwind-protect (progn (fset 'raise-frame vnew) (let ((yant/suppress-pop-frame t)) (org-protocol-capture (list :template "B" :url it :title (format "%s: %s" (elfeed-feed-title (elfeed-entry-feed entry)) (elfeed-entry-title entry)) :elfeed-data entry)))) (fset 'raise-frame old))
  (let* ((vnew #'(lambda (&rest _) nil)) (old (symbol-function 'raise-frame))) (unwind-protect (progn (fset 'raise-frame vnew) (let ((yant/suppress-pop-frame t)) (org-protocol-capture (list :template "B" :url it :title (format "%s: %s" (elfeed-feed-title ...) (elfeed-entry-title entry)) :elfeed-data entry)))) (fset 'raise-frame old)))
  (progn (let* ((vnew #'(lambda (&rest _) nil)) (old (symbol-function 'raise-frame))) (unwind-protect (progn (fset 'raise-frame vnew) (let ((yant/suppress-pop-frame t)) (org-protocol-capture (list :template "B" :url it :title (format "%s: %s" ... ...) :elfeed-data entry)))) (fset 'raise-frame old))))
  (if it (progn (let* ((vnew #'(lambda (&rest _) nil)) (old (symbol-function 'raise-frame))) (unwind-protect (progn (fset 'raise-frame vnew) (let ((yant/suppress-pop-frame t)) (org-protocol-capture (list :template "B" :url it :title ... :elfeed-data entry)))) (fset 'raise-frame old)))))
  (let ((it (elfeed-entry-link entry))) (if it (progn (let* ((vnew #'(lambda ... nil)) (old (symbol-function 'raise-frame))) (unwind-protect (progn (fset 'raise-frame vnew) (let (...) (org-protocol-capture ...))) (fset 'raise-frame old))))))
  (while (consp --cl-var--) (setq entry (car --cl-var--)) (elfeed-untag entry 'unread) (let ((it (elfeed-entry-link entry))) (if it (progn (let* ((vnew #'...) (old (symbol-function ...))) (unwind-protect (progn (fset ... vnew) (let ... ...)) (fset 'raise-frame old)))))) (setq --cl-var-- (cdr --cl-var--)))
  (let* ((--cl-var-- entries) (entry nil)) (while (consp --cl-var--) (setq entry (car --cl-var--)) (elfeed-untag entry 'unread) (let ((it (elfeed-entry-link entry))) (if it (progn (let* ((vnew ...) (old ...)) (unwind-protect (progn ... ...) (fset ... old)))))) (setq --cl-var-- (cdr --cl-var--))) nil)
  (let ((entries (elfeed-search-selected))) (let* ((--cl-var-- entries) (entry nil)) (while (consp --cl-var--) (setq entry (car --cl-var--)) (elfeed-untag entry 'unread) (let ((it (elfeed-entry-link entry))) (if it (progn (let* (... ...) (unwind-protect ... ...))))) (setq --cl-var-- (cdr --cl-var--))) nil) (mapc #'elfeed-search-update-entry entries) (if (use-region-p) nil (forward-line)))
  (#f(lambda () :dynbind "Capture selected entries into inbox." (interactive nil) (elfeed-search-tag-all 'opened) (meta-up) (let ((entries (elfeed-search-selected))) (let* ((--cl-var-- entries) (entry nil)) (while (consp --cl-var--) (setq entry (car --cl-var--)) (elfeed-untag entry 'unread) (let ((it ...)) (if it (progn ...))) (setq --cl-var-- (cdr --cl-var--))) nil) (mapc #'elfeed-search-update-entry entries) (if (use-region-p) nil (forward-line)))))
  (apply #f(lambda () :dynbind "Capture selected entries into inbox." (interactive nil) (elfeed-search-tag-all 'opened) (meta-up) (let ((entries (elfeed-search-selected))) (let* ((--cl-var-- entries) (entry nil)) (while (consp --cl-var--) (setq entry (car --cl-var--)) (elfeed-untag entry 'unread) (let ((it ...)) (if it (progn ...))) (setq --cl-var-- (cdr --cl-var--))) nil) (mapc #'elfeed-search-update-entry entries) (if (use-region-p) nil (forward-line)))) nil)
  (yant/elfeed-capture-entry)
  (funcall-interactively yant/elfeed-capture-entry)
  (command-execute yant/elfeed-capture-entry)


In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.42, cairo version 1.18.2) of 2024-12-28 built on localhost
Repository revision: ae6924ac7e76c40bb2c1e99dda60fbad5a971046
Repository branch: scratch/igc
Windowing system distributor 'The X.Org Foundation', version 11.0.12101014
System Description: Gentoo Linux

Configured using:
 'configure --with-mps=yes --with-native-compilation 'CFLAGS=-g3
 -I/opt/mps/include -L/opt/mps/lib'
 JAVAC=/etc/java-config-2/current-system-vm/bin/javac
 PKG_CONFIG_PATH=/usr/share/guile-data/3.0/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG
LCMS2 LIBXML2 MODULES MPS NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG
SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM
XINPUT2 XPM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.utf8
  locale-coding-system: utf-8-unix

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message #8 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>,
 Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 75292 <at> debbugs.gnu.org
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Thu, 02 Jan 2025 20:37:41 +0200

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Date: Thu, 02 Jan 2025 17:54:45 +0000
> 
> I am getting the belo error regularly, when Emacs is spawning external
> process. Not every time though.
> 
> See the full backtrace below.
> Please advice what I can do to debug further.
> 
> Debugger entered--Lisp error: (file-error "Doing vfork" "Bad address")
>   (call-process-shell-command "grep -anE '^:(Sourc.URL\\+?):[ \11[]+https://curiouscoding\\.nl/posts/static-search-tree/[]]*$' '/home/yantar92/Org/rss_archive_2019.org'" nil t)

Is this something new?  If so, did you update some system libraries
lately?

Paul, any ideas or suggestions?

Message #11 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75292 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Thu, 02 Jan 2025 18:42:14 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Debugger entered--Lisp error: (file-error "Doing vfork" "Bad address")
>>   (call-process-shell-command "grep -anE '^:(Sourc.URL\\+?):[ \11[]+https://curiouscoding\\.nl/posts/static-search-tree/[]]*$' '/home/yantar92/Org/rss_archive_2019.org'" nil t)
>
> Is this something new?  If so, did you update some system libraries
> lately?

I am seeing it since long time ago.
It is just that I had enough willpower to report this recently, after I
came back to testing the igc branch.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message #14 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 75292 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Thu, 02 Jan 2025 21:29:45 +0200

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 75292 <at> debbugs.gnu.org
> Date: Thu, 02 Jan 2025 18:42:14 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Debugger entered--Lisp error: (file-error "Doing vfork" "Bad address")
> >>   (call-process-shell-command "grep -anE '^:(Sourc.URL\\+?):[ \11[]+https://curiouscoding\\.nl/posts/static-search-tree/[]]*$' '/home/yantar92/Org/rss_archive_2019.org'" nil t)
> >
> > Is this something new?  If so, did you update some system libraries
> > lately?
> 
> I am seeing it since long time ago.

Could it be that this started happening when we began using
posix_spawn instead of vfork?  If you rebuild Emacs disabling
USABLE_POSIX_SPAWN, does the problem go away?

Message #17 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75292 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Thu, 02 Jan 2025 19:37:00 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

> Could it be that this started happening when we began using
> posix_spawn instead of vfork?  If you rebuild Emacs disabling
> USABLE_POSIX_SPAWN, does the problem go away?

Should I pass some ./configure option? Or do you want me to modify the
sources directly?

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message #20 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>, Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 75292 <at> debbugs.gnu.org
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Thu, 2 Jan 2025 11:41:29 -0800

On 2025-01-02 11:29, Eli Zaretskii wrote:
>>>> Debugger entered--Lisp error: (file-error "Doing vfork" "Bad address")
>>>>    (call-process-shell-command "grep -anE '^:(Sourc.URL\\+?):[ \11[]+https://curiouscoding\\.nl/posts/static-search-tree/[]]*$' '/home/yantar92/Org/rss_archive_2019.org'" nil t)
...
> Could it be that this started happening when we began using
> posix_spawn instead of vfork?

If Emacs uses posix_spawn instead of vfork, shouldn't file-error report 
"Doing posix_spawn" instead of "Doing vfork"? Truth in advertising and 
all that....

Message #23 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 75292 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Thu, 02 Jan 2025 22:22:09 +0200

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: eggert <at> cs.ucla.edu, 75292 <at> debbugs.gnu.org
> Date: Thu, 02 Jan 2025 19:37:00 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Could it be that this started happening when we began using
> > posix_spawn instead of vfork?  If you rebuild Emacs disabling
> > USABLE_POSIX_SPAWN, does the problem go away?
> 
> Should I pass some ./configure option? Or do you want me to modify the
> sources directly?

I think you just need to recompile callproc.c and then relink.  Like
this:

  $ cd src
  $ make callproc.o -W callproc.c MYCPPFLAGS='-DUSABLE_POSIX_SPAWN=0'
  $ cd .. && make

Message #26 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 75292 <at> debbugs.gnu.org, yantar92 <at> posteo.net
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Thu, 02 Jan 2025 22:35:06 +0200

> Date: Thu, 2 Jan 2025 11:41:29 -0800
> Cc: 75292 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> On 2025-01-02 11:29, Eli Zaretskii wrote:
> >>>> Debugger entered--Lisp error: (file-error "Doing vfork" "Bad address")
> >>>>    (call-process-shell-command "grep -anE '^:(Sourc.URL\\+?):[ \11[]+https://curiouscoding\\.nl/posts/static-search-tree/[]]*$' '/home/yantar92/Org/rss_archive_2019.org'" nil t)
> ...
> > Could it be that this started happening when we began using
> > posix_spawn instead of vfork?
> 
> If Emacs uses posix_spawn instead of vfork, shouldn't file-error report 
> "Doing posix_spawn" instead of "Doing vfork"? Truth in advertising and 
> all that....

We should, but it looks like someone didn't want to condition the
value of CHILD_SETUP_ERROR_DESC by USABLE_POSIX_SPAWN...

Message #29 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75292 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Thu, 02 Jan 2025 20:45:57 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

> I think you just need to recompile callproc.c and then relink.  Like
> this:
>
>   $ cd src
>   $ make callproc.o -W callproc.c MYCPPFLAGS='-DUSABLE_POSIX_SPAWN=0'
>   $ cd .. && make

Done.
I will run this version for a couple of days and see if the error
re-surface.

[yantar92:~/Git/emacs] scratch/igc+* 1h3m1s 1 ± 
> cd src
[yantar92:~/Git/emacs/src] scratch/igc+* 2s ± 
> make callproc.o -W callproc.c MYCPPFLAGS='-DUSABLE_POSIX_SPAWN=0'
  GEN      globals.h
  CC       callproc.o
callproc.c:47:10: warning: "USABLE_POSIX_SPAWN" redefined
   47 | # define USABLE_POSIX_SPAWN 1
      |          ^~~~~~~~~~~~~~~~~~
<command-line>: note: this is the location of the previous definition
[yantar92:~/Git/emacs/src] scratch/igc+* 7s ± 
> cd .. && make
...

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message #32 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> protonmail.com>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 75292 <at> debbugs.gnu.org
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Thu, 02 Jan 2025 20:45:40 +0000

"Ihor Radchenko" <yantar92 <at> posteo.net> writes:

> I am getting the belo error regularly, when Emacs is spawning external
> process. Not every time though.

Sounds like something's moved by GC and shouldn't be.  Since you're
running without optimization, it's unlikely that GCC (we don't indicate
the compiler used in report-emacs-bug?  we should) mangled a reference
badly.

The code does assume that SAFE_ALLOCA'd string pointers keep the string
data alive.  That is a bug, and it might cause the behavior you see if,
for some weird reason, we wouldn't be using alloca directly.  But I
think we would be, unless there is something odd about your system.

> See the full backtrace below.
> Please advice what I can do to debug further.

After checking Eli's suggestion, an strace would be nice to find out
which of the pointers has gone bad.

FWIW, I'll try reproducing this now, using your build flags...

Pip

Message #35 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 75292 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Thu, 02 Jan 2025 23:07:59 +0200

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: eggert <at> cs.ucla.edu, 75292 <at> debbugs.gnu.org
> Date: Thu, 02 Jan 2025 20:45:57 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > I think you just need to recompile callproc.c and then relink.  Like
> > this:
> >
> >   $ cd src
> >   $ make callproc.o -W callproc.c MYCPPFLAGS='-DUSABLE_POSIX_SPAWN=0'
> >   $ cd .. && make
> 
> Done.
> I will run this version for a couple of days and see if the error
> re-surface.
> 
> [yantar92:~/Git/emacs] scratch/igc+* 1h3m1s 1 ± 
> > cd src
> [yantar92:~/Git/emacs/src] scratch/igc+* 2s ± 
> > make callproc.o -W callproc.c MYCPPFLAGS='-DUSABLE_POSIX_SPAWN=0'
>   GEN      globals.h
>   CC       callproc.o
> callproc.c:47:10: warning: "USABLE_POSIX_SPAWN" redefined
>    47 | # define USABLE_POSIX_SPAWN 1
>       |          ^~~~~~~~~~~~~~~~~~
> <command-line>: note: this is the location of the previous definition
> [yantar92:~/Git/emacs/src] scratch/igc+* 7s ± 

Ugh, then I guess you will need to modify the source, indeed, to
change

  # define USABLE_POSIX_SPAWN 1

to say

  # define USABLE_POSIX_SPAWN 0

Sorry.

Message #38 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75292 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Fri, 03 Jan 2025 17:56:46 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

> Ugh, then I guess you will need to modify the source, indeed, to
> change
>
>   # define USABLE_POSIX_SPAWN 1
>
> to say
>
>   # define USABLE_POSIX_SPAWN 0

Done this morning.
After one day of usage, no errors (so far).

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message #41 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: 75292 <at> debbugs.gnu.org
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Fri, 03 Jan 2025 17:58:33 +0000

Pip Cet <pipcet <at> protonmail.com> writes:

> After checking Eli's suggestion, an strace would be nice to find out
> which of the pointers has gone bad.

It can sometimes take one day to get the error. I am not sure if have
enough disk space to record strace for so long. (I never used strace though)

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message #44 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> protonmail.com>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 75292 <at> debbugs.gnu.org
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Fri, 03 Jan 2025 18:24:47 +0000

"Ihor Radchenko" <yantar92 <at> posteo.net> writes:

> Pip Cet <pipcet <at> protonmail.com> writes:
>
>> After checking Eli's suggestion, an strace would be nice to find out
>> which of the pointers has gone bad.
>
> It can sometimes take one day to get the error. I am not sure if have
> enough disk space to record strace for so long. (I never used strace though)

Ouch.  I didn't manage to reproduce it; maybe I didn't try for long
enough.

For the record, Emacs still defaults to -O if no optimization option is
specified.  I fixed that in my tree a long time ago, and I forgot.  You
are running with optimization so it's entirely possible an automatic
variable which should have kept alive the string disappeared.

My suggestion would be

(strace -ff ...emacs... 2>&1) | egrep -50 '(fork|clone|spawn|exec)'

(grep -e on most distros, but you use gentoo, right?)

Note that this will attach to all of emacs's child processes
recursively, so there still might be a lot of output.

You can also attach to a running emacs process with strace -p; this
should allow you to kill the strace and attach gdb to emacs afterwards
for inspection purposes.

However, we have three possible explanations for this bug that we
already know about; maybe it's best to fix those three and see whether
the bug went away?

I've opened bug#75322 for the almost definitely buggy usage of
SAFE_ALLOCA in process.c and callproc.c, which might explain this (but I
don't think it does, TBH, because SAFE_ALLOCA would use alloca on your
system in this case, I think).

I don't think it's the 64KB stack allocation of call_process, either,
but that's also something we shouldn't do and there is a tiny chance
we somehow fail to mark a large C stack.

The most likely candidate right now is make_environment_block, which
happily stuffs string data pointers into an xmalloc'd block and goes
about its merry way without letting GC know about them.   I think it
would cause the problem you observed, but haven't managed to reproduce
it yet.  If I manage to do so, I'll push a fix.

Pip

Message #47 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> protonmail.com>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 75292 <at> debbugs.gnu.org
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Fri, 03 Jan 2025 19:11:58 +0000

Pip Cet <pipcet <at> protonmail.com> writes:

> "Ihor Radchenko" <yantar92 <at> posteo.net> writes:
>
> The most likely candidate right now is make_environment_block, which
> happily stuffs string data pointers into an xmalloc'd block and goes
> about its merry way without letting GC know about them.   I think it
> would cause the problem you observed, but haven't managed to reproduce
> it yet.  If I manage to do so, I'll push a fix.

There's definitely a bug there (inserting an igc_collect() will corrupt
the environment), and I'll fix it, but I'm a bit puzzled by the "Bad
address" thing, and I think there may be an additional bug (making four
overall for this very productive bug report):

How do syscalls and execve(), in particular, handle the case of a
pointer to MPS-managed memory which is behind an active memory barrier?
I'm pretty sure there's no SIGSEGV in this case, just an EFAULT.  Easily
fixable for execve, which accesses only a limited amount of data, but I
don't remember whether we ever read() or write() MPS-managed memory,
which I assume would eventually run into this bug.

If syscalls silently accept mprotect()ed mapped areas which are
currently inaccessible (they really shouldn't because it breaks w+x
protection!), that's an additional problem we need to work around,
because the memory contents might not be valid.  I don't think we(*)
ever read() or write() Lisp_Objects and expect useful results, so maybe
everything's okay in that case?

(*) - the fork()-based mark-and-sweep GC did, so it's not entirely
unreasonable to do that :-)

Pip

Message #50 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 75292 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Fri, 03 Jan 2025 21:33:13 +0200

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: eggert <at> cs.ucla.edu, 75292 <at> debbugs.gnu.org
> Date: Fri, 03 Jan 2025 17:56:46 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Ugh, then I guess you will need to modify the source, indeed, to
> > change
> >
> >   # define USABLE_POSIX_SPAWN 1
> >
> > to say
> >
> >   # define USABLE_POSIX_SPAWN 0
> 
> Done this morning.
> After one day of usage, no errors (so far).

I one day enough time to conclude that this problem is gone?  How
frequently did you get that error before the change?

Message #53 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: 75292 <at> debbugs.gnu.org, yantar92 <at> posteo.net
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Fri, 03 Jan 2025 21:47:23 +0200

> Cc: 75292 <at> debbugs.gnu.org
> Date: Fri, 03 Jan 2025 18:24:47 +0000
> From:  Pip Cet via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> The most likely candidate right now is make_environment_block, which
> happily stuffs string data pointers into an xmalloc'd block and goes
> about its merry way without letting GC know about them.   I think it
> would cause the problem you observed, but haven't managed to reproduce
> it yet.  If I manage to do so, I'll push a fix.

Please be sure to show the patch before you push, and please explain
the problem you found and the fix.

This is a delicate area, so we must discuss any changes before they
are installed.

Thanks.

Message #56 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> protonmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75292 <at> debbugs.gnu.org, yantar92 <at> posteo.net
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Fri, 03 Jan 2025 19:51:54 +0000

"Eli Zaretskii" <eliz <at> gnu.org> writes:

>> Cc: 75292 <at> debbugs.gnu.org
>> Date: Fri, 03 Jan 2025 18:24:47 +0000
>> From:  Pip Cet via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> The most likely candidate right now is make_environment_block, which
>> happily stuffs string data pointers into an xmalloc'd block and goes
>> about its merry way without letting GC know about them.   I think it
>> would cause the problem you observed, but haven't managed to reproduce
>> it yet.  If I manage to do so, I'll push a fix.
>
> Please be sure to show the patch before you push, and please explain
> the problem you found and the fix.

Sorry, didn't see this in time.  Reverted for now.

> This is a delicate area, so we must discuss any changes before they
> are installed.

Okay.

Pip

Message #59 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 75292 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Fri, 03 Jan 2025 22:21:07 +0200

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: eggert <at> cs.ucla.edu, 75292 <at> debbugs.gnu.org
> Date: Fri, 03 Jan 2025 17:56:46 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Ugh, then I guess you will need to modify the source, indeed, to
> > change
> >
> >   # define USABLE_POSIX_SPAWN 1
> >
> > to say
> >
> >   # define USABLE_POSIX_SPAWN 0
> 
> Done this morning.
> After one day of usage, no errors (so far).

Does this problem happen only on the igc branch, or also on master?

Message #62 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75292 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Sat, 04 Jan 2025 14:12:50 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Done this morning.
>> After one day of usage, no errors (so far).
>
> I one day enough time to conclude that this problem is gone?  How
> frequently did you get that error before the change?

Now, 1.5 days :)
I usually get this error once in 1-2 days, especially when I use
elfeed/magit actively.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message #65 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75292 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Sat, 04 Jan 2025 14:13:07 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

> Does this problem happen only on the igc branch, or also on master?

Only igc branch.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message #68 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 75292 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Sat, 04 Jan 2025 16:20:18 +0200

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: eggert <at> cs.ucla.edu, 75292 <at> debbugs.gnu.org
> Date: Sat, 04 Jan 2025 14:12:50 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Done this morning.
> >> After one day of usage, no errors (so far).
> >
> > I one day enough time to conclude that this problem is gone?  How
> > frequently did you get that error before the change?
> 
> Now, 1.5 days :)
> I usually get this error once in 1-2 days, especially when I use
> elfeed/magit actively.

OK, let's wait for another day or two.

Message #71 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 75292 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Sat, 04 Jan 2025 16:22:26 +0200

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: eggert <at> cs.ucla.edu, 75292 <at> debbugs.gnu.org
> Date: Sat, 04 Jan 2025 14:13:07 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Does this problem happen only on the igc branch, or also on master?
> 
> Only igc branch.

Oh.  Then when you said that you are "seeing it since long time ago",
did you mean since you started using the igc branch?

Message #74 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75292 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Sat, 04 Jan 2025 15:21:33 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> > Does this problem happen only on the igc branch, or also on master?
>> 
>> Only igc branch.
>
> Oh.  Then when you said that you are "seeing it since long time ago",
> did you mean since you started using the igc branch?

I am using igc branch irregularly.
I was using it for a while a few months ago, then stopped, now again
trying.
I started seeing the vform errors months ago, during my previous
iteration of igc testing. Just did not report it.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message #77 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75292 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Tue, 07 Jan 2025 17:40:22 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Now, 1.5 days :)
>> I usually get this error once in 1-2 days, especially when I use
>> elfeed/magit actively.
>
> OK, let's wait for another day or two.

The error did not show up until now.
Although, Emacs got quite slow after a few days. Especially when
handling process output - Emacs sometimes froze for a minute or two
while doing M-x compile. (with your suggested changes applied).

I will not go into details yet as it might be a topic for another bug report.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message #80 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 75292 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Tue, 07 Jan 2025 19:50:31 +0200

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: eggert <at> cs.ucla.edu, 75292 <at> debbugs.gnu.org
> Date: Tue, 07 Jan 2025 17:40:22 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Now, 1.5 days :)
> >> I usually get this error once in 1-2 days, especially when I use
> >> elfeed/magit actively.
> >
> > OK, let's wait for another day or two.
> 
> The error did not show up until now.

I guess the next thing to try is to return to the posix_spawn build
after callproc.c is patched as discussed in bug#75322.

Message #83 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75292 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Tue, 07 Jan 2025 18:44:45 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

> I guess the next thing to try is to return to the posix_spawn build
> after callproc.c is patched as discussed in bug#75322.

Do I understand correctly that the patch is not yet finalized?

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message #86 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 75292 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Tue, 07 Jan 2025 21:28:54 +0200

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: eggert <at> cs.ucla.edu, 75292 <at> debbugs.gnu.org
> Date: Tue, 07 Jan 2025 18:44:45 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > I guess the next thing to try is to return to the posix_spawn build
> > after callproc.c is patched as discussed in bug#75322.
> 
> Do I understand correctly that the patch is not yet finalized?

No.  It was installed, but then reverted.  The plan is to revert the
revert, AFAIU.

Message #89 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> protonmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75292 <at> debbugs.gnu.org, Ihor Radchenko <yantar92 <at> posteo.net>,
 eggert <at> cs.ucla.edu
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Fri, 10 Jan 2025 20:17:52 +0000

"Eli Zaretskii" <eliz <at> gnu.org> writes:

>> From: Ihor Radchenko <yantar92 <at> posteo.net>
>> Cc: eggert <at> cs.ucla.edu, 75292 <at> debbugs.gnu.org
>> Date: Tue, 07 Jan 2025 18:44:45 +0000
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > I guess the next thing to try is to return to the posix_spawn build
>> > after callproc.c is patched as discussed in bug#75322.
>>
>> Do I understand correctly that the patch is not yet finalized?
>
> No.  It was installed, but then reverted.  The plan is to revert the
> revert, AFAIU.

If we reinstall that patch, we should not be fixing !HAVE_MPS bugs on
scratch/igc.  If we think there is one, we should install it on master;
if we think there isn't, we should #ifdef it so no changes apply to the
!HAVE_MPS build.

Please let me know which option you prefer.

(My *long-term* preference is option C: make it safe to call traditional
GC while an SDATA pointer is on the stack or in conservatively-scanned
heap regions, which we'd have to introduce first :-)

I got distracted and extended alloc.c conservative scanning to
automatically pin strings if there is a corresponding SDATA pointer on
the stack, and I was going to make conservative scanning apply to
SAFE_ALLOCA xmalloc'd memory next.  If we do that, we can just use
xmalloc_conservative in make_environment_block and SAFE_ALLOCA and we no
longer have to worry about that particular no-GC assumption.

My intention was to display strings with live SDATA pointers to find
bugs where alloc.c GC happens at the wrong time, helping us locate
live-SDATA-during-GC bugs (which would have been a strong argument for
applying the patch).  I couldn't find any, not even when I ramped up GC
to barely tolerable levels and always relocated every single unpinned
string.  I think such bugs exist but are limited to unlikely code paths,
such as the one where ENCODE_FILE calls Lisp, GCs, and destroys
call_process's SDATA pointers (I haven't been able to trigger this bug;
it may be prevented by some logic I missed).

This would make pin_string redundant, but there's also a risk that
constantly compacting all the bytecode objects that are NOT referenced
by the stack would make GC much slower.  It would prevent bugs similar
to this one, but this precise bug would not have been prevented because
the SDATA pointers were in xmalloc'd memory.)

Pip

Message #92 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: 75292 <at> debbugs.gnu.org, yantar92 <at> posteo.net, eggert <at> cs.ucla.edu
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Fri, 10 Jan 2025 22:33:23 +0200

> Date: Fri, 10 Jan 2025 20:17:52 +0000
> From: Pip Cet <pipcet <at> protonmail.com>
> Cc: Ihor Radchenko <yantar92 <at> posteo.net>, 75292 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
> 
> "Eli Zaretskii" <eliz <at> gnu.org> writes:
> 
> > No.  It was installed, but then reverted.  The plan is to revert the
> > revert, AFAIU.
> 
> If we reinstall that patch, we should not be fixing !HAVE_MPS bugs on
> scratch/igc.  If we think there is one, we should install it on master;
> if we think there isn't, we should #ifdef it so no changes apply to the
> !HAVE_MPS build.
> 
> Please let me know which option you prefer.

The latter, please.

Message #95 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75292 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Sat, 11 Jan 2025 18:43:37 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> > I guess the next thing to try is to return to the posix_spawn build
>> > after callproc.c is patched as discussed in bug#75322.
>> 
>> Do I understand correctly that the patch is not yet finalized?
>
> No.  It was installed, but then reverted.  The plan is to revert the
> revert, AFAIU.

AFAIU, the fix has been installed.
I am running with it for a couple of days, and I am not seeing vfork
errors anymore. I guess that this bug might be closed.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message #100 received at 75292-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 75292-done <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Sat, 11 Jan 2025 21:33:25 +0200

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: eggert <at> cs.ucla.edu, 75292 <at> debbugs.gnu.org
> Date: Sat, 11 Jan 2025 18:43:37 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> > I guess the next thing to try is to return to the posix_spawn build
> >> > after callproc.c is patched as discussed in bug#75322.
> >> 
> >> Do I understand correctly that the patch is not yet finalized?
> >
> > No.  It was installed, but then reverted.  The plan is to revert the
> > revert, AFAIU.
> 
> AFAIU, the fix has been installed.
> I am running with it for a couple of days, and I am not seeing vfork
> errors anymore. I guess that this bug might be closed.

Thanks, closing.

Message #103 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75292 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Thu, 30 Jan 2025 19:26:31 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

> I guess the next thing to try is to return to the posix_spawn build
> after callproc.c is patched as discussed in bug#75322.

I tried, and did not get any issues up to now.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message #106 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 75292 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Thu, 30 Jan 2025 21:34:57 +0200

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: eggert <at> cs.ucla.edu, 75292 <at> debbugs.gnu.org
> Date: Thu, 30 Jan 2025 19:26:31 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > I guess the next thing to try is to return to the posix_spawn build
> > after callproc.c is patched as discussed in bug#75322.
> 
> I tried, and did not get any issues up to now.

So can we declare this bug fixed and close it?  Or would you like to
run some more before we do that?

Message #109 received at 75292 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75292 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Thu, 30 Jan 2025 19:39:51 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:
>> I tried, and did not get any issues up to now.
>
> So can we declare this bug fixed and close it?  Or would you like to
> run some more before we do that?

I think we can close the bug.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message #112 received at 75292-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 75292-done <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Thu, 30 Jan 2025 22:31:24 +0200

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: eggert <at> cs.ucla.edu, 75292 <at> debbugs.gnu.org
> Date: Thu, 30 Jan 2025 19:39:51 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> I tried, and did not get any issues up to now.
> >
> > So can we declare this bug fixed and close it?  Or would you like to
> > run some more before we do that?
> 
> I think we can close the bug.

Thanks, done.

Previous Next

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