unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
@ 2025-01-02 17:54 Ihor Radchenko
  2025-01-02 18:37 ` Eli Zaretskii
  2025-01-02 20:45 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 2 replies; 24+ messages in thread
From: Ihor Radchenko @ 2025-01-02 17:54 UTC (permalink / raw)
  To: 75292

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@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@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@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@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>





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
  2025-01-02 17:54 bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address") Ihor Radchenko
@ 2025-01-02 18:37 ` Eli Zaretskii
  2025-01-02 18:42   ` Ihor Radchenko
  2025-01-02 20:45 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2025-01-02 18:37 UTC (permalink / raw)
  To: Ihor Radchenko, Paul Eggert; +Cc: 75292

> From: Ihor Radchenko <yantar92@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?





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
  2025-01-02 18:37 ` Eli Zaretskii
@ 2025-01-02 18:42   ` Ihor Radchenko
  2025-01-02 19:29     ` Eli Zaretskii
  0 siblings, 1 reply; 24+ messages in thread
From: Ihor Radchenko @ 2025-01-02 18:42 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 75292, Paul Eggert

Eli Zaretskii <eliz@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>





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
  2025-01-02 18:42   ` Ihor Radchenko
@ 2025-01-02 19:29     ` Eli Zaretskii
  2025-01-02 19:37       ` Ihor Radchenko
  2025-01-02 19:41       ` Paul Eggert
  0 siblings, 2 replies; 24+ messages in thread
From: Eli Zaretskii @ 2025-01-02 19:29 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: 75292, eggert

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Paul Eggert <eggert@cs.ucla.edu>, 75292@debbugs.gnu.org
> Date: Thu, 02 Jan 2025 18:42:14 +0000
> 
> Eli Zaretskii <eliz@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?





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
  2025-01-02 19:29     ` Eli Zaretskii
@ 2025-01-02 19:37       ` Ihor Radchenko
  2025-01-02 20:22         ` Eli Zaretskii
  2025-01-02 19:41       ` Paul Eggert
  1 sibling, 1 reply; 24+ messages in thread
From: Ihor Radchenko @ 2025-01-02 19:37 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 75292, eggert

Eli Zaretskii <eliz@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>





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
  2025-01-02 19:29     ` Eli Zaretskii
  2025-01-02 19:37       ` Ihor Radchenko
@ 2025-01-02 19:41       ` Paul Eggert
  2025-01-02 20:35         ` Eli Zaretskii
  1 sibling, 1 reply; 24+ messages in thread
From: Paul Eggert @ 2025-01-02 19:41 UTC (permalink / raw)
  To: Eli Zaretskii, Ihor Radchenko; +Cc: 75292

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....





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
  2025-01-02 19:37       ` Ihor Radchenko
@ 2025-01-02 20:22         ` Eli Zaretskii
  2025-01-02 20:45           ` Ihor Radchenko
  0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2025-01-02 20:22 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: 75292, eggert

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: eggert@cs.ucla.edu, 75292@debbugs.gnu.org
> Date: Thu, 02 Jan 2025 19:37:00 +0000
> 
> Eli Zaretskii <eliz@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





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
  2025-01-02 19:41       ` Paul Eggert
@ 2025-01-02 20:35         ` Eli Zaretskii
  0 siblings, 0 replies; 24+ messages in thread
From: Eli Zaretskii @ 2025-01-02 20:35 UTC (permalink / raw)
  To: Paul Eggert; +Cc: 75292, yantar92

> Date: Thu, 2 Jan 2025 11:41:29 -0800
> Cc: 75292@debbugs.gnu.org
> From: Paul Eggert <eggert@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...





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
  2025-01-02 17:54 bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address") Ihor Radchenko
  2025-01-02 18:37 ` Eli Zaretskii
@ 2025-01-02 20:45 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2025-01-03 17:58   ` Ihor Radchenko
  1 sibling, 1 reply; 24+ messages in thread
From: Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-02 20:45 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: 75292

"Ihor Radchenko" <yantar92@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






^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
  2025-01-02 20:22         ` Eli Zaretskii
@ 2025-01-02 20:45           ` Ihor Radchenko
  2025-01-02 21:07             ` Eli Zaretskii
  0 siblings, 1 reply; 24+ messages in thread
From: Ihor Radchenko @ 2025-01-02 20:45 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 75292, eggert

Eli Zaretskii <eliz@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>





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
  2025-01-02 20:45           ` Ihor Radchenko
@ 2025-01-02 21:07             ` Eli Zaretskii
  2025-01-03 17:56               ` Ihor Radchenko
  0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2025-01-02 21:07 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: 75292, eggert

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: eggert@cs.ucla.edu, 75292@debbugs.gnu.org
> Date: Thu, 02 Jan 2025 20:45:57 +0000
> 
> Eli Zaretskii <eliz@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.





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
  2025-01-02 21:07             ` Eli Zaretskii
@ 2025-01-03 17:56               ` Ihor Radchenko
  2025-01-03 19:33                 ` Eli Zaretskii
  2025-01-03 20:21                 ` Eli Zaretskii
  0 siblings, 2 replies; 24+ messages in thread
From: Ihor Radchenko @ 2025-01-03 17:56 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 75292, eggert

Eli Zaretskii <eliz@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>





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
  2025-01-02 20:45 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-03 17:58   ` Ihor Radchenko
  2025-01-03 18:24     ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2025-01-03 19:11     ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 2 replies; 24+ messages in thread
From: Ihor Radchenko @ 2025-01-03 17:58 UTC (permalink / raw)
  To: Pip Cet; +Cc: 75292

Pip Cet <pipcet@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>





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
  2025-01-03 17:58   ` Ihor Radchenko
@ 2025-01-03 18:24     ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2025-01-03 19:47       ` Eli Zaretskii
  2025-01-03 19:11     ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 1 reply; 24+ messages in thread
From: Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-03 18:24 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: 75292

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

> Pip Cet <pipcet@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






^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
  2025-01-03 17:58   ` Ihor Radchenko
  2025-01-03 18:24     ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-03 19:11     ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 0 replies; 24+ messages in thread
From: Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-03 19:11 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: 75292

Pip Cet <pipcet@protonmail.com> writes:

> "Ihor Radchenko" <yantar92@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






^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
  2025-01-03 17:56               ` Ihor Radchenko
@ 2025-01-03 19:33                 ` Eli Zaretskii
  2025-01-04 14:12                   ` Ihor Radchenko
  2025-01-03 20:21                 ` Eli Zaretskii
  1 sibling, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2025-01-03 19:33 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: 75292, eggert

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: eggert@cs.ucla.edu, 75292@debbugs.gnu.org
> Date: Fri, 03 Jan 2025 17:56:46 +0000
> 
> Eli Zaretskii <eliz@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?





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
  2025-01-03 18:24     ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-03 19:47       ` Eli Zaretskii
  2025-01-03 19:51         ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2025-01-03 19:47 UTC (permalink / raw)
  To: Pip Cet; +Cc: 75292, yantar92

> Cc: 75292@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@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.





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
  2025-01-03 19:47       ` Eli Zaretskii
@ 2025-01-03 19:51         ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 0 replies; 24+ messages in thread
From: Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-03 19:51 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 75292, yantar92

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

>> Cc: 75292@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@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






^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
  2025-01-03 17:56               ` Ihor Radchenko
  2025-01-03 19:33                 ` Eli Zaretskii
@ 2025-01-03 20:21                 ` Eli Zaretskii
  2025-01-04 14:13                   ` Ihor Radchenko
  1 sibling, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2025-01-03 20:21 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: 75292, eggert

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: eggert@cs.ucla.edu, 75292@debbugs.gnu.org
> Date: Fri, 03 Jan 2025 17:56:46 +0000
> 
> Eli Zaretskii <eliz@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?





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
  2025-01-03 19:33                 ` Eli Zaretskii
@ 2025-01-04 14:12                   ` Ihor Radchenko
  2025-01-04 14:20                     ` Eli Zaretskii
  0 siblings, 1 reply; 24+ messages in thread
From: Ihor Radchenko @ 2025-01-04 14:12 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 75292, eggert

Eli Zaretskii <eliz@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>





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
  2025-01-03 20:21                 ` Eli Zaretskii
@ 2025-01-04 14:13                   ` Ihor Radchenko
  2025-01-04 14:22                     ` Eli Zaretskii
  0 siblings, 1 reply; 24+ messages in thread
From: Ihor Radchenko @ 2025-01-04 14:13 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 75292, eggert

Eli Zaretskii <eliz@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>





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
  2025-01-04 14:12                   ` Ihor Radchenko
@ 2025-01-04 14:20                     ` Eli Zaretskii
  0 siblings, 0 replies; 24+ messages in thread
From: Eli Zaretskii @ 2025-01-04 14:20 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: 75292, eggert

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: eggert@cs.ucla.edu, 75292@debbugs.gnu.org
> Date: Sat, 04 Jan 2025 14:12:50 +0000
> 
> Eli Zaretskii <eliz@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.





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
  2025-01-04 14:13                   ` Ihor Radchenko
@ 2025-01-04 14:22                     ` Eli Zaretskii
  2025-01-04 15:21                       ` Ihor Radchenko
  0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2025-01-04 14:22 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: 75292, eggert

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: eggert@cs.ucla.edu, 75292@debbugs.gnu.org
> Date: Sat, 04 Jan 2025 14:13:07 +0000
> 
> Eli Zaretskii <eliz@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?





^ permalink raw reply	[flat|nested] 24+ messages in thread

* bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
  2025-01-04 14:22                     ` Eli Zaretskii
@ 2025-01-04 15:21                       ` Ihor Radchenko
  0 siblings, 0 replies; 24+ messages in thread
From: Ihor Radchenko @ 2025-01-04 15:21 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 75292, eggert

Eli Zaretskii <eliz@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>





^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2025-01-04 15:21 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-01-02 17:54 bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address") Ihor Radchenko
2025-01-02 18:37 ` Eli Zaretskii
2025-01-02 18:42   ` Ihor Radchenko
2025-01-02 19:29     ` Eli Zaretskii
2025-01-02 19:37       ` Ihor Radchenko
2025-01-02 20:22         ` Eli Zaretskii
2025-01-02 20:45           ` Ihor Radchenko
2025-01-02 21:07             ` Eli Zaretskii
2025-01-03 17:56               ` Ihor Radchenko
2025-01-03 19:33                 ` Eli Zaretskii
2025-01-04 14:12                   ` Ihor Radchenko
2025-01-04 14:20                     ` Eli Zaretskii
2025-01-03 20:21                 ` Eli Zaretskii
2025-01-04 14:13                   ` Ihor Radchenko
2025-01-04 14:22                     ` Eli Zaretskii
2025-01-04 15:21                       ` Ihor Radchenko
2025-01-02 19:41       ` Paul Eggert
2025-01-02 20:35         ` Eli Zaretskii
2025-01-02 20:45 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-03 17:58   ` Ihor Radchenko
2025-01-03 18:24     ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-03 19:47       ` Eli Zaretskii
2025-01-03 19:51         ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-03 19:11     ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).