GNU bug report logs - #39962
27.0.90; Crash in Emacs 27.0.90

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 39962 in the body.
You can then email your comments to 39962 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: Pieter van Oostrum <pieter <at> vanoostrum.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 7 Mar 2020 00:55:39 +0100

[Message part 1 (text/plain, inline)]

I got a segmentation fault in Emacs. I read my email with VM (Viewmail), and I had a few fairly large mailboxes open when Emacs crashed. I had a few other cases where it crashed under similar circumstances, but other cases where it ran without problems.

I have the crashed instance under gdb, and I will keep it some time there to be able to extract more info. For the time being it looks like it is in the garbage collector.

The backtrace is very large, so it could be a stack overflow.

The 'bt full' output ran out of the buffer space in MacOS's Terminal window, so I have only the bottom part, but it seems to top part is mostly the same. And gdb got an error, so I cannot get more info out of it.

[backtrace_bottom (application/octet-stream, attachment)]

[Message part 3 (text/plain, inline)]

In GNU Emacs 27.0.90 (build 1, i686-apple-darwin10.0.0, NS appkit-1561.61 Version 10.13.6 (Build 17G11023))
 of 2020-03-06 built on cochabamba.vanoostrum.org
Repository revision: c5f255d68156926923232b1edadf50faac527861
Repository branch: HEAD
Windowing system distributor 'Apple', version 10.3.1561
System Description:  Mac OS X 10.13.6

Recent messages:
PRIVE<Mail>: 1471 messages, 75 new, 0 unread, 0 deleted
PRIVE<Mail>: Generating summary... done
PRIVE<Mail>: Decoding MIME message...
PRIVE<Mail>: Inlining text/html by emacs-w3m... done.
PRIVE<Mail>: Decoding MIME message... done
PRIVE<Mail>: Recreating summary... done
Mark set
PRIVE<Mail>: Checking for new mail...
PRIVE<Mail>: 1471 messages, 75 new, 0 unread, 0 deleted
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --build i686-apple-darwin10.0.0 --without-dbus --with-ns
 --enable-checking=yes,glyphs --enable-check-lisp-object-type
 'CFLAGS=-pipe -march=nocona -O0 -g3'
 build_alias=i686-apple-darwin10.0.0
 PKG_CONFIG_PATH=/opt/local/lib/pkgconfig/:/usr/X11R6/pkgconfig/:/usr/local/lib/pkgconfig/:/usr/lib/pkgconfig/'

Configured features:
RSVG GLIB NOTIFY KQUEUE ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS XIM
NS MODULES THREADS PDUMPER LCMS2

Important settings:
  value of $LC_CTYPE: UTF-8
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  smartparens-global-mode: t
  smartparens-mode: t
  flycheck-pos-tip-mode: t
  global-flycheck-mode: t
  flycheck-mode: t
  yas-minor-mode: t
  shell-dirtrack-mode: t
  TeX-PDF-mode: t
  recentf-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  global-so-long-mode: t
  show-paren-mode: t
  display-time-mode: t
  delete-selection-mode: t
  desktop-save-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  global-visual-line-mode: t
  visual-line-mode: t
  transient-mark-mode: t

Load-path shadows:
/Users/pieter/Library/Application Support/Emacs/site-lisp/isend-mode hides /Users/pieter/.emacs.d/elpa/isend-mode-20190201.832/isend-mode
/Users/pieter/.emacs.d/elpa/el-get-20181006.225/el-get-install hides /Users/pieter/.emacs.d/elpa/load-relative-20190601.1221/el-get-install
/Users/pieter/Library/Application Support/Emacs/site-lisp/web-mode hides /Users/pieter/.emacs.d/elpa/web-mode-20200301.1948/web-mode
/Users/pieter/Library/Application Support/Emacs/site-lisp/websocket hides /Users/pieter/.emacs.d/elpa/websocket-20200102.637/websocket
/Users/pieter/.emacs.d/elpa/org-9.3.3/ox hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ox
/Users/pieter/.emacs.d/elpa/org-9.3.3/ox-texinfo hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ox-texinfo
/Users/pieter/.emacs.d/elpa/org-9.3.3/ox-publish hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ox-publish
/Users/pieter/.emacs.d/elpa/org-9.3.3/ox-org hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ox-org
/Users/pieter/.emacs.d/elpa/org-9.3.3/ox-odt hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ox-odt
/Users/pieter/.emacs.d/elpa/org-9.3.3/ox-md hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ox-md
/Users/pieter/.emacs.d/elpa/org-9.3.3/ox-man hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ox-man
/Users/pieter/.emacs.d/elpa/org-9.3.3/ox-latex hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ox-latex
/Users/pieter/.emacs.d/elpa/org-9.3.3/ox-icalendar hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ox-icalendar
/Users/pieter/.emacs.d/elpa/org-9.3.3/ox-html hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ox-html
/Users/pieter/.emacs.d/elpa/org-9.3.3/ox-beamer hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ox-beamer
/Users/pieter/.emacs.d/elpa/org-9.3.3/ox-ascii hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ox-ascii
/Users/pieter/.emacs.d/elpa/org-9.3.3/org hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-version hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-version
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-timer hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-timer
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-tempo hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-tempo
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-table hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-table
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-src hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-src
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-protocol hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-protocol
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-plot hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-plot
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-pcomplete hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-pcomplete
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-num hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-num
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-mouse hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-mouse
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-mobile hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-mobile
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-macs hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-macs
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-macro hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-macro
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-loaddefs hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-loaddefs
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-list hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-list
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-lint hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-lint
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-keys hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-keys
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-install hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-install
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-inlinetask hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-inlinetask
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-indent hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-indent
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-id hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-id
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-habit hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-habit
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-goto hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-goto
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-footnote hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-footnote
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-feed hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-feed
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-faces hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-faces
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-entities hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-entities
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-element hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-element
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-duration hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-duration
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-datetree hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-datetree
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-ctags hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-ctags
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-crypt hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-crypt
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-compat hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-compat
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-colview hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-colview
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-clock hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-clock
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-capture hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-capture
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-attach hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-attach
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-attach-git hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-attach-git
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-archive hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-archive
/Users/pieter/.emacs.d/elpa/org-9.3.3/org-agenda hides /Applications/Emacs27.app/Contents/Resources/lisp/org/org-agenda
/Users/pieter/.emacs.d/elpa/org-9.3.3/ol hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ol
/Users/pieter/.emacs.d/elpa/org-9.3.3/ol-w3m hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ol-w3m
/Users/pieter/.emacs.d/elpa/org-9.3.3/ol-rmail hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ol-rmail
/Users/pieter/.emacs.d/elpa/org-9.3.3/ol-mhe hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ol-mhe
/Users/pieter/.emacs.d/elpa/org-9.3.3/ol-irc hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ol-irc
/Users/pieter/.emacs.d/elpa/org-9.3.3/ol-info hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ol-info
/Users/pieter/.emacs.d/elpa/org-9.3.3/ol-gnus hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ol-gnus
/Users/pieter/.emacs.d/elpa/org-9.3.3/ol-eww hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ol-eww
/Users/pieter/.emacs.d/elpa/org-9.3.3/ol-eshell hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ol-eshell
/Users/pieter/.emacs.d/elpa/org-9.3.3/ol-docview hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ol-docview
/Users/pieter/.emacs.d/elpa/org-9.3.3/ol-bibtex hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ol-bibtex
/Users/pieter/.emacs.d/elpa/org-9.3.3/ol-bbdb hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ol-bbdb
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-vala hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-vala
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-tangle hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-tangle
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-table hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-table
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-stan hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-stan
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-sqlite hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-sqlite
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-sql hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-sql
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-shen hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-shen
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-shell hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-shell
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-sed hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-sed
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-screen hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-screen
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-scheme hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-scheme
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-sass hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-sass
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-ruby hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-ruby
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-ref hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-ref
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-R hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-R
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-python hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-python
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-processing hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-processing
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-plantuml hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-plantuml
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-picolisp hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-picolisp
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-perl hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-perl
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-org hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-org
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-octave hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-octave
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-ocaml hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-ocaml
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-mscgen hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-mscgen
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-maxima hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-maxima
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-matlab hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-matlab
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-makefile hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-makefile
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-lua hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-lua
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-lob hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-lob
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-lisp hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-lisp
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-lilypond hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-lilypond
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-ledger hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-ledger
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-latex hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-latex
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-js hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-js
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-java hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-java
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-J hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-J
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-io hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-io
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-hledger hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-hledger
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-haskell hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-haskell
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-groovy hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-groovy
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-gnuplot hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-gnuplot
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-fortran hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-fortran
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-forth hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-forth
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-exp hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-exp
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-eval hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-eval
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-eshell hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-eshell
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-emacs-lisp hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-emacs-lisp
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-ebnf hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-ebnf
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-dot hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-dot
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-ditaa hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-ditaa
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-css hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-css
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-core hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-core
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-coq hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-coq
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-comint hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-comint
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-clojure hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-clojure
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-calc hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-calc
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-C hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-C
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-awk hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-awk
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-asymptote hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-asymptote
/Users/pieter/.emacs.d/elpa/org-9.3.3/ob-abc hides /Applications/Emacs27.app/Contents/Resources/lisp/org/ob-abc
/Users/pieter/Library/Application Support/Emacs/site-lisp/package hides /Applications/Emacs27.app/Contents/Resources/lisp/emacs-lisp/package
/Users/pieter/.emacs.d/elpa/company-20200206.2239/company hides /Users/pieter/Library/Application Support/Emacs/site-lisp/company-mode-master/company
/Users/pieter/.emacs.d/elpa/company-20200206.2239/company-xcode hides /Users/pieter/Library/Application Support/Emacs/site-lisp/company-mode-master/company-xcode
/Users/pieter/.emacs.d/elpa/company-20200206.2239/company-tempo hides /Users/pieter/Library/Application Support/Emacs/site-lisp/company-mode-master/company-tempo
/Users/pieter/.emacs.d/elpa/company-20200206.2239/company-template hides /Users/pieter/Library/Application Support/Emacs/site-lisp/company-mode-master/company-template
/Users/pieter/.emacs.d/elpa/company-20200206.2239/company-semantic hides /Users/pieter/Library/Application Support/Emacs/site-lisp/company-mode-master/company-semantic
/Users/pieter/.emacs.d/elpa/company-20200206.2239/company-oddmuse hides /Users/pieter/Library/Application Support/Emacs/site-lisp/company-mode-master/company-oddmuse
/Users/pieter/.emacs.d/elpa/company-20200206.2239/company-nxml hides /Users/pieter/Library/Application Support/Emacs/site-lisp/company-mode-master/company-nxml
/Users/pieter/.emacs.d/elpa/company-20200206.2239/company-keywords hides /Users/pieter/Library/Application Support/Emacs/site-lisp/company-mode-master/company-keywords
/Users/pieter/.emacs.d/elpa/company-20200206.2239/company-ispell hides /Users/pieter/Library/Application Support/Emacs/site-lisp/company-mode-master/company-ispell
/Users/pieter/.emacs.d/elpa/company-20200206.2239/company-gtags hides /Users/pieter/Library/Application Support/Emacs/site-lisp/company-mode-master/company-gtags
/Users/pieter/.emacs.d/elpa/company-20200206.2239/company-files hides /Users/pieter/Library/Application Support/Emacs/site-lisp/company-mode-master/company-files
/Users/pieter/.emacs.d/elpa/company-20200206.2239/company-etags hides /Users/pieter/Library/Application Support/Emacs/site-lisp/company-mode-master/company-etags
/Users/pieter/.emacs.d/elpa/company-20200206.2239/company-elisp hides /Users/pieter/Library/Application Support/Emacs/site-lisp/company-mode-master/company-elisp
/Users/pieter/.emacs.d/elpa/company-20200206.2239/company-eclim hides /Users/pieter/Library/Application Support/Emacs/site-lisp/company-mode-master/company-eclim
/Users/pieter/.emacs.d/elpa/company-20200206.2239/company-dabbrev hides /Users/pieter/Library/Application Support/Emacs/site-lisp/company-mode-master/company-dabbrev
/Users/pieter/.emacs.d/elpa/company-20200206.2239/company-dabbrev-code hides /Users/pieter/Library/Application Support/Emacs/site-lisp/company-mode-master/company-dabbrev-code
/Users/pieter/.emacs.d/elpa/company-20200206.2239/company-css hides /Users/pieter/Library/Application Support/Emacs/site-lisp/company-mode-master/company-css
/Users/pieter/.emacs.d/elpa/company-20200206.2239/company-clang hides /Users/pieter/Library/Application Support/Emacs/site-lisp/company-mode-master/company-clang
/Users/pieter/.emacs.d/elpa/company-20200206.2239/company-capf hides /Users/pieter/Library/Application Support/Emacs/site-lisp/company-mode-master/company-capf
/Users/pieter/.emacs.d/elpa/company-20200206.2239/company-abbrev hides /Users/pieter/Library/Application Support/Emacs/site-lisp/company-mode-master/company-abbrev
/Users/pieter/.emacs.d/elpa/tabbar-20180726.1735/tabbar hides /Users/pieter/Library/Application Support/Emacs/site-lisp/tabbar/tabbar
/Users/pieter/Library/Application Support/Emacs/site-lisp/vcard hides /Users/pieter/Library/Application Support/Emacs/site-lisp/vm-trunk/lisp/vcard

Features:
(shadow bbdb-message emacsbug w3m-cookie tapestry make-mode latexenc tcl
preview prv-emacs noutline outline font-latex tex-mode autorevert
filenotify vc-git diff-mode imenu company-oddmuse company-keywords
company-etags company-gtags company-dabbrev-code company-dabbrev
company-files company-cmake company-xcode company-clang company-eclim
company-template company-bbdb w3m-form vm-save vm-sort vm-pcrisis vm-w3m
mailalias nnmail gnus-int gnus-range mail-source vm-pine vm-rfaddons
vm-undo vm-minibuf bbdb-vm vm-message vm-macro vm-virtual
vm-summary-faces vm-pop utf7 vm-imap vm-thread vm-mouse vm-toolbar
vm-menu vm-crypto vm-summary bbdb-mua vm server wgrep smartparens-config
smartparens-text smartparens-python smartparens-latex smartparens
multiple-cursors mc-hide-unmatched-lines-mode mc-separate-operations
rectangular-region-mode mc-mark-pop mc-mark-more mc-cycle-cursors
mc-edit-lines multiple-cursors-core rect flycheck-pos-tip pos-tip
flycheck find-func dash yasnippet-classic-snippets cl-extra yasnippet
highlight-indentation company-capf company pcase help-fns radix-tree
help-mode elpy elpy-rpc pyvenv eshell esh-cmd esh-ext esh-opt esh-proc
esh-io esh-arg esh-module esh-groups esh-util elpy-shell elpy-profile
elpy-django s elpy-refactor python tramp-sh tramp tramp-loaddefs
trampver tramp-integration tramp-compat shell pcomplete parse-time
iso8601 ls-lisp ido grep files-x etags fileloop generator xref project
cus-edit info-look auctex-latexmk tex-buf latex easy-mmode edmacro
kmacro latex-flymake flymake-proc flymake compile comint ansi-color ring
warnings thingatpt tex-ispell tex-style tex ediff ediff-merg ediff-mult
ediff-wind ediff-diff ediff-help ediff-init ediff-util isend bbdb-vcard
bbdb-com crm vcard bbdb bbdb-site bbdb-loaddefs message-x message rmc
puny format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader cl w3m doc-view
image-mode exif timezone w3m-hist w3m-fb bookmark-w3m w3m-ems w3m-ccl
ccl w3m-favicon w3m-image w3m-proc w3m-util smtpmail sendmail vm-pgg
vm-motion vm-reply vm-mime vm-page vm-window vm-folder vm-misc pgg
pgg-parse pgg-def vm-autoloads vm-version vm-vars epa-file epa derived
epg epg-config dired-x dired dired-loaddefs neotree advice recentf
tree-widget undo-tree diff flyspell ispell so-long exec-path-from-shell
jka-compr paren gnus nnheader gnus-util rmail rmail-loaddefs rfc2047
rfc2045 ietf-drums text-property-search time-date mail-utils mm-util
mail-prsvr wid-edit elec-pair time delsel cus-start cus-load finder-inf
desktop frameset rx tex-site info package easymenu browse-url
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json subr-x map url-vars seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel term/ns-win ns-win
ucs-normalize mule-util term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads kqueue cocoa ns
lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 527676 60383)
 (symbols 48 46887 57)
 (strings 32 171693 7735)
 (string-bytes 1 7512765)
 (vectors 16 93148)
 (vector-slots 8 1836527 111626)
 (floats 8 262 60)
 (intervals 56 22274 3158)
 (buffers 1000 51))

-- 
Pieter van Oostrum <pieter <at> vanoostrum.org>
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pieter van Oostrum <pieter <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 07 Mar 2020 09:48:40 +0200

> Date: Sat, 7 Mar 2020 00:55:39 +0100
> From: Pieter van Oostrum <pieter <at> vanoostrum.org>
> 
> I got a segmentation fault in Emacs. I read my email with VM (Viewmail), and I had a few fairly large mailboxes open when Emacs crashed. I had a few other cases where it crashed under similar circumstances, but other cases where it ran without problems.
> 
> I have the crashed instance under gdb, and I will keep it some time there to be able to extract more info. For the time being it looks like it is in the garbage collector.
> 
> The backtrace is very large, so it could be a stack overflow.

Please show the first few backtrace frames (with "bt 10", for
example), they are important for trying to figure out whether this was
a stack overflow or something else.

What is the max stack size of your Emacs binary?

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, Pieter van Oostrum <pieter <at> vanoostrum.org>
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 07 Mar 2020 09:40:27 +0100

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

>> Date: Sat, 7 Mar 2020 00:55:39 +0100
>> From: Pieter van Oostrum <pieter <at> vanoostrum.org>
>> 
>> I got a segmentation fault in Emacs. I read my email with VM
>> (Viewmail), and I had a few fairly large mailboxes open when Emacs
>> crashed. I had a few other cases where it crashed under similar
>> circumstances, but other cases where it ran without problems.
>> 
>> I have the crashed instance under gdb, and I will keep it some time
>> there to be able to extract more info. For the time being it looks
>> like it is in the garbage collector.
>> 
>> The backtrace is very large, so it could be a stack overflow.
>
> Please show the first few backtrace frames (with "bt 10", for
> example), they are important for trying to figure out whether this was
> a stack overflow or something else.
>
> What is the max stack size of your Emacs binary?

It is the default nextstep stack size, I don't know how much that is.
It is configured with
./configure --build i686-apple-darwin10.0.0 \
      --without-dbus --with-ns \
	  --enable-checking='yes,glyphs' --enable-check-lisp-object-type \
	  CFLAGS="-pipe -march=nocona -O0 -g3"
that I picked up some time ago from a shell script to build nightlies.

But my gdb is now in a not-usable state, so I will have to reconstruct the crash to get more information.
-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, Pieter van Oostrum <pieter <at> vanoostrum.org>
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 07 Mar 2020 09:41:30 +0100

Or is it possible to attach a new gdb instance to the crashed Emacs?
-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org, pieter <at> vanoostrum.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 07 Mar 2020 12:51:55 +0200

> From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
> Cc: Pieter van Oostrum <pieter <at> vanoostrum.org>,  39962 <at> debbugs.gnu.org
> Date: Sat, 07 Mar 2020 09:41:30 +0100
> 
> Or is it possible to attach a new gdb instance to the crashed Emacs?

I don't think so, but there's nothing to lose if you try.

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, Pieter van Oostrum <pieter <at> vanoostrum.org>
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 07 Mar 2020 12:06:50 +0100

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

>> Date: Sat, 7 Mar 2020 00:55:39 +0100
>> From: Pieter van Oostrum <pieter <at> vanoostrum.org>
>> 
>> I got a segmentation fault in Emacs. I read my email with VM
>> (Viewmail), and I had a few fairly large mailboxes open when Emacs
>> crashed. I had a few other cases where it crashed under similar
>> circumstances, but other cases where it ran without problems.
>> 
>> I have the crashed instance under gdb, and I will keep it some time
>> there to be able to extract more info. For the time being it looks
>> like it is in the garbage collector.
>> 
>> The backtrace is very large, so it could be a stack overflow.
>
> Please show the first few backtrace frames (with "bt 10", for
> example), they are important for trying to figure out whether this was
> a stack overflow or something else.

I managed to reproduce another crash, but now it gives an assertion failure rather than a segmentation violation, which is much better IMHO.

insdel.c:295: Emacs fatal error: assertion failed: m->bytepos >= m->charpos && m->bytepos - m->charpos <= Z_BYTE - Z
--Type <RET> for more, q to quit, c to continue without paging--
insdel.c:295: Emacs fatal error: assertion failed: m->bytepos >= m->charpos && m->bytepos - m->charpos <= Z_BYTE - Z
--Type <RET> for more, q to quit, c to continue without paging--

Thread 3 hit Breakpoint 1, terminate_due_to_signal (sig=6, 
    backtrace_limit=2147483647) at emacs.c:371
371	  signal (sig, SIG_DFL);
(gdb) bt 10
#0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:371
#1  0x00000001002a4abb in die (
    msg=0x10050ff57 "m->bytepos >= m->charpos && m->bytepos - m->charpos <= Z_BYTE - Z", file=0x10050fdda "insdel.c", line=295) at alloc.c:7246
#2  0x0000000100233af4 in adjust_markers_for_insert (from=36399, 
    from_byte=36399, to=36401, to_byte=36401, before_markers=false)
    at insdel.c:294
#3  0x00000001002344d0 in insert_from_string_1 (string=XIL(0x15b29a904), 
    pos=0, pos_byte=0, nchars=2, nbytes=2, inherit=false, before_markers=false)
    at insdel.c:1060
#4  0x0000000100233e18 in insert_from_string (string=XIL(0x15b29a904), pos=0, 
    pos_byte=0, length=2, length_byte=2, inherit=false) at insdel.c:967
#5  0x00000001002ec4c2 in general_insert_function (
    insert_func=0x1002320b0 <insert>, 
    insert_from_string_func=0x100233d80 <insert_from_string>, inherit=false, 
    nargs=1, args=0x7ffeefbf5ce8) at editfns.c:1334
#6  0x00000001002ec1db in Finsert (nargs=1, args=0x7ffeefbf5ce8)
    at editfns.c:1370
#7  0x00000001003a7d53 in exec_byte_code (bytestr=XIL(0x10d25eb84), 
    vector=XIL(0x10e0fc055), maxdepth=make_fixnum(6), args_template=XIL(0), 
    nargs=0, args=0x0) at bytecode.c:1075
#8  0x0000000100317436 in funcall_lambda (fun=XIL(0x10e0fde35), nargs=1, 
    arg_vector=0x7ffeefbf6e80) at eval.c:3067
#9  0x0000000100314bfe in Ffuncall (nargs=2, args=0x7ffeefbf6e78)
    at eval.c:2796
(More stack frames follow...)
[New Thread 0x1c8f of process 52920]
[New Thread 0x521b of process 52920]

Lisp Backtrace:
Cannot access memory at address 0xcfeb5c0
(gdb) 

-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org, pieter <at> vanoostrum.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 07 Mar 2020 15:10:16 +0200

> From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
> Cc: Pieter van Oostrum <pieter <at> vanoostrum.org>,  39962 <at> debbugs.gnu.org
> Date: Sat, 07 Mar 2020 12:06:50 +0100
> 
> insdel.c:295: Emacs fatal error: assertion failed: m->bytepos >= m->charpos && m->bytepos - m->charpos <= Z_BYTE - Z
> --Type <RET> for more, q to quit, c to continue without paging--
> insdel.c:295: Emacs fatal error: assertion failed: m->bytepos >= m->charpos && m->bytepos - m->charpos <= Z_BYTE - Z

Please show the values of the variables involved in this assertion.

> Lisp Backtrace:
> Cannot access memory at address 0xcfeb5c0

This last bit is highly suspicious.  Something is going on in addition
to the assertion violation, and that something might be the actual
reason for the assertion.

Also note that this is no longer in GC, at least not directly.

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, pieter <at> vanoostrum.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 07 Mar 2020 16:06:09 +0100

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

>> From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
>> Cc: Pieter van Oostrum <pieter <at> vanoostrum.org>,  39962 <at> debbugs.gnu.org
>> Date: Sat, 07 Mar 2020 12:06:50 +0100
>> 
>> insdel.c:295: Emacs fatal error: assertion failed: m->bytepos >=
>> m->charpos && m->bytepos - m->charpos <= Z_BYTE - Z
>> --Type <RET> for more, q to quit, c to continue without paging--
>> insdel.c:295: Emacs fatal error: assertion failed: m->bytepos >=
>> m->charpos && m->bytepos - m->charpos <= Z_BYTE - Z
>
> Please show the values of the variables involved in this assertion.

(gdb) f 2
#2  0x0000000100233af4 in adjust_markers_for_insert (from=36399, 
    from_byte=36399, to=36401, to_byte=36401, before_markers=false)
    at insdel.c:294
294	      eassert (m->bytepos >= m->charpos
(gdb) p m
$1 = (struct Lisp_Marker *) 0x1609db830
(gdb) p m->bytepos
$2 = 11538
(gdb) p m->charpos
$3 = 0
(gdb) p Z_BYTE
No symbol "Z_BYTE" in current context.
(gdb) p Z
No symbol "Z" in current context.
(gdb) p current_buffer->text->z_byte
No symbol "current_buffer" in current context.
(gdb) p current_buffer
No symbol "current_buffer" in current context.
(gdb) p current_thread->m_current_buffer
$4 = (struct buffer *) 0x15b29a4b0
(gdb) p current_thread->m_current_buffer->text->z_byte
$5 = 529784
(gdb) p current_thread->m_current_buffer->text->z
$6 = 529778
(gdb)

>
>> Lisp Backtrace:
>> Cannot access memory at address 0xcfeb5c0
>
> This last bit is highly suspicious.  Something is going on in addition
> to the assertion violation, and that something might be the actual
> reason for the assertion.
>
> Also note that this is no longer in GC, at least not directly.

That's right. Although the cause of this might also have caused the GC problem when the assertion would not have caught it.
-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org, pieter <at> vanoostrum.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 07 Mar 2020 17:17:55 +0200

> From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
> Cc: 39962 <at> debbugs.gnu.org,  pieter <at> vanoostrum.org
> Date: Sat, 07 Mar 2020 16:06:09 +0100
> 
> (gdb) f 2
> #2  0x0000000100233af4 in adjust_markers_for_insert (from=36399, 
>     from_byte=36399, to=36401, to_byte=36401, before_markers=false)
>     at insdel.c:294
> 294	      eassert (m->bytepos >= m->charpos
> (gdb) p m
> $1 = (struct Lisp_Marker *) 0x1609db830
> (gdb) p m->bytepos
> $2 = 11538
> (gdb) p m->charpos
> $3 = 0
> (gdb) p Z_BYTE
> No symbol "Z_BYTE" in current context.
> (gdb) p Z
> No symbol "Z" in current context.
> (gdb) p current_buffer->text->z_byte
> No symbol "current_buffer" in current context.
> (gdb) p current_buffer
> No symbol "current_buffer" in current context.
> (gdb) p current_thread->m_current_buffer
> $4 = (struct buffer *) 0x15b29a4b0
> (gdb) p current_thread->m_current_buffer->text->z_byte
> $5 = 529784
> (gdb) p current_thread->m_current_buffer->text->z
> $6 = 529778
> (gdb)

Thanks.  Could it be that the marker in question is from another
buffer?  How does m->buffer compare with
current_thread->m_current_buffer?

> > Also note that this is no longer in GC, at least not directly.
> 
> That's right. Although the cause of this might also have caused the GC problem when the assertion would not have caught it.

Are you saying that GC is somewhere up the call-stack?  If so, can
you show that?

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, pieter <at> vanoostrum.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 07 Mar 2020 16:49:46 +0100

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

>> From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
>> Cc: 39962 <at> debbugs.gnu.org,  pieter <at> vanoostrum.org
>> Date: Sat, 07 Mar 2020 16:06:09 +0100
>> 
>> (gdb) f 2
>> #2  0x0000000100233af4 in adjust_markers_for_insert (from=36399, 
>>     from_byte=36399, to=36401, to_byte=36401, before_markers=false)
>>     at insdel.c:294
>> 294	      eassert (m->bytepos >= m->charpos
>> (gdb) p m
>> $1 = (struct Lisp_Marker *) 0x1609db830
>> (gdb) p m->bytepos
>> $2 = 11538
>> (gdb) p m->charpos
>> $3 = 0
>> (gdb) p Z_BYTE
>> No symbol "Z_BYTE" in current context.
>> (gdb) p Z
>> No symbol "Z" in current context.
>> (gdb) p current_buffer->text->z_byte
>> No symbol "current_buffer" in current context.
>> (gdb) p current_buffer
>> No symbol "current_buffer" in current context.
>> (gdb) p current_thread->m_current_buffer
>> $4 = (struct buffer *) 0x15b29a4b0
>> (gdb) p current_thread->m_current_buffer->text->z_byte
>> $5 = 529784
>> (gdb) p current_thread->m_current_buffer->text->z
>> $6 = 529778
>> (gdb)
>
> Thanks.  Could it be that the marker in question is from another
> buffer?  How does m->buffer compare with
> current_thread->m_current_buffer?

They are the same.

>> > Also note that this is no longer in GC, at least not directly.
>> 
>> That's right. Although the cause of this might also have caused the GC
>> problem when the assertion would not have caught it.
>
> Are you saying that GC is somewhere up the call-stack?  If so, can
> you show that?

No. What I meant is: if this is some kind of corruption of a data structure and if it wouldn't have been caught by the assertion it might later have caused problem in GC.
-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org, pieter <at> vanoostrum.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 07 Mar 2020 18:07:49 +0200

> From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
> Cc: 39962 <at> debbugs.gnu.org,  pieter <at> vanoostrum.org
> Date: Sat, 07 Mar 2020 16:49:46 +0100
> 
> >> (gdb) f 2
> >> #2  0x0000000100233af4 in adjust_markers_for_insert (from=36399, 
> >>     from_byte=36399, to=36401, to_byte=36401, before_markers=false)
> >>     at insdel.c:294
> >> 294	      eassert (m->bytepos >= m->charpos
> >> (gdb) p m
> >> $1 = (struct Lisp_Marker *) 0x1609db830
> >> (gdb) p m->bytepos
> >> $2 = 11538
> >> (gdb) p m->charpos
> >> $3 = 0
> >> (gdb) p Z_BYTE
> >> No symbol "Z_BYTE" in current context.
> >> (gdb) p Z
> >> No symbol "Z" in current context.
> >> (gdb) p current_buffer->text->z_byte
> >> No symbol "current_buffer" in current context.
> >> (gdb) p current_buffer
> >> No symbol "current_buffer" in current context.
> >> (gdb) p current_thread->m_current_buffer
> >> $4 = (struct buffer *) 0x15b29a4b0
> >> (gdb) p current_thread->m_current_buffer->text->z_byte
> >> $5 = 529784
> >> (gdb) p current_thread->m_current_buffer->text->z
> >> $6 = 529778
> >> (gdb)
> >
> > Thanks.  Could it be that the marker in question is from another
> > buffer?  How does m->buffer compare with
> > current_thread->m_current_buffer?
> 
> They are the same.

Wait a minute... how come m->charpos is zero?  That should never
happen, since buffer positions start from 1, and the value should be
close to m->bytepos anyway.

Can you show the full C backtrace?

> >> > Also note that this is no longer in GC, at least not directly.
> >> 
> >> That's right. Although the cause of this might also have caused the GC
> >> problem when the assertion would not have caught it.
> >
> > Are you saying that GC is somewhere up the call-stack?  If so, can
> > you show that?
> 
> No. What I meant is: if this is some kind of corruption of a data structure and if it wouldn't have been caught by the assertion it might later have caused problem in GC.

Anything's possible, but this is highly unlikely IME: GC is much more
sensitive to data corruption than anything else in Emacs.

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, pieter <at> vanoostrum.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 07 Mar 2020 18:21:47 +0100

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

>
> Wait a minute... how come m->charpos is zero?  That should never
> happen, since buffer positions start from 1, and the value should be
> close to m->bytepos anyway.
>
> Can you show the full C backtrace?
>
(gdb) bt
#0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:371
#1  0x00000001002a4abb in die (
    msg=0x10050ff57 "m->bytepos >= m->charpos && m->bytepos - m->charpos <= Z_BYTE - Z", file=0x10050fdda "insdel.c", line=295) at alloc.c:7246
#2  0x0000000100233af4 in adjust_markers_for_insert (from=36399, 
    from_byte=36399, to=36401, to_byte=36401, before_markers=false)
    at insdel.c:294
#3  0x00000001002344d0 in insert_from_string_1 (string=XIL(0x15b29a904), 
    pos=0, pos_byte=0, nchars=2, nbytes=2, inherit=false, before_markers=false)
    at insdel.c:1060
#4  0x0000000100233e18 in insert_from_string (string=XIL(0x15b29a904), pos=0, 
    pos_byte=0, length=2, length_byte=2, inherit=false) at insdel.c:967
#5  0x00000001002ec4c2 in general_insert_function (
    insert_func=0x1002320b0 <insert>, 
    insert_from_string_func=0x100233d80 <insert_from_string>, inherit=false, 
    nargs=1, args=0x7ffeefbf5ce8) at editfns.c:1334
#6  0x00000001002ec1db in Finsert (nargs=1, args=0x7ffeefbf5ce8)
    at editfns.c:1370
#7  0x00000001003a7d53 in exec_byte_code (bytestr=XIL(0x10d25eb84), 
    vector=XIL(0x10e0fc055), maxdepth=make_fixnum(6), args_template=XIL(0), 
    nargs=0, args=0x0) at bytecode.c:1075
#8  0x0000000100317436 in funcall_lambda (fun=XIL(0x10e0fde35), nargs=1, 
    arg_vector=0x7ffeefbf6e80) at eval.c:3067
#9  0x0000000100314bfe in Ffuncall (nargs=2, args=0x7ffeefbf6e78)
    at eval.c:2796
#10 0x00000001003a51df in exec_byte_code (bytestr=XIL(0x10d25ea24), 
    vector=XIL(0x10e0fb0a5), maxdepth=make_fixnum(3), args_template=XIL(0), 
    nargs=0, args=0x0) at bytecode.c:633
#11 0x0000000100317436 in funcall_lambda (fun=XIL(0x10e0fa1c5), nargs=0, 
    arg_vector=0x7ffeefbf7e50) at eval.c:3067
#12 0x0000000100314bfe in Ffuncall (nargs=1, args=0x7ffeefbf7e48)
    at eval.c:2796
#13 0x00000001003a51df in exec_byte_code (bytestr=XIL(0x10434b554), 
    vector=XIL(0x105c5b3c5), maxdepth=make_fixnum(4), args_template=XIL(0), 
    nargs=0, args=0x0) at bytecode.c:633
#14 0x0000000100317436 in funcall_lambda (fun=XIL(0x105c5b465), nargs=1, 
    arg_vector=0x7ffeefbf8e50) at eval.c:3067
#15 0x0000000100314bfe in Ffuncall (nargs=2, args=0x7ffeefbf8e48)
    at eval.c:2796
#16 0x0000000100315cb4 in call1 (fn=XIL(0x105c5b465), arg1=XIL(0xdbdceb0))
    at eval.c:2654
#17 0x000000010037aa6d in mapatoms_1 (sym=XIL(0xdbdceb0), 
    function=XIL(0x105c5b465)) at lread.c:4380
#18 0x000000010037a90e in map_obarray (obarray=XIL(0x10e182e95), 
    fn=0x10037aa50 <mapatoms_1>, arg=XIL(0x105c5b465)) at lread.c:4369
#19 0x000000010037aa31 in Fmapatoms (function=XIL(0x105c5b465), 
    obarray=XIL(0x10e182e95)) at lread.c:4391
--Type <RET> for more, q to quit, c to continue without paging--
#20 0x00000001003165cc in funcall_subr (subr=0x10055b5a8, numargs=2, 
    args=0x7ffeefbf91a0) at eval.c:2869
#21 0x0000000100314bae in Ffuncall (nargs=3, args=0x7ffeefbf9198)
    at eval.c:2794
#22 0x00000001003a51df in exec_byte_code (bytestr=XIL(0x10434b514), 
    vector=XIL(0x105c5b495), maxdepth=make_fixnum(6), args_template=XIL(0), 
    nargs=0, args=0x0) at bytecode.c:633
#23 0x0000000100317436 in funcall_lambda (fun=XIL(0x105c5b585), nargs=0, 
    arg_vector=0x7ffeefbfa1c0) at eval.c:3067
#24 0x0000000100314bfe in Ffuncall (nargs=1, args=0x7ffeefbfa1b8)
    at eval.c:2796
#25 0x00000001003a51df in exec_byte_code (bytestr=XIL(0x10d25f184), 
    vector=XIL(0x10d9f2205), maxdepth=make_fixnum(13), args_template=XIL(0), 
    nargs=0, args=0x0) at bytecode.c:633
#26 0x0000000100317436 in funcall_lambda (fun=XIL(0x10e0899b5), nargs=9, 
    arg_vector=0x7ffeefbfb610) at eval.c:3067
#27 0x0000000100314bfe in Ffuncall (nargs=10, args=0x7ffeefbfb608)
    at eval.c:2796
#28 0x00000001003a51df in exec_byte_code (bytestr=XIL(0x10d25e434), 
    vector=XIL(0x10d9f26d5), maxdepth=make_fixnum(11), args_template=XIL(0), 
    nargs=0, args=0x0) at bytecode.c:633
#29 0x0000000100317436 in funcall_lambda (fun=XIL(0x10e0ae1a5), nargs=2, 
    arg_vector=0x7ffeefbfc960) at eval.c:3067
#30 0x0000000100314bfe in Ffuncall (nargs=3, args=0x7ffeefbfc958)
    at eval.c:2796
#31 0x00000001002fd9ca in Ffuncall_interactively (nargs=3, args=0x7ffeefbfc958)
    at callint.c:254
#32 0x0000000100316486 in funcall_subr (subr=0x100558db8, numargs=3, 
    args=0x7ffeefbfc958) at eval.c:2847
#33 0x0000000100314bae in Ffuncall (nargs=4, args=0x7ffeefbfc950)
    at eval.c:2794
#34 0x0000000100314966 in Fapply (nargs=3, args=0x7ffeefbfd6f0) at eval.c:2424
#35 0x00000001002fdf30 in Fcall_interactively (function=XIL(0x4a62fc0), 
    record_flag=XIL(0), keys=XIL(0x160edff25)) at callint.c:342
#36 0x0000000100316602 in funcall_subr (subr=0x100558d88, numargs=3, 
    args=0x7ffeefbfd9c0) at eval.c:2872
#37 0x0000000100314bae in Ffuncall (nargs=4, args=0x7ffeefbfd9b8)
    at eval.c:2794
#38 0x00000001003a51df in exec_byte_code (bytestr=XIL(0x106a3df8c), 
    vector=XIL(0x106a3dadd), maxdepth=make_fixnum(13), 
    args_template=make_fixnum(1025), nargs=1, args=0x7ffeefbfea28)
    at bytecode.c:633
#39 0x0000000100316c95 in funcall_lambda (fun=XIL(0x106a3daad), nargs=1, 
    arg_vector=0x7ffeefbfea20) at eval.c:2989
#40 0x0000000100314bfe in Ffuncall (nargs=2, args=0x7ffeefbfea18)
    at eval.c:2796
#41 0x0000000100315cb4 in call1 (fn=XIL(0x3960), arg1=XIL(0x4a62fc0))
--Type <RET> for more, q to quit, c to continue without paging--
    at eval.c:2654
#42 0x00000001001c7640 in command_loop_1 () at keyboard.c:1463
#43 0x000000010030d5bf in internal_condition_case (
    bfun=0x1001c68e0 <command_loop_1>, handlers=XIL(0x90), 
    hfun=0x1001e9fa0 <cmd_error>) at eval.c:1355
#44 0x00000001001e9e81 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1091
#45 0x000000010030c6f8 in internal_catch (tag=XIL(0xc450), 
    func=0x1001e9e50 <command_loop_2>, arg=XIL(0)) at eval.c:1116
#46 0x00000001001c5955 in command_loop () at keyboard.c:1070
#47 0x00000001001c5727 in recursive_edit_1 () at keyboard.c:714
#48 0x00000001001c5bd6 in Frecursive_edit () at keyboard.c:786
#49 0x00000001001c273e in main (argc=1, argv=0x7ffeefbff660) at emacs.c:2054
[New Thread 0x2753 of process 52920]
[New Thread 0x2a7b of process 52920]

Lisp Backtrace:
Cannot access memory at address 0xcfeb5c0
(gdb) 

-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org, pieter <at> vanoostrum.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 07 Mar 2020 20:01:06 +0200

> From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
> Cc: 39962 <at> debbugs.gnu.org,  pieter <at> vanoostrum.org
> Date: Sat, 07 Mar 2020 18:21:47 +0100
> 
> > Can you show the full C backtrace?
> >
> (gdb) bt
> #0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:371
> #1  0x00000001002a4abb in die (
>     msg=0x10050ff57 "m->bytepos >= m->charpos && m->bytepos - m->charpos <= Z_BYTE - Z", file=0x10050fdda "insdel.c", line=295) at alloc.c:7246
> #2  0x0000000100233af4 in adjust_markers_for_insert (from=36399, 
>     from_byte=36399, to=36401, to_byte=36401, before_markers=false)
>     at insdel.c:294
> #3  0x00000001002344d0 in insert_from_string_1 (string=XIL(0x15b29a904), 
>     pos=0, pos_byte=0, nchars=2, nbytes=2, inherit=false, before_markers=false)
>     at insdel.c:1060
> #4  0x0000000100233e18 in insert_from_string (string=XIL(0x15b29a904), pos=0, 
>     pos_byte=0, length=2, length_byte=2, inherit=false) at insdel.c:967
> #5  0x00000001002ec4c2 in general_insert_function (
>     insert_func=0x1002320b0 <insert>, 
>     insert_from_string_func=0x100233d80 <insert_from_string>, inherit=false, 
>     nargs=1, args=0x7ffeefbf5ce8) at editfns.c:1334
> #6  0x00000001002ec1db in Finsert (nargs=1, args=0x7ffeefbf5ce8)
>     at editfns.c:1370

Thanks.  Since xbacktrace doesn't work in your case for some reason
(which is troublesome on its own), I will have to ask you to go to
every frame that calls Ffuncall, and do this:

  (gdb) p args[0]
  (gdb) xtype

If "xtype" says it's a symbol, then additionally do this immediately
after "xtype":

  (gdb) xsymbol

This will tell us which Lisp function was called in each such frame: a
poor man's Lisp backtrace.

Are these problems something you can trigger at will?

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, pieter <at> vanoostrum.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 07 Mar 2020 20:14:56 +0100

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

>
> Thanks.  Since xbacktrace doesn't work in your case for some reason
> (which is troublesome on its own), I will have to ask you to go to
> every frame that calls Ffuncall, and do this:
>
>   (gdb) p args[0]
>   (gdb) xtype
>
> If "xtype" says it's a symbol, then additionally do this immediately
> after "xtype":
>
>   (gdb) xsymbol
>
> This will tell us which Lisp function was called in each such frame: a
> poor man's Lisp backtrace.
>
> Are these problems something you can trigger at will?

Yes. Load a few quite big mailboxes in VM, and do some manipulation on them (like sorting).

Here is the info:

#9  0x0000000100314bfe in Ffuncall (nargs=2, args=0x7ffeefbf6e78)
    at eval.c:2796
2796	    val = funcall_lambda (fun, numargs, args + 1);
(gdb) p args[0]
$8 = XIL(0xcfeb420)
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$9 = (struct Lisp_Symbol *) 0xcfeb5b8
Cannot access memory at address 0xcfeb5c0
(gdb)

#15 0x0000000100314bfe in Ffuncall (nargs=2, args=0x7ffeefbf8e48)
    at eval.c:2796
2796	    val = funcall_lambda (fun, numargs, args + 1);
(gdb) p args[0]
$10 = XIL(0x105c5b465)
(gdb) xtype
Lisp_Vectorlike
PVEC_COMPILED
(gdb)

#21 0x0000000100314bae in Ffuncall (nargs=3, args=0x7ffeefbf9198)
    at eval.c:2794
2794	    val = funcall_subr (XSUBR (fun), numargs, args + 1);
(gdb) p args[0]
$11 = XIL(0x5fb6d60)
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$12 = (struct Lisp_Symbol *) 0x5fb6ef8
Cannot access memory at address 0x5fb6f00
(gdb)

#24 0x0000000100314bfe in Ffuncall (nargs=1, args=0x7ffeefbfa1b8)
    at eval.c:2796
2796	    val = funcall_lambda (fun, numargs, args + 1);
(gdb) p args[0]
$13 = XIL(0x3e34910)
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$14 = (struct Lisp_Symbol *) 0x3e34aa8
Cannot access memory at address 0x3e34ab0
(gdb)

#27 0x0000000100314bfe in Ffuncall (nargs=10, args=0x7ffeefbfb608)
    at eval.c:2796
2796	    val = funcall_lambda (fun, numargs, args + 1);
(gdb) p args[0]
$15 = XIL(0x56c6a00)
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$16 = (struct Lisp_Symbol *) 0x56c6b98
Cannot access memory at address 0x56c6ba0
(gdb)

#30 0x0000000100314bfe in Ffuncall (nargs=3, args=0x7ffeefbfc958)
    at eval.c:2796
2796	    val = funcall_lambda (fun, numargs, args + 1);
(gdb) p args[0]
$17 = XIL(0x4a62fc0)
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$18 = (struct Lisp_Symbol *) 0x4a63158
Cannot access memory at address 0x4a63160
(gdb)

#31 0x00000001002fd9ca in Ffuncall_interactively (nargs=3, args=0x7ffeefbfc958)
    at callint.c:254
254	  return unbind_to (speccount, Ffuncall (nargs, args));
(gdb) p args[0]
$19 = XIL(0x4a62fc0)
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$20 = (struct Lisp_Symbol *) 0x4a63158
Cannot access memory at address 0x4a63160
(gdb)

#33 0x0000000100314bae in Ffuncall (nargs=4, args=0x7ffeefbfc950)
    at eval.c:2794
2794	    val = funcall_subr (XSUBR (fun), numargs, args + 1);
(gdb) p args[0]
$21 = XIL(0x62a0)
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$22 = (struct Lisp_Symbol *) 0x6438
Cannot access memory at address 0x6440
(gdb)

#37 0x0000000100314bae in Ffuncall (nargs=4, args=0x7ffeefbfd9b8)
    at eval.c:2794
2794	    val = funcall_subr (XSUBR (fun), numargs, args + 1);
(gdb) p args[0]
$23 = XIL(0x5f592d0)
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$24 = (struct Lisp_Symbol *) 0x5f59468
Cannot access memory at address 0x5f59470
(gdb)

#40 0x0000000100314bfe in Ffuncall (nargs=2, args=0x7ffeefbfea18)
    at eval.c:2796
2796	    val = funcall_lambda (fun, numargs, args + 1);
(gdb) p args[0]
$25 = XIL(0x3960)
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$26 = (struct Lisp_Symbol *) 0x3af8
Cannot access memory at address 0x3b00
(gdb) 

There seems to be something fishy with the Lisp memory.
-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org, pieter <at> vanoostrum.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 07 Mar 2020 21:21:49 +0200

> From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
> Cc: 39962 <at> debbugs.gnu.org,  pieter <at> vanoostrum.org
> Date: Sat, 07 Mar 2020 20:14:56 +0100
> 
> #40 0x0000000100314bfe in Ffuncall (nargs=2, args=0x7ffeefbfea18)
>     at eval.c:2796
> 2796	    val = funcall_lambda (fun, numargs, args + 1);
> (gdb) p args[0]
> $25 = XIL(0x3960)
> (gdb) xtype
> Lisp_Symbol
> (gdb) xsymbol
> $26 = (struct Lisp_Symbol *) 0x3af8
> Cannot access memory at address 0x3b00
> (gdb) 
> 
> There seems to be something fishy with the Lisp memory.

Indeed.  Are you using the .gdbinit file from the same src directory
where you built Emacs?

The code which produces this crash runs mapatoms, so maybe it somehow
affects the symbols recorded in the obarray?  Can you identify the
Lisp code which is running here?

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, pieter <at> vanoostrum.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 07 Mar 2020 23:07:00 +0100

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

>> From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
>> Cc: 39962 <at> debbugs.gnu.org,  pieter <at> vanoostrum.org
>> Date: Sat, 07 Mar 2020 20:14:56 +0100
>> 
>> #40 0x0000000100314bfe in Ffuncall (nargs=2, args=0x7ffeefbfea18)
>>     at eval.c:2796
>> 2796	    val = funcall_lambda (fun, numargs, args + 1);
>> (gdb) p args[0]
>> $25 = XIL(0x3960)
>> (gdb) xtype
>> Lisp_Symbol
>> (gdb) xsymbol
>> $26 = (struct Lisp_Symbol *) 0x3af8
>> Cannot access memory at address 0x3b00
>> (gdb) 
>> 
>> There seems to be something fishy with the Lisp memory.
>
> Indeed.  Are you using the .gdbinit file from the same src directory
> where you built Emacs?

I run gdb from the src directory in the Emacs git repository. That's the standard .gdbinit that comes with the source.

In ~/.gdbinit I have:

add-auto-load-safe-path /Users/pieter/Projects/EMACS/src/.gdbinit which is the one I mentioned first.

> The code which produces this crash runs mapatoms, so maybe it somehow
> affects the symbols recorded in the obarray?  Can you identify the
> Lisp code which is running here?

I don't think I can find out what Lisp code was running.
-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pieter van Oostrum <pieter <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 7 Mar 2020 23:42:51 -0800

[Message part 1 (text/plain, inline)]

> In GNU Emacs 27.0.90 (build 1, i686-apple-darwin10.0.0, NS appkit-1561.61 Version 10.13.6 (Build 17G11023))

"i686"? Are you building a 32-bit executable? If so, does the problem go away if 
you build the more-typical 64-bit executable?

What compiler and version are you using? And what GDB version are you using?

> (gdb) p args[0]
> $25 = XIL(0x3960)
> (gdb) xtype
> Lisp_Symbol
> (gdb) xsymbol
> $26 = (struct Lisp_Symbol *) 0x3af8
> Cannot access memory at address 0x3b00

Something's wrong here. xsymbol should have output something like:

$8 = (struct Lisp_Symbol *) 0x10515f0 <lispsym+14688>

Try this instead (my examples show output on my Ubuntu 18.04 x86-64 platform):

(gdb) p args[0]
$25 = XIL(0x3960)
(gdb) xgetsym $25
(gdb) p $ptr
$27 = (struct Lisp_Symbol *) 0x10515f0 <lispsym+14688>

I assume yours will output something like "$27 = (struct Lisp_Symbol *) 0x3af8" 
instead. If so, try this:

(gdb) xgetptr $25
(gdb) p/x $ptr
$28 = 0x3960

Assuming you get that, try this:

(gdb) p ((struct Lisp_Symbol *) ((char *)lispsym + 0x3960))
$29 = (struct Lisp_Symbol *) 0x10515f0 <lispsym+14688>

I assume yours will output something like "$29 = (struct Lisp_Symbol *) 0x3af8" 
instead. If so, please try this:

(gdb) p (char *)lispsym
$30 = 0x104dc90 <lispsym> "\230\001"
(gdb) p (char *)&lispsym[0]
$31 = 0x104dc90 <lispsym> "\230\001"

My *guess* is that the above two lines will differ due either to a bug in your 
compiler or in your debugger. Your $30 will equal 408. If I'm right, the 
attached patch should work around your compiler/debugger bug. Of course this 
will merely help you debug Emacs; it won't fix the original bug you reported. So 
if this fixes your problem please redo the backtrace info Eli asked for.

[t.diff (text/x-patch, attachment)]

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 39962 <at> debbugs.gnu.org, Pieter van Oostrum <pieter <at> vanoostrum.org>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sun, 08 Mar 2020 10:34:20 +0100

Paul Eggert <eggert <at> cs.ucla.edu> writes:

>> In GNU Emacs 27.0.90 (build 1, i686-apple-darwin10.0.0, NS
>> appkit-1561.61 Version 10.13.6 (Build 17G11023))
>
> "i686"? Are you building a 32-bit executable? If so, does the problem go
> away if you build the more-typical 64-bit executable?

Sorry, I got that i686 stuff from a compile script I picked up somewhere. I'll try to recompile without that.

But, Emacs is still a 64-bit executable:
The file command gives:
Emacs: Mach-O 64-bit x86_64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>

> What compiler and version are you using? And what GDB version are you
> using?

gcc -v

Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 9.1.0 (clang-902.0.39.2)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

gdb version 9.1_0 with python3.7

>
>> (gdb) p args[0]
>> $25 = XIL(0x3960)
>> (gdb) xtype
>> Lisp_Symbol
>> (gdb) xsymbol
>> $26 = (struct Lisp_Symbol *) 0x3af8
>> Cannot access memory at address 0x3b00
>
> Something's wrong here. xsymbol should have output something like:
>
> $8 = (struct Lisp_Symbol *) 0x10515f0 <lispsym+14688>
>
> Try this instead (my examples show output on my Ubuntu 18.04 x86-64 platform):
>
> (gdb) p args[0]
> $25 = XIL(0x3960)
> (gdb) xgetsym $25
> (gdb) p $ptr
> $27 = (struct Lisp_Symbol *) 0x10515f0 <lispsym+14688>
>
> I assume yours will output something like "$27 = (struct Lisp_Symbol *)
> 0x3af8" instead. If so, try this:
>
> (gdb) xgetptr $25
> (gdb) p/x $ptr
> $28 = 0x3960
>
> Assuming you get that, try this:
>
> (gdb) p ((struct Lisp_Symbol *) ((char *)lispsym + 0x3960))
> $29 = (struct Lisp_Symbol *) 0x10515f0 <lispsym+14688>
>
> I assume yours will output something like "$29 = (struct Lisp_Symbol *)
> 0x3af8" instead. If so, please try this:
>
> (gdb) p (char *)lispsym
> $30 = 0x104dc90 <lispsym> "\230\001"
> (gdb) p (char *)&lispsym[0]
> $31 = 0x104dc90 <lispsym> "\230\001"
>
> My *guess* is that the above two lines will differ due either to a bug
> in your compiler or in your debugger. Your $30 will equal 408. If I'm
> right, the attached patch should work around your compiler/debugger bug.
> Of course this will merely help you debug Emacs; it won't fix the
> original bug you reported. So if this fixes your problem please redo the
> backtrace info Eli asked for.
>
Here is that output.


(gdb) xgetsym $25
(gdb) p $ptr
$31 = (struct Lisp_Symbol *) 0x3af8
(gdb) xgetptr $25
(gdb) p/x $ptr
$32 = 0x3960
(gdb) p ((struct Lisp_Symbol *) ((char *)lispsym + 0x3960))
$33 = (struct Lisp_Symbol *) 0x3af8
(gdb) p (char *)lispsym
$34 = 0x198 <error: Cannot access memory at address 0x198>
(gdb) p (char *)&lispsym[0]
'lispsym' has unknown type; cast it to its declared type
(gdb)

So I guess your patch might not help. Or is it worthwhile to try anyway?
But anyway, to use that patch, I have to create a new instance of the crash.
And then, I also will recompile first.
-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org, Pieter van Oostrum <pieter <at> vanoostrum.org>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sun, 8 Mar 2020 03:05:42 -0700

On 3/8/20 1:34 AM, Pieter van Oostrum wrote:
> (gdb) p (char *)lispsym
> $34 = 0x198 <error: Cannot access memory at address 0x198>
> (gdb) p (char *)&lispsym[0]
> 'lispsym' has unknown type; cast it to its declared type

lispsym's type is not known?! Either your compiler or your debugger has got a 
serious bug.

What does this command do?

(gdb) p (char *) &lispsym

Also, what does 'objdump -g emacs.o' say about lispsym? Mine says this:

emacs.o:     file format elf64-x86-64

Contents of the .debug_info section:

  Compilation Unit @ offset 0x0:
   Length:        0x1a196 (32-bit)
   Version:       4
   Abbrev Offset: 0x0
   Pointer Size:  8
 ...
 <1><8c7>: Abbrev Number: 70 (DW_TAG_structure_type)
    <8c8>   DW_AT_name        : (indirect string, offset: 0xcb81d): Lisp_Symbol
    <8cc>   DW_AT_byte_size   : 48
    <8cd>   DW_AT_alignment   : 8
    <8ce>   DW_AT_decl_file   : 4
    <8cf>   DW_AT_decl_line   : 805
    <8d1>   DW_AT_sibling     : <0x8e2>
 ...
 <1><8e2>: Abbrev Number: 8 (DW_TAG_pointer_type)
    <8e3>   DW_AT_byte_size   : 8
    <8e4>   DW_AT_type        : <0x8c7>
 ...
 <1><2969>: Abbrev Number: 122 (DW_TAG_array_type)
    <296a>   DW_AT_type        : <0x8c7>
    <296e>   DW_AT_alignment   : 8
    <296f>   DW_AT_sibling     : <0x297b>
 <2><2973>: Abbrev Number: 96 (DW_TAG_subrange_type)
    <2974>   DW_AT_type        : <0x2d>
    <2978>   DW_AT_upper_bound : 1279
 <2><297a>: Abbrev Number: 0
 <1><297b>: Abbrev Number: 9 (DW_TAG_variable)
    <297c>   DW_AT_name        : (indirect string, offset: 0x3c788): lispsym
    <2980>   DW_AT_decl_file   : 29
    <2981>   DW_AT_decl_line   : 1170
    <2983>   DW_AT_type        : <0x2969>
    <2987>   DW_AT_external    : 1
    <2987>   DW_AT_declaration : 1
 ...

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 39962 <at> debbugs.gnu.org, Pieter van Oostrum <pieter <at> vanoostrum.org>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sun, 08 Mar 2020 22:37:52 +0100

[Message part 1 (text/plain, inline)]

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> On 3/8/20 1:34 AM, Pieter van Oostrum wrote:
>> (gdb) p (char *)lispsym
>> $34 = 0x198 <error: Cannot access memory at address 0x198>
>> (gdb) p (char *)&lispsym[0]
>> 'lispsym' has unknown type; cast it to its declared type
>
> lispsym's type is not known?! Either your compiler or your debugger has
> got a serious bug.
>
> What does this command do?
>
> (gdb) p (char *) &lispsym

gdb) p (char *) &lispsym
$35 = 0x100a38d30 "\230\001"

By the way, the same comes up from
dsymutil   -dump-debug-map  emacs

      - { sym: _lispsym, binAddr: 0x0000000100A38D30, size: 0x00000000 }

>
> Also, what does 'objdump -g emacs.o' say about lispsym? Mine says this:
>
> emacs.o:     file format elf64-x86-64

objdump doesn't do Mach-O object files.

I did use dwarfdump which gives debug info. But it doesn't mention lispsym, although it gives other variables. 

[debuginfo2 (text/plain, attachment)]

[Message part 3 (text/plain, inline)]

-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 39962 <at> debbugs.gnu.org, Pieter van Oostrum <pieter <at> vanoostrum.org>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sun, 08 Mar 2020 22:58:21 +0100

lispsym comes up in dwarfdum *.o:

File: lread.o (x86_64)

0x000004b2:     TAG_variable [19]  
                 AT_name( "lispsym" )
                 AT_type( {0x000004c8} ( Lisp_Symbol[] ) )
                 AT_external( true )
                 AT_decl_file( "/Users/pieter/Projects/EMACS/src/globals.h" )
                 AT_decl_line( 1124 )
                 AT_location( [0x0000000000000000] )

-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org, Pieter van Oostrum <pieter <at> vanoostrum.org>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sun, 8 Mar 2020 15:34:07 -0700

[Message part 1 (text/plain, inline)]

On 3/8/20 2:37 PM, Pieter van Oostrum wrote:
> gdb) p (char *) &lispsym
> $35 = 0x100a38d30 "\230\001"

In that case, I expect the attached patch to work around the clang bug (and it 
is a bug in clang - clang is not outputting 'lispsym' debug info anywhere but in 
lread.o). Please give this patch a try and (assuming it works) go on to 
debugging the original problem.

[tt.diff (text/x-patch, attachment)]

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

From: Pieter van Oostrum <pieter <at> vanoostrum.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 39962 <at> debbugs.gnu.org, Pieter van Oostrum <pieter-l <at> vanoostrum.org>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Mon, 9 Mar 2020 00:58:18 +0100

Can I get this activated in a running gdb, or must I start a new gdb session?

-- 
Pieter van Oostrum

> On 8 Mar 2020, at 23:34, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> 
>> On 3/8/20 2:37 PM, Pieter van Oostrum wrote:
>> gdb) p (char *) &lispsym
>> $35 = 0x100a38d30 "\230\001"
> 
> In that case, I expect the attached patch to work around the clang bug (and it is a bug in clang - clang is not outputting 'lispsym' debug info anywhere but in lread.o). Please give this patch a try and (assuming it works) go on to debugging the original problem.
> <tt.diff>

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pieter van Oostrum <pieter <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org, Pieter van Oostrum <pieter-l <at> vanoostrum.org>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sun, 8 Mar 2020 17:01:52 -0700

On 3/8/20 4:58 PM, Pieter van Oostrum wrote:
> Can I get this activated in a running gdb, or must I start a new gdb session?

You can type the 'define xgetsym' into a running GDB. Something like this:

(gdb) define xgetsym
Redefine command "xgetsym"? (y or n) y
Type commands for definition of "xgetsym".
End with a line saying just "end".
>xgetptr $arg0
>set $ptr = ((struct Lisp_Symbol *) ((char *) &lispsym + $ptr))
>end
(gdb)

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

From: Pip Cet <pipcet <at> gmail.com>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Pieter van Oostrum <pieter <at> vanoostrum.org>,
 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Mon, 9 Mar 2020 04:00:01 +0000

On Sat, Mar 7, 2020 at 11:07 AM Pieter van Oostrum
<pieter-l <at> vanoostrum.org> wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> Date: Sat, 7 Mar 2020 00:55:39 +0100
> >> From: Pieter van Oostrum <pieter <at> vanoostrum.org>
> >>
> >> I got a segmentation fault in Emacs. I read my email with VM
> >> (Viewmail), and I had a few fairly large mailboxes open when Emacs
> >> crashed. I had a few other cases where it crashed under similar
> >> circumstances, but other cases where it ran without problems.

This is a hunch, but is it possible GC is somehow triggered either on
a secondary thread or in an event handler?

Can you uncomment the definitions of NSTRACE_ENABLED and
NSTRACE_ALL_GROUPS in nsterm.h and post the last few lines produced
that way before a crash? Also, what's the output of "i thr" in gdb
after that crash?

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 39962 <at> debbugs.gnu.org, Pieter van Oostrum <pieter <at> vanoostrum.org>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Mon, 09 Mar 2020 14:26:19 +0100

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> On 3/8/20 4:58 PM, Pieter van Oostrum wrote:
>> Can I get this activated in a running gdb, or must I start a new gdb session?
>
> You can type the 'define xgetsym' into a running GDB. Something like this:
>
> (gdb) define xgetsym
> Redefine command "xgetsym"? (y or n) y
> Type commands for definition of "xgetsym".
> End with a line saying just "end".
>>xgetptr $arg0
>>set $ptr = ((struct Lisp_Symbol *) ((char *) &lispsym + $ptr))
>>end
> (gdb)
>

OK, with this change I get sensible information:

(gdb) f 9
#9  0x0000000100314bfe in Ffuncall (nargs=2, args=0x7ffeefbf6e78)
    at eval.c:2796
2796	    val = funcall_lambda (fun, numargs, args + 1);
(gdb) p args[0]
$50 = XIL(0xcfeb420)
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$51 = (struct Lisp_Symbol *) 0x10da24150
"vm-set-summary-pointer"
(gdb) f 12
#12 0x0000000100314bfe in Ffuncall (nargs=1, args=0x7ffeefbf7e48)
    at eval.c:2796
2796	    val = funcall_lambda (fun, numargs, args + 1);
(gdb) p args[0]
$52 = XIL(0x3e349a0)
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$53 = (struct Lisp_Symbol *) 0x10486d6d0
"vm-do-needed-summary-rebuild"
(gdb) f 15
#15 0x0000000100314bfe in Ffuncall (nargs=2, args=0x7ffeefbf8e48)
    at eval.c:2796
2796	    val = funcall_lambda (fun, numargs, args + 1);
(gdb) p args[0]
$54 = XIL(0x105c5b465)
(gdb) xtype
Lisp_Vectorlike
PVEC_COMPILED
(gdb) f 21
#21 0x0000000100314bae in Ffuncall (nargs=3, args=0x7ffeefbf9198)
    at eval.c:2794
2794	    val = funcall_subr (XSUBR (fun), numargs, args + 1);
(gdb) p args[0]
$55 = XIL(0x5fb6d60)
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$56 = (struct Lisp_Symbol *) 0x1069efa90
"mapatoms"
(gdb) f 24
#24 0x0000000100314bfe in Ffuncall (nargs=1, args=0x7ffeefbfa1b8)
    at eval.c:2796
2796	    val = funcall_lambda (fun, numargs, args + 1);
(gdb) p args[0]
$57 = XIL(0x3e34910)
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$58 = (struct Lisp_Symbol *) 0x10486d640
"vm-update-summary-and-mode-line"
(gdb) f 27
#27 0x0000000100314bfe in Ffuncall (nargs=10, args=0x7ffeefbfb608)
    at eval.c:2796
2796	    val = funcall_lambda (fun, numargs, args + 1);
(gdb) p args[0]
$59 = XIL(0x56c6a00)
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$60 = (struct Lisp_Symbol *) 0x1060ff730
"vm"
(gdb) f 30
#30 0x0000000100314bfe in Ffuncall (nargs=3, args=0x7ffeefbfc958)
    at eval.c:2796
2796	    val = funcall_lambda (fun, numargs, args + 1);
(gdb) p args[0]
$61 = XIL(0x4a62fc0)
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$62 = (struct Lisp_Symbol *) 0x10549bcf0
"vm-visit-folder"
(gdb) f 31
#31 0x00000001002fd9ca in Ffuncall_interactively (nargs=3, args=0x7ffeefbfc958)
    at callint.c:254
254	  return unbind_to (speccount, Ffuncall (nargs, args));
(gdb) p args[0]
$63 = XIL(0x4a62fc0)
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$64 = (struct Lisp_Symbol *) 0x10549bcf0
"vm-visit-folder"
(gdb) f 33
#33 0x0000000100314bae in Ffuncall (nargs=4, args=0x7ffeefbfc950)
    at eval.c:2794
2794	    val = funcall_subr (XSUBR (fun), numargs, args + 1);
(gdb) p args[0]
$65 = XIL(0x62a0)
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$66 = (struct Lisp_Symbol *) 0x100a3efd0
"funcall-interactively"
(gdb) f 37
#37 0x0000000100314bae in Ffuncall (nargs=4, args=0x7ffeefbfd9b8)
    at eval.c:2794
2794	    val = funcall_subr (XSUBR (fun), numargs, args + 1);
(gdb) p args[0]
$67 = XIL(0x5f592d0)
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$68 = (struct Lisp_Symbol *) 0x106992000
"call-interactively"
(gdb) f 40
#40 0x0000000100314bfe in Ffuncall (nargs=2, args=0x7ffeefbfea18)
    at eval.c:2796
2796	    val = funcall_lambda (fun, numargs, args + 1);
(gdb) p args[0]
$69 = XIL(0x3960)
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$70 = (struct Lisp_Symbol *) 0x100a3c690
"command-execute"
(gdb) 

-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, pieter <at> vanoostrum.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Mon, 09 Mar 2020 19:10:02 +0200

> From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
> Cc: Pieter van Oostrum <pieter <at> vanoostrum.org>,  39962 <at> debbugs.gnu.org,  Eli
>  Zaretskii <eliz <at> gnu.org>
> Date: Mon, 09 Mar 2020 14:26:19 +0100
> 
> OK, with this change I get sensible information:
> 
> (gdb) f 9
> #9  0x0000000100314bfe in Ffuncall (nargs=2, args=0x7ffeefbf6e78)
>     at eval.c:2796
> 2796	    val = funcall_lambda (fun, numargs, args + 1);
> (gdb) p args[0]
> $50 = XIL(0xcfeb420)
> (gdb) xtype
> Lisp_Symbol
> (gdb) xsymbol
> $51 = (struct Lisp_Symbol *) 0x10da24150
> "vm-set-summary-pointer"

Thanks (and thanks to Paul for making GD|B usable in this case).

So does vm-set-summary-pointer indeed call mapatoms as part of its
job?  If so, can you show the relevant code fragment(s)?

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, pieter <at> vanoostrum.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Mon, 09 Mar 2020 20:48:48 +0100

[Message part 1 (text/plain, inline)]

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

>> From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
>> Cc: Pieter van Oostrum <pieter <at> vanoostrum.org>,  39962 <at> debbugs.gnu.org,  Eli
>>  Zaretskii <eliz <at> gnu.org>
>> Date: Mon, 09 Mar 2020 14:26:19 +0100
>> 
>> OK, with this change I get sensible information:
>> 
>> (gdb) f 9
>> #9  0x0000000100314bfe in Ffuncall (nargs=2, args=0x7ffeefbf6e78)
>>     at eval.c:2796
>> 2796	    val = funcall_lambda (fun, numargs, args + 1);
>> (gdb) p args[0]
>> $50 = XIL(0xcfeb420)
>> (gdb) xtype
>> Lisp_Symbol
>> (gdb) xsymbol
>> $51 = (struct Lisp_Symbol *) 0x10da24150
>> "vm-set-summary-pointer"
>
> Thanks (and thanks to Paul for making GD|B usable in this case).
>
> So does vm-set-summary-pointer indeed call mapatoms as part of its
> job?  If so, can you show the relevant code fragment(s)?

You probably mean vm-update-summary-and-mode-line (in frame #24). That one indeed calls mapatoms. It uses it to find all the buffers. I don't know why they don't use '(buffer-list)'.
And then that calls vm-do-needed-summary-rebuild which calls vm-set-summary-pointer

But anyway, this shouldn't crash emacs.

By the way, with Paul's patch, I now do get a normal Lisp backtrace. It's equal to what I got the hard way:

Lisp Backtrace:
"vm-set-summary-pointer" (0xefbf6e80)
"vm-do-needed-summary-rebuild" (0xefbf7e50)
0x5c5b460 PVEC_COMPILED
"mapatoms" (0xefbf91a0)
"vm-update-summary-and-mode-line" (0xefbfa1c0)
"vm" (0xefbfb610)
"vm-visit-folder" (0xefbfc960)
"funcall-interactively" (0xefbfc958)
"call-interactively" (0xefbfd9c0)
"command-execute" (0xefbfea20)
(gdb) 

I include the whole Elisp file with these functions.

[vm-summary.el (application/emacs-lisp, attachment)]

[Message part 3 (text/plain, inline)]

-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>, Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org, pieter <at> vanoostrum.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Mon, 9 Mar 2020 12:51:05 -0700

On 3/9/20 10:10 AM, Eli Zaretskii wrote:
> So does vm-set-summary-pointer indeed call mapatoms as part of its
> job?  If so, can you show the relevant code fragment(s)?


https://bazaar.launchpad.net/~vm/vm/trunk/view/head:/lisp/vm-folder.el#L514

though it's not clear whether this (the trunk version) is exactly the 
code he's running.

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, pieter <at> vanoostrum.org, 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Mon, 09 Mar 2020 22:32:39 +0100

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> On 3/9/20 10:10 AM, Eli Zaretskii wrote:
>> So does vm-set-summary-pointer indeed call mapatoms as part of its
>> job?  If so, can you show the relevant code fragment(s)?
>
>
> https://bazaar.launchpad.net/~vm/vm/trunk/view/head:/lisp/vm-folder.el#L514
>
> though it's not clear whether this (the trunk version) is exactly the
> code he's running.
>

Yes, I am running trunk, with one small patch:

--- /Users/pieter/Projects/vm/lisp/vm-mime.el.~1~	2020-01-24 16:44:18.000000000 +0100
+++ /Users/pieter/Projects/vm/lisp/vm-mime.el	2020-01-24 16:47:54.000000000 +0100
@@ -1102,7 +1102,7 @@
     (save-excursion
       (setq start (point-min))
       (while (not done)
-	(setq charset (get-text-property start 'vm-charset))
+	(setq charset (or (get-text-property start 'vm-charset) "us-ascii"))
 	(setq pos (next-single-property-change start 'vm-charset))
 	(or pos (setq pos (point-max) done t))
 	(if charset

-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Tue, 10 Mar 2020 11:52:04 +0100

I think we got stuck here. I don't think the problem is in the actual code that Emacs was executing at this point. Rather, the problem was that a marker was corrupted (m->charpos == 0).
That could have happened at a completely unrelated place. I have been trying to look in insdel.c and editfns.c to find something unusual, but to no avail.

I have also looked into the chain of markers in the buffer. There are quite a lot of them, and I haven't finished it, but what I have seen looks normal.

On the other hand, every edit action on the buffer must have adjusted the markers, so the corruption probably did not occur a long time ago.

Do you have any suggestion on what more to inspect?
-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, pieter <at> vanoostrum.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Tue, 10 Mar 2020 14:37:43 +0100

I wrote:

> You probably mean vm-update-summary-and-mode-line (in frame #24). That one indeed calls mapatoms. It uses it to find all the buffers. I don't know why they don't use '(buffer-list)'.
> And then that calls vm-do-needed-summary-rebuild which calls vm-set-summary-pointer

I checked, and VM uses mapatoms a lot, but always on its own obarrays. They use these as hash storages. So it shouldn't affect the Lisp obarray. So I was wrong about the (buffer-list).
-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Pip Cet <pipcet <at> gmail.com>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Tue, 10 Mar 2020 14:19:14 +0000

On Tue, Mar 10, 2020 at 10:53 AM Pieter van Oostrum
<pieter-l <at> vanoostrum.org> wrote:
> I think we got stuck here. I don't think the problem is in the actual code that Emacs was executing at this point. Rather, the problem was that a marker was corrupted (m->charpos == 0).

Inspecting the rest of the marker structure, in particular the header,
might let us know whether, as I suspect, the marker was wrongly freed
and re-allocated.

What does "x/32gx marker" produce?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Tue, 10 Mar 2020 17:10:01 +0200

> From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 39962 <at> debbugs.gnu.org
> Date: Tue, 10 Mar 2020 11:52:04 +0100
> 
> I think we got stuck here.

I think you are jumping to conclusions too quickly.  We've just
obtained the ability of putting GDB to a good use in this case, so we
are just starting to look seriously into this problem.  There are
still several things to try before we decide that we are stuck.

> I don't think the problem is in the actual code that Emacs was executing at this point. Rather, the problem was that a marker was corrupted (m->charpos == 0).
> That could have happened at a completely unrelated place. I have been trying to look in insdel.c and editfns.c to find something unusual, but to no avail.
> 
> I have also looked into the chain of markers in the buffer. There are quite a lot of them, and I haven't finished it, but what I have seen looks normal.
> 
> On the other hand, every edit action on the buffer must have adjusted the markers, so the corruption probably did not occur a long time ago.

Indeed, so the "completely unrelated code" which corrupts the marker
(if indeed this is what happens) must be quite close to what we see,
perhaps even in the same backtrace.  Too early to decide that's not
so.

Moreover, we don't even know that the code being executed is not the
culprit: it could be a compiler bug, for example.

> Do you have any suggestion on what more to inspect?

A few.

First, your original message indicated that you used the -march
compiler switch -- is that strictly necessary? can Emacs be built with
the default architecture, and if so, does the bug still happen?

Next, I see two places in the code which assigns the value to
m->charpos without validating it first.  Here's one:

  static void
  attach_marker (struct Lisp_Marker *m, struct buffer *b,
		 ptrdiff_t charpos, ptrdiff_t bytepos)
  {
    /* In a single-byte buffer, two positions must be equal.
       Otherwise, every character is at least one byte.  */
    if (BUF_Z (b) == BUF_Z_BYTE (b))
      eassert (charpos == bytepos);
    else
      eassert (charpos <= bytepos);

    m->charpos = charpos;  <<<<<<<<<<<<<<<<<<<<<
    m->bytepos = bytepos;

The other one is in alloc.c:build_marker.

So another idea is to put a conditional breakpoint there:

  (gdb) break marker.c:472 if charpos <= 0

and similarly for build_marker, and run with them to see whether you
ever get any of them to break.  If one of these breakpoints breaks, we
then will have our culprit.

The next idea depends on whether the offending marker always happens
in the same buffer and at the same position in the buffer's chain of
markers.  For example, is it always the first or the last marker?  If
it is, then you could put a watchpoint on that marker's charpos,
conditioned by the value being zero, and see if you can catch the code
which does that.

That's what I have for now.  I will try to come up with more ideas
later.

Thanks.

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 39962 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Tue, 10 Mar 2020 17:36:04 +0100

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

> On Tue, Mar 10, 2020 at 10:53 AM Pieter van Oostrum
> <pieter-l <at> vanoostrum.org> wrote:
>> I think we got stuck here. I don't think the problem is in the actual
>> code that Emacs was executing at this point. Rather, the problem was
>> that a marker was corrupted (m->charpos == 0).
>
> Inspecting the rest of the marker structure, in particular the header,
> might let us know whether, as I suspect, the marker was wrongly freed
> and re-allocated.
>
> What does "x/32gx marker" produce?

#2  0x0000000100233af4 in adjust_markers_for_insert (from=36399, 
    from_byte=36399, to=36401, to_byte=36401, before_markers=false)
    at insdel.c:294
294	      eassert (m->bytepos >= m->charpos
(gdb) x/32gx m
0x1609db830:	0x4000000003005000	0x000000015b29a4b0
0x1609db840:	0x00000001609dba44	0x00000001609db800
0x1609db850:	0x0000000000000000	0x0000000000002d12
0x1609db860:	0x4000000003005000	0x000000015b29a4b0
0x1609db870:	0x0000000000000000	0x00000001609db830
0x1609db880:	0x0000000000002d6f	0x0000000000002d6f
0x1609db890:	0x4000000004001003	0x00000001609db835
0x1609db8a0:	0x00000001609db865	0x00000001054d2723
0x1609db8b0:	0x00000001609db7a0	0x0000000000000000
0x1609db8c0:	0x4000000003005000	0x000000015b29a4b0
0x1609db8d0:	0x0000000000000010	0x00000001609db860
0x1609db8e0:	0x0000000000002d12	0x0000000000002d12
0x1609db8f0:	0x4000000003005000	0x000000015b29a4b0
0x1609db900:	0x0000000000000008	0x00000001609db8c0
0x1609db910:	0x0000000000002d6f	0x0000000000002d6f
0x1609db920:	0x4000000003005000	0x000000015b29a4b0
(gdb) p m->charpos
$186 = 0
(gdb) 

-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Tue, 10 Mar 2020 19:23:26 +0100

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

>> From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 39962 <at> debbugs.gnu.org
>> Date: Tue, 10 Mar 2020 11:52:04 +0100
>> 
>> I think we got stuck here.
>
> I think you are jumping to conclusions too quickly.  We've just
> obtained the ability of putting GDB to a good use in this case, so we
> are just starting to look seriously into this problem.  There are
> still several things to try before we decide that we are stuck.

I meant: in the current session.
I have done a recompile with cleaner options.

I will start a new session and set the breakpoints/suggestions mentioned
below, and then try to have it crash/trigger the bug again.
I will keep the other session around as long as my laptop can bear it.

>> I don't think the problem is in the actual code that Emacs was
>> executing at this point. Rather, the problem was that a marker was
>> corrupted (m->charpos == 0).
>> That could have happened at a completely unrelated place. I have been
>> trying to look in insdel.c and editfns.c to find something unusual,
>> but to no avail.
>> 
>> I have also looked into the chain of markers in the buffer. There are
>> quite a lot of them, and I haven't finished it, but what I have seen
>> looks normal.
>> 
>> On the other hand, every edit action on the buffer must have adjusted
>> the markers, so the corruption probably did not occur a long time ago.
>
> Indeed, so the "completely unrelated code" which corrupts the marker
> (if indeed this is what happens) must be quite close to what we see,
> perhaps even in the same backtrace.  Too early to decide that's not
> so.
>
> Moreover, we don't even know that the code being executed is not the
> culprit: it could be a compiler bug, for example.
>
>> Do you have any suggestion on what more to inspect?
>
> A few.
>
> First, your original message indicated that you used the -march
> compiler switch -- is that strictly necessary? can Emacs be built with
> the default architecture, and if so, does the bug still happen?
>
> Next, I see two places in the code which assigns the value to
> m->charpos without validating it first.  Here's one:
>
>   static void
>   attach_marker (struct Lisp_Marker *m, struct buffer *b,
> 		 ptrdiff_t charpos, ptrdiff_t bytepos)
>   {
>     /* In a single-byte buffer, two positions must be equal.
>        Otherwise, every character is at least one byte.  */
>     if (BUF_Z (b) == BUF_Z_BYTE (b))
>       eassert (charpos == bytepos);
>     else
>       eassert (charpos <= bytepos);
>
>     m->charpos = charpos;  <<<<<<<<<<<<<<<<<<<<<
>     m->bytepos = bytepos;
>
> The other one is in alloc.c:build_marker.
>
> So another idea is to put a conditional breakpoint there:
>
>   (gdb) break marker.c:472 if charpos <= 0
>
> and similarly for build_marker, and run with them to see whether you
> ever get any of them to break.  If one of these breakpoints breaks, we
> then will have our culprit.
>
> The next idea depends on whether the offending marker always happens
> in the same buffer and at the same position in the buffer's chain of
> markers.  For example, is it always the first or the last marker?  If
> it is, then you could put a watchpoint on that marker's charpos,
> conditioned by the value being zero, and see if you can catch the code
> which does that.
>
> That's what I have for now.  I will try to come up with more ideas
> later.
>
> Thanks.

-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Wed, 11 Mar 2020 01:22:28 -0700

On 3/10/20 3:52 AM, Pieter van Oostrum wrote:
> Rather, the problem was that a marker was corrupted (m->charpos == 0).

GDB's 'watch -l' command is often a good way to find out when a particular 
location unexpectedly became 0.

https://sourceware.org/gdb/current/onlinedocs/gdb/Set-Watchpoints.html

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

From: Pip Cet <pipcet <at> gmail.com>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Wed, 11 Mar 2020 14:32:09 +0000

On Tue, Mar 10, 2020 at 4:36 PM Pieter van Oostrum
<pieter-l <at> vanoostrum.org> wrote:
> #2  0x0000000100233af4 in adjust_markers_for_insert (from=36399,
>     from_byte=36399, to=36401, to_byte=36401, before_markers=false)
>     at insdel.c:294
> 294           eassert (m->bytepos >= m->charpos
> (gdb) x/32gx m
> 0x1609db830:    0x4000000003005000      0x000000015b29a4b0
> 0x1609db840:    0x00000001609dba44      0x00000001609db800
> 0x1609db850:    0x0000000000000000      0x0000000000002d12
> 0x1609db860:    0x4000000003005000      0x000000015b29a4b0
> 0x1609db870:    0x0000000000000000      0x00000001609db830
> 0x1609db880:    0x0000000000002d6f      0x0000000000002d6f
> 0x1609db890:    0x4000000004001003      0x00000001609db835
> 0x1609db8a0:    0x00000001609db865      0x00000001054d2723
> 0x1609db8b0:    0x00000001609db7a0      0x0000000000000000

So it's a marker marking the start position of an overlay. It's
allocated in the same vector block as other markers and overlays, so
maybe there used to be an overlay at 0x1609db830 and someone set its
"next" pointer to NULL after it had been freed?

I'm not sure this is related, but in looking over the code I spotted a
bit of confusion in the garbage collector between checking a buffer is
"live" (in the sense that it has not been killed) and checking it's
live in the sense that it needs to be preserved by GC: evaluating this
code in *scratch* causes a segfault at least some of the time.

(prog1
    (let ((temp-buffer (generate-new-buffer " *temp*")))
      (prog1
          temp-buffer
        (kill-buffer temp-buffer)
        (setq temp-buffer nil)))
  (garbage-collect))

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 39962 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Wed, 11 Mar 2020 16:16:16 +0100

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

> I'm not sure this is related, but in looking over the code I spotted a
> bit of confusion in the garbage collector between checking a buffer is
> "live" (in the sense that it has not been killed) and checking it's
> live in the sense that it needs to be preserved by GC: evaluating this
> code in *scratch* causes a segfault at least some of the time.
>
> (prog1
>     (let ((temp-buffer (generate-new-buffer " *temp*")))
>       (prog1
>           temp-buffer
>         (kill-buffer temp-buffer)
>         (setq temp-buffer nil)))
>   (garbage-collect))

That crash shouldn't happen, so it has to be found what causes it.

Looking through the code of kill-buffer, I also spotted something that
surprised me. I don't thing it is related to the current crash, but I
want to mention it anyway.

In various places we find the following or similar code:

    /* If the hooks have killed the buffer, exit now.  */
    if (!BUFFER_LIVE_P (b))
      return unbind_to (count, Qt);

But after running the Query functions (line 1724-1732) this is not done.
Now in most cases, because these functions just return true or false,
they will not kill the buffer, but there is no restriction
for them to do that.
So before checking whether the buffer is still modified (line
1734-1742), shouldn't it also check if the buffer is still live?


-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Pip Cet <pipcet <at> gmail.com>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Wed, 11 Mar 2020 15:43:18 +0000

[Message part 1 (text/plain, inline)]

On Wed, Mar 11, 2020 at 3:16 PM Pieter van Oostrum
<pieter-l <at> vanoostrum.org> wrote:
> > (prog1
> >     (let ((temp-buffer (generate-new-buffer " *temp*")))
> >       (prog1
> >           temp-buffer
> >         (kill-buffer temp-buffer)
> >         (setq temp-buffer nil)))
> >   (garbage-collect))
>
> That crash shouldn't happen, so it has to be found what causes it.

The attached patch should fix things.

[0001-Don-t-GC-killed-buffers-that-are-still-reachable.patch (text/x-patch, attachment)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pip Cet <pipcet <at> gmail.com>, Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Wed, 11 Mar 2020 08:51:15 -0700

On 3/11/20 8:43 AM, Pip Cet wrote:
> The attached patch should fix things.

Thanks for writing that. Pieter, does that work for you? Either way, I suppose 
we should install this into the emacs-27 branch.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 39962 <at> debbugs.gnu.org, pieter-l <at> vanoostrum.org, pipcet <at> gmail.com
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Wed, 11 Mar 2020 18:21:26 +0200

> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Wed, 11 Mar 2020 08:51:15 -0700
> Cc: 39962 <at> debbugs.gnu.org
> 
> On 3/11/20 8:43 AM, Pip Cet wrote:
> > The attached patch should fix things.
> 
> Thanks for writing that. Pieter, does that work for you? Either way, I suppose 
> we should install this into the emacs-27 branch.

I'd prefer not to.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 39962 <at> debbugs.gnu.org, pieter-l <at> vanoostrum.org, eggert <at> cs.ucla.edu
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Wed, 11 Mar 2020 19:52:13 +0200

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Wed, 11 Mar 2020 15:43:18 +0000
> Cc: 39962 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
> 
> From e98749389a1cc81f3c4479170d223cc8c9871288 Mon Sep 17 00:00:00 2001
> From: Pip Cet <pipcet <at> gmail.com>
> Date: Wed, 11 Mar 2020 15:29:19 +0000
> Subject: [PATCH] Don't GC killed buffers that are still reachable
> 
> * src/alloc.c (live_buffer_holding): Return killed buffers, which are
> still "live" for GC purposes.

Thanks.

Did you audit all the users of this function, both direct and
indirect?  Some of them are outside of GC.

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

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, pieter-l <at> vanoostrum.org, eggert <at> cs.ucla.edu
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Wed, 11 Mar 2020 18:53:55 +0000

On Wed, Mar 11, 2020 at 5:52 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > * src/alloc.c (live_buffer_holding): Return killed buffers, which are
> > still "live" for GC purposes.
>
> Thanks.
>
> Did you audit all the users of this function, both direct and
> indirect?  Some of them are outside of GC.

Thanks for the comment; I just re-checked, and they look fine to me.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 39962 <at> debbugs.gnu.org, pieter-l <at> vanoostrum.org, eggert <at> cs.ucla.edu
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Wed, 11 Mar 2020 21:34:26 +0200

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Wed, 11 Mar 2020 18:53:55 +0000
> Cc: pieter-l <at> vanoostrum.org, 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
> 
> > Did you audit all the users of this function, both direct and
> > indirect?  Some of them are outside of GC.
> 
> Thanks for the comment; I just re-checked, and they look fine to me.

??? Fine in what way?  One of the callers is live_buffer_p, which is
called by valid_lisp_object_p, which is expected to return a special
value for dead buffers.  Your change will break that, no?

IOW, you are changing the semantics of "live buffer", for a reason
that can hardly justify that.  That doesn't sound economical to me; it
will certainly make it much harder for me to agree to make the change
on the release branch.  The problem you are trying to solve is rare
and obscure, since this code was with us since 20 years ago without
anyone bumping into it, so changing it to solve such a rare problem,
and on the release branch on top of that, doesn't sound right to me.

Am I missing something?

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 39962 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Wed, 11 Mar 2020 21:03:14 +0100

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

> On Wed, Mar 11, 2020 at 3:16 PM Pieter van Oostrum
> <pieter-l <at> vanoostrum.org> wrote:
>> > (prog1
>> >     (let ((temp-buffer (generate-new-buffer " *temp*")))
>> >       (prog1
>> >           temp-buffer
>> >         (kill-buffer temp-buffer)
>> >         (setq temp-buffer nil)))
>> >   (garbage-collect))
>>
>> That crash shouldn't happen, so it has to be found what causes it.
>
> The attached patch should fix things.

With this patch I still get a crash. This time a sementation violation again in the garbage collector. So that doesn't solve the problem I am encountering.

GDB bailed out for some reason (I get the impression that GDB on MacOS isn't very stable).
But here is what I got:


Thread 3 received signal SIGSEGV, Segmentation fault.
0x00000001002b5000 in vector_marked_p (v=0x160249fd0) at alloc.c:3715
3715	  if (pdumper_object_p (v))
(gdb) bt 10
#0  0x00000001002b5000 in vector_marked_p (v=0x160249fd0) at alloc.c:3715
#1  0x00000001002b369f in mark_object (arg=XIL(0x160249fd5)) at alloc.c:6480
#2  0x00000001002b5813 in mark_vectorlike (header=0x160249f50) at alloc.c:6157
#3  0x00000001002b391a in mark_object (arg=XIL(0x160249f55)) at alloc.c:6566
#4  0x00000001002b5813 in mark_vectorlike (header=0x160249e60) at alloc.c:6157
#5  0x00000001002b391a in mark_object (arg=XIL(0x160249e65)) at alloc.c:6566
#6  0x00000001002b3d33 in mark_object (arg=XIL(0x167929583)) at alloc.c:6628
#7  0x00000001002b3b04 in mark_object (arg=XIL(0x515dcd0)) at alloc.c:6585
#8  0x00000001002b5813 in mark_vectorlike (header=0x11ddd20f0) at alloc.c:6157
#9  0x00000001002b391a in mark_object (arg=XIL(0x11ddd20f5)) at alloc.c:6566
(More stack frames follow...)
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0x7ffeef270f7f

Command aborted.
An error occurred while in a function called from GDB.
Evaluation of the expression containing the function
(backtrace_top) will be abandoned.
When the function is done executing, GDB will silently stop.

[1]+  Stopped                 gdb ~/Projects/Emacs/nextstep/Emacs.app/Contents/MacOS/Emacs
src $ bt
-bash: bt: command not found
src $ fg
gdb ~/Projects/Emacs/nextstep/Emacs.app/Contents/MacOS/Emacs
(gdb) bt
#0  backtrace_top () at eval.c:176
Backtrace stopped: Cannot access memory at address 0x7ffeef270f68
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0x7ffeef270edf
Cannot insert breakpoint 0.
Cannot access memory at address 0x7ffeef270f7f

Command aborted.
An error occurred while in a function called from GDB.
Evaluation of the expression containing the function
(backtrace_top) will be abandoned.
When the function is done executing, GDB will silently stop.

[1]+  Stopped                 gdb ~/Projects/Emacs/nextstep/Emacs.app/Contents/MacOS/Emacs

-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, pieter-l <at> vanoostrum.org, eggert <at> cs.ucla.edu
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Thu, 12 Mar 2020 10:32:16 +0000

On Wed, Mar 11, 2020 at 7:34 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > > Did you audit all the users of this function, both direct and
> > > indirect?  Some of them are outside of GC.
> >
> > Thanks for the comment; I just re-checked, and they look fine to me.
>
> ??? Fine in what way?

It doesn't affect visible behavior of any callers, except in the case
where the previous behavior was buggy.

> One of the callers is live_buffer_p, which is
> called by valid_lisp_object_p, which is expected to return a special
> value for dead buffers.  Your change will break that, no?

Who's expecting valid_lisp_object_p to return a special value for dead buffers?

The only calls to it that I see check merely whether the return value
is != 0 or > 0, both of which tests remain invariant. Am I missing
something?

What confused me is that live_buffer and live_buffer_p both exist and
do wildly different things. But as you correctly point out, we
shouldn't fix that on the release branch.

> IOW, you are changing the semantics of "live buffer", for a reason
> that can hardly justify that.

I'm most certainly not changing the semantics of live_buffer, if
that's what you're worried about. I am changing the semantics of
live_buffer_p, which is an internal function, and my initial patch
also changed the return value of valid_lisp_object_p, to another value
that would be treated equivalently. If there are objections to that,
we can easily distinguish the two cases.

And I think "so we don't collect reachable objects" is a fairly good
reason, generally.

> That doesn't sound economical to me; it
> will certainly make it much harder for me to agree to make the change
> on the release branch.

I think you've made perfectly clear that you don't want this patch on
the release branch, though I'm not sure I understand the reasoning for
that.

> The problem you are trying to solve is rare

I think it would become much less rare with lexical binding in effect,
at least when the code's byte-compiled.

> and obscure,

IME, test cases often are, even if they test for real and common problems.

> since this code was with us since 20 years ago without
> anyone bumping into it,

That we know of. They might have just accrued it to random Emacs crashes.

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

From: Pip Cet <pipcet <at> gmail.com>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Thu, 12 Mar 2020 13:55:56 +0000

On Wed, Mar 11, 2020 at 8:03 PM Pieter van Oostrum
<pieter-l <at> vanoostrum.org> wrote:
> With this patch I still get a crash. This time a sementation violation again in the garbage collector. So that doesn't solve the problem I am encountering.

It's not always the same crash, is it? That one looks like it might be
a stack overflow.

> Thread 3 received signal SIGSEGV, Segmentation fault.

Thread 3 is the main thread? What does "i thr" say, if gdb supports it on MacOS?

> 0x00000001002b5000 in vector_marked_p (v=0x160249fd0) at alloc.c:3715
> 3715      if (pdumper_object_p (v))
> (gdb) bt 10
> #0  0x00000001002b5000 in vector_marked_p (v=0x160249fd0) at alloc.c:3715
> #1  0x00000001002b369f in mark_object (arg=XIL(0x160249fd5)) at alloc.c:6480
> #2  0x00000001002b5813 in mark_vectorlike (header=0x160249f50) at alloc.c:6157
> #3  0x00000001002b391a in mark_object (arg=XIL(0x160249f55)) at alloc.c:6566
> #4  0x00000001002b5813 in mark_vectorlike (header=0x160249e60) at alloc.c:6157
> #5  0x00000001002b391a in mark_object (arg=XIL(0x160249e65)) at alloc.c:6566
> #6  0x00000001002b3d33 in mark_object (arg=XIL(0x167929583)) at alloc.c:6628
> #7  0x00000001002b3b04 in mark_object (arg=XIL(0x515dcd0)) at alloc.c:6585
> #8  0x00000001002b5813 in mark_vectorlike (header=0x11ddd20f0) at alloc.c:6157
> #9  0x00000001002b391a in mark_object (arg=XIL(0x11ddd20f5)) at alloc.c:6566
> (More stack frames follow...)
> Warning:
> Cannot insert breakpoint 0.
> Cannot access memory at address 0x7ffeef270f7f

My guess is 0x7ffeef270000 is your stack's guard page... Can you print
$rsp to confirm?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 39962 <at> debbugs.gnu.org, pieter-l <at> vanoostrum.org, eggert <at> cs.ucla.edu
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Thu, 12 Mar 2020 17:23:29 +0200

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Thu, 12 Mar 2020 10:32:16 +0000
> Cc: pieter-l <at> vanoostrum.org, 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
> 
> On Wed, Mar 11, 2020 at 7:34 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > > > Did you audit all the users of this function, both direct and
> > > > indirect?  Some of them are outside of GC.
> > >
> > > Thanks for the comment; I just re-checked, and they look fine to me.
> >
> > ??? Fine in what way?
> 
> It doesn't affect visible behavior of any callers, except in the case
> where the previous behavior was buggy.

I guess we have different notions of "visible" and "buggy".

> What confused me is that live_buffer and live_buffer_p both exist and
> do wildly different things.

They do very similar things, AFAICT.

> I'm most certainly not changing the semantics of live_buffer, if
> that's what you're worried about. I am changing the semantics of
> live_buffer_p, which is an internal function, and my initial patch
> also changed the return value of valid_lisp_object_p, to another value
> that would be treated equivalently. If there are objections to that,
> we can easily distinguish the two cases.

I actually don't understand why we need to make such a change.

> And I think "so we don't collect reachable objects" is a fairly good
> reason, generally.

I didn't say it wasn't good, I said it didn't justify the proposed
solution.

How about if you tell more about the root cause of the crash you are
trying to solve, and why disregarding the fact that a buffer is killed
is the way to solve it?

> > The problem you are trying to solve is rare
> 
> I think it would become much less rare with lexical binding in effect,
> at least when the code's byte-compiled.

That remains to be seen.

> > since this code was with us since 20 years ago without
> > anyone bumping into it,
> 
> That we know of. They might have just accrued it to random Emacs crashes.

Then again, they might not.  We don't really have any evidence to that
effect, all we know is that the code survived virtually intact since
the day it was written.

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 39962 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Thu, 12 Mar 2020 19:13:10 +0100

[Message part 1 (text/plain, inline)]

Pip Cet <pipcet <at> gmail.com> writes:
>
> My guess is 0x7ffeef270000 is your stack's guard page... Can you print
> $rsp to confirm?

Sorry, because of the erratic behaviour of GDB I killed that one. I have a new segfault in the GC. It is a long stack trace, so it could be a stack overflow. And, by the way, I had the two brakpoints set for the assignments to marker->charpos that Eli suggested, but they were not triggered. I have dumped a part of the stack trace below.

[GDBOutput.txt (text/plain, attachment)]

[Message part 3 (text/plain, inline)]

-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Pip Cet <pipcet <at> gmail.com>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Thu, 12 Mar 2020 20:00:13 +0000

[Message part 1 (text/plain, inline)]

On Thu, Mar 12, 2020 at 6:13 PM Pieter van Oostrum
<pieter-l <at> vanoostrum.org> wrote:
> > My guess is 0x7ffeef270000 is your stack's guard page... Can you print
> > $rsp to confirm?
>
> Sorry, because of the erratic behaviour of GDB I killed that one. I have a new segfault in the GC. It is a long stack trace, so it could be a stack overflow. And, by the way, I had the two brakpoints set for the assignments to marker->charpos that Eli suggested, but they were not triggered. I have dumped a part of the stack trace below.

Thanks! I believe that solves it.

That indeed looks like a stack overflow.

Here's some speculation about what I think is happening:

We're seeing deep recursion in the garbage collector. If you look at
the tag bits of the objects marked by mark_object, you'll notice the
sequence is

symbol - cons - vectorlike - vectorlike - symbol - cons - vectorlike -
vectorlike - ...

That means there are thousands of symbols referring to values which
again contain symbols, and so on.

I suspect this code in vm-summary.el, or similar code, at least:

(defun vm-make-message ()
  "Create a new blank message struct."
  (let ((mvec (make-vector 5 nil))
    sym)
    (vm-set-softdata-of mvec (make-vector vm-softdata-vector-length nil))
    (vm-set-location-data-of
     mvec (make-vector vm-location-data-vector-length nil))
    (vm-set-mirror-data-of
     mvec (make-vector vm-mirror-data-vector-length nil))
    (vm-set-message-id-number-of mvec (int-to-string vm-message-id-number))
    (vm-increment vm-message-id-number)
    (vm-set-buffer-of mvec (current-buffer))
    ;; We use an uninterned symbol here as a level of indirection
    ;; from a purely self-referential structure.  This is
    ;; necessary so that Emacs debugger can be used on this
    ;; program.
    (setq sym (make-symbol "<<>>"))
    (set sym mvec)
    (vm-set-real-message-sym-of mvec sym)
    (vm-set-mirrored-message-sym-of mvec sym)
    ;; Another uninterned symbol for the virtual messages list.
    (setq sym (make-symbol "<v>"))
    (set sym nil)
    (vm-set-virtual-messages-sym-of mvec sym)
    ;; Another uninterned symbol for the reverse link
    ;; into the message list.
    (setq sym (make-symbol "<--"))
    (vm-set-reverse-link-sym-of mvec sym)
    mvec ))

Essentially, that code is building a singly-linked list of message
vectors, but the links go via symbols rather than directly to the next
message. The garbage collector isn't written for that case, and
recurses rather than iterating, causing the stack overflow.

The first attachment to this message is an Elisp file which does the
same thing, by creating thousands of symbols. On GNU/Linux, with
fairly default standard stack size settings, I get a segfault after
some 85,000 symbols have been created.

The second attachment is a patch which is
1. untested
2. a dirty workaround
3. not intended for inclusion in the master branch
4. not intended for inclusion in the emacs-27 branch.

It's possible this patch will work around the problem and result in a
different bug, or, less optimistically, fix this bug. With the patch,
I'm able to make it through the first 2^20 iterations of
symbol-crash.el without a segfault.

[symbol-crash.el (text/x-emacs-lisp, attachment)]

[0001-recurse-into-symbol-values-rather-than-along-the-sym.patch (text/x-patch, attachment)]

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

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, pieter-l <at> vanoostrum.org, eggert <at> cs.ucla.edu
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Thu, 12 Mar 2020 20:36:10 +0000

On Thu, Mar 12, 2020 at 3:23 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > > > > Did you audit all the users of this function, both direct and
> > > > > indirect?  Some of them are outside of GC.
> > > >
> > > > Thanks for the comment; I just re-checked, and they look fine to me.
> > >
> > > ??? Fine in what way?
> >
> > It doesn't affect visible behavior of any callers, except in the case
> > where the previous behavior was buggy.
>
> I guess we have different notions of "visible"

Please say something about your notion of "visible". It doesn't affect
any of the existing C callers of valid_lisp_object_p. Are you talking
about printing valid_lisp_object_p(x) in a debugger, and not getting
the expected value? Or something else?

> and "buggy".

It avoids segfaults or random memory corruption. How is that not "buggy"?

> > I'm most certainly not changing the semantics of live_buffer, if
> > that's what you're worried about. I am changing the semantics of
> > live_buffer_p, which is an internal function, and my initial patch
> > also changed the return value of valid_lisp_object_p, to another value
> > that would be treated equivalently. If there are objections to that,
> > we can easily distinguish the two cases.
>
> I actually don't understand why we need to make such a change.

Which change? Treating the two cases differently? Because the garbage
collector needs to know whether an object is reachable, not whether
it's still a live buffer.

valid_lisp_object_p is currently documented to return 2 for a killed
buffer and 1 for a live buffer, which is weird since they're both
valid. It also returns 1 for some fake objects which aren't actually
valid:

(gdb) p current_thread->m_current_buffer
$3 = (struct buffer *) 0x555556694b10
(gdb) p valid_lisp_object_p(0x555556694b15)
$4 = 1
(gdb) p valid_lisp_object_p(0x555556694b25)
$5 = 1

Luckily, no one relies upon that documented mis-feature, so it's safe
to remove it.

> > And I think "so we don't collect reachable objects" is a fairly good
> > reason, generally.
>
> I didn't say it wasn't good, I said it didn't justify the proposed
> solution.

> How about if you tell more about the root cause of the crash you are
> trying to solve, and why disregarding the fact that a buffer is killed
> is the way to solve it?

I can try.

The garbage collector needs to mark all reachable objects. It can get
away with marking unreachable objects (and does so, for overlays in
killed buffers), but not marking a reachable object is a serious bug.

If a buffer is live, everything is fine.

If a buffer has been killed but is unreachable, everything is fine; it
will be collected by GC.

If a buffer has been killed but is reachable through mark_object,
everything is fine.

If a buffer has been killed but is reachable only through
mark_maybe_object, we fail to mark it.

We should mark it. In fact, whether a buffer object is marked should
depend only on whether it's reachable, not whether it's "live" in some
other sense.

That's all my patch does.

> > > The problem you are trying to solve is rare
> >
> > I think it would become much less rare with lexical binding in effect,
> > at least when the code's byte-compiled.
>
> That remains to be seen.

How about we put out the fire rather than waiting to see whether it
causes any damage? And, if we can agree to do so, what would you like
a patch which is actually meant for inclusion into the emacs-27 branch
(my previous patch wasn't, obviously) to look like?

> > > since this code was with us since 20 years ago without
> > > anyone bumping into it,
> >
> > That we know of. They might have just accrued it to random Emacs crashes.
>
> Then again, they might not.  We don't really have any evidence to that
> effect, all we know is that the code survived virtually intact since
> the day it was written.

I have no idea what you're trying to get at here.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, pipcet <at> gmail.com
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Fri, 13 Mar 2020 09:58:51 +0200

> From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
> Date: Thu, 12 Mar 2020 19:13:10 +0100
> Cc: 39962 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
> 
> > My guess is 0x7ffeef270000 is your stack's guard page... Can you print
> > $rsp to confirm?
> 
> Sorry, because of the erratic behaviour of GDB I killed that one. I have a new segfault in the GC. It is a long stack trace, so it could be a stack overflow. And, by the way, I had the two brakpoints set for the assignments to marker->charpos that Eli suggested, but they were not triggered. I have dumped a part of the stack trace below.
> 
> Thread 3 received signal SIGSEGV, Segmentation fault.
> dead_object () at ./lisp.h:1303
> 1303	  return make_lisp_ptr (NULL, Lisp_String);
> (gdb) bt
> #0  dead_object () at ./lisp.h:1303
> #1  0x00000001002b6179 in deadp (x=XIL(0x11e331fb5)) at alloc.c:433
> #2  0x00000001002b80d4 in live_cons_holding (m=0x16033ead0, p=0x170c5c770)
>     at alloc.c:4365

That does look like a stack overflow, since there's nothing at line
1303 of lisp.h which could cause a segfault, except a function call
(which pushes stuff onto the stack).  It doesn't seem to be related to
the crashes due to markers (unless those were somehow caused by  stack
overflow).

Can you enlarge the run-time stack size of the Emacs binary, e.g., by
using ulimit?  We may need to do that by default in the build command,
but just to check it is effective, could you run for a while with an
enlarged stack and see if crashes in GC go away?

Thanks.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 39962 <at> debbugs.gnu.org, pieter-l <at> vanoostrum.org, eggert <at> cs.ucla.edu
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Fri, 13 Mar 2020 10:09:00 +0200

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Thu, 12 Mar 2020 20:00:13 +0000
> Cc: 39962 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
> 
> The first attachment to this message is an Elisp file which does the
> same thing, by creating thousands of symbols. On GNU/Linux, with
> fairly default standard stack size settings, I get a segfault after
> some 85,000 symbols have been created.

The default stack size on GNU/Linux is 2MB, right?  Maybe it's high
time we raised that, what with the memory size today's machines
routinely have at their disposal.  FWIW, the MS-Windows build have
been using a 8MB run-time stack for a very long time.

Of course, given enough recursive data structures we can always crash
the current GC the way it is implemented.  But the question is how
many such recursive symbols are there in Pieter's sessions? are they
anywhere near the 1000000000 mark you used in your test program?  IOW,
I think we need to know how close we are in real-life sessions to the
dangerous mark.

Maybe this is also worth reporting to VM developers.  They might
consider changing their implementation to avoid these problems.

Thanks.

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

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, pieter-l <at> vanoostrum.org, eggert <at> cs.ucla.edu
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Fri, 13 Mar 2020 08:39:41 +0000

On Fri, Mar 13, 2020 at 8:08 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > The first attachment to this message is an Elisp file which does the
> > same thing, by creating thousands of symbols. On GNU/Linux, with
> > fairly default standard stack size settings, I get a segfault after
> > some 85,000 symbols have been created.
>
> The default stack size on GNU/Linux is 2MB, right?  Maybe it's high
> time we raised that, what with the memory size today's machines
> routinely have at their disposal.

Well, it's just virtual memory, so raising it shouldn't be a problem,
though apparently the stack size is limited to 4 GB.

> FWIW, the MS-Windows build have
> been using a 8MB run-time stack for a very long time.

"ulimit -s" produces 9788 here.

> Of course, given enough recursive data structures we can always crash
> the current GC the way it is implemented.

Absolutely.

> But the question is how
> many such recursive symbols are there in Pieter's sessions? are they
> anywhere near the 1000000000 mark you used in your test program?

If I'm reading the code correctly, the recursion depth is equal to the
number of messages in VM's list, so a few tens of thousands of symbols
seem possible. Not anywhere near a billion, though.

> IOW,
> I think we need to know how close we are in real-life sessions to the
> dangerous mark.

It should certainly be possible to warn the user when stack usage
during GC exceeded a given percentage of the possible stack size;
hopefully, that would happen at least once before a crash.

It would also be possible to modify the code in sysdep.c to report
when it has detected an unrecoverable stack overflow.

> Maybe this is also worth reporting to VM developers.  They might
> consider changing their implementation to avoid these problems.

I think this is a VM-specific problem, not anything that we should be
changing GC code on the release branch for.

Do you happen to know whether anyone is looking at gcc -fsplit-stack
support for Emacs? That would avoid the problem entirely but allow us
to keep our current GC code.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 39962 <at> debbugs.gnu.org, pieter-l <at> vanoostrum.org, eggert <at> cs.ucla.edu
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Fri, 13 Mar 2020 11:19:41 +0200

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Fri, 13 Mar 2020 08:39:41 +0000
> Cc: pieter-l <at> vanoostrum.org, 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
> 
> > The default stack size on GNU/Linux is 2MB, right?  Maybe it's high
> > time we raised that, what with the memory size today's machines
> > routinely have at their disposal.
> 
> Well, it's just virtual memory, so raising it shouldn't be a problem,
> though apparently the stack size is limited to 4 GB.

We have a long way to go before we get anywhere near that limit ;-)

> > FWIW, the MS-Windows build have
> > been using a 8MB run-time stack for a very long time.
> 
> "ulimit -s" produces 9788 here.

That's system-wide, but what is the stack size that the Emacs binary
can use?

> > But the question is how
> > many such recursive symbols are there in Pieter's sessions? are they
> > anywhere near the 1000000000 mark you used in your test program?
> 
> If I'm reading the code correctly, the recursion depth is equal to the
> number of messages in VM's list, so a few tens of thousands of symbols
> seem possible. Not anywhere near a billion, though.

Your test code crashes before 100,000, so the question is how many
tens of thousands of messages does Pieter's session have?  If it's
anywhere near 100,000, then we are really close to the limit, but I
suspect it's much lower, which might suggest the recursion in VM is
much deeper.

> It should certainly be possible to warn the user when stack usage
> during GC exceeded a given percentage of the possible stack size;
> hopefully, that would happen at least once before a crash.
> 
> It would also be possible to modify the code in sysdep.c to report
> when it has detected an unrecoverable stack overflow.

How do you do that without consuming more stack?

Btw, we already have stack-overflow protection in Emacs, but it is
disabled during GC.

> Do you happen to know whether anyone is looking at gcc -fsplit-stack
> support for Emacs?

I'm not aware of anyone working on that, no.  But I also am not sure
this is something we should do.  First, it only works on GNU/Linux,
while Pieter is on macOS AFAIU.  And second, if you read the GCC
manual's description of that switch, you will see some serious
caveats, which could mean using that option might produce an
unworkable binary.  IOW, it doesn't sound to me as an option that is
recommended for general-purpose use.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 39962 <at> debbugs.gnu.org, pieter-l <at> vanoostrum.org, eggert <at> cs.ucla.edu
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Fri, 13 Mar 2020 11:39:54 +0200

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Thu, 12 Mar 2020 20:36:10 +0000
> Cc: pieter-l <at> vanoostrum.org, 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
> 
> > > It doesn't affect visible behavior of any callers, except in the case
> > > where the previous behavior was buggy.
> >
> > I guess we have different notions of "visible"
> 
> Please say something about your notion of "visible". It doesn't affect
> any of the existing C callers of valid_lisp_object_p. Are you talking
> about printing valid_lisp_object_p(x) in a debugger, and not getting
> the expected value? Or something else?

I'm talking about the behavior documented in the commentary.

> > and "buggy".
> 
> It avoids segfaults or random memory corruption. How is that not "buggy"?

That's not the issue here.  You said the proposed change didn't change
the behavior "except where it was buggy"; I'm saying that it changes
the behavior unrelated to this bug, where previous behavior was not
buggy by any measure.

> > > I'm most certainly not changing the semantics of live_buffer, if
> > > that's what you're worried about. I am changing the semantics of
> > > live_buffer_p, which is an internal function, and my initial patch
> > > also changed the return value of valid_lisp_object_p, to another value
> > > that would be treated equivalently. If there are objections to that,
> > > we can easily distinguish the two cases.
> >
> > I actually don't understand why we need to make such a change.
> 
> Which change? Treating the two cases differently? Because the garbage
> collector needs to know whether an object is reachable, not whether
> it's still a live buffer.

So why does it not consider the buffer reachable in this case?  The
call to live_buffer_p is just one attempt to identify it as reachable;
there are (or at least should be) others.

> valid_lisp_object_p is currently documented to return 2 for a killed
> buffer and 1 for a live buffer, which is weird since they're both
> valid. It also returns 1 for some fake objects which aren't actually
> valid:
> 
> (gdb) p current_thread->m_current_buffer
> $3 = (struct buffer *) 0x555556694b10
> (gdb) p valid_lisp_object_p(0x555556694b15)
> $4 = 1
> (gdb) p valid_lisp_object_p(0x555556694b25)
> $5 = 1

Why do you consider this incorrect?  The Emacs GC is "conservative",
which means it doesn't collect anything that _might_ be a valid Lisp
object.  In what ways does the above violate that contract?

> If a buffer has been killed but is reachable only through
> mark_maybe_object, we fail to mark it.
> 
> We should mark it. In fact, whether a buffer object is marked should
> depend only on whether it's reachable, not whether it's "live" in some
> other sense.
> 
> That's all my patch does.

Your patch modifies the notion of whether a buffer is "live", on the
assumption that this is the root cause of the failure to mark it.  But
do we have any evidence that this is the root cause?  Because if not,
your patch might just be a band-aid, and the real root cause will
still be out there, even if we apply the patch.

Moreover, by disregarding the indication of a killed buffer, doesn't
your patch cause us not to GC killed buffers even though they are
unreachable, or at least create a danger that we would?  Buffers are
objects that are created and killed a lot in any Emacs session, so
failing to GC them would mean memory leaks.

The way to understand what happened in your test case is to figure out
how come the buffer was not found to be reachable via any other
approach the GC makes.  For example, shouldn't we have this buffer
somewhere on the stack? if so, how come stack marking didn't find it?
And if we don't have it on the stack, why not?

> > > > The problem you are trying to solve is rare
> > >
> > > I think it would become much less rare with lexical binding in effect,
> > > at least when the code's byte-compiled.
> >
> > That remains to be seen.
> 
> How about we put out the fire rather than waiting to see whether it
> causes any damage?

The disagreement is whether there's fire, not whether we should put it
out if there is.  You've shown that you can start a fire if you want,
but not that the fire is already out there, burning.  E.g., I see no
reason for some Lisp program to do what your test case does, it simply
makes no sense.

> And, if we can agree to do so, what would you like a patch which is
> actually meant for inclusion into the emacs-27 branch (my previous
> patch wasn't, obviously) to look like?

If it isn't clear, I'm saying that your proposed patch is not
necessarily TRT for master, either.  I'd like to see more analysis of
what exactly happens in that case, and why, along the above-mentioned
lines, before I make up my mind.

> > > > since this code was with us since 20 years ago without
> > > > anyone bumping into it,
> > >
> > > That we know of. They might have just accrued it to random Emacs crashes.
> >
> > Then again, they might not.  We don't really have any evidence to that
> > effect, all we know is that the code survived virtually intact since
> > the day it was written.
> 
> I have no idea what you're trying to get at here.

I'm saying that we have no evidence on which to base the arguments, so
I suggest to drop this part of the dispute as counter-productive.

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

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, pieter-l <at> vanoostrum.org, eggert <at> cs.ucla.edu
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Fri, 13 Mar 2020 13:56:07 +0000

On Fri, Mar 13, 2020 at 9:40 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > > > It doesn't affect visible behavior of any callers, except in the case
> > > > where the previous behavior was buggy.
> > >
> > > I guess we have different notions of "visible"
> >
> > Please say something about your notion of "visible". It doesn't affect
> > any of the existing C callers of valid_lisp_object_p. Are you talking
> > about printing valid_lisp_object_p(x) in a debugger, and not getting
> > the expected value? Or something else?
>
> I'm talking about the behavior documented in the commentary.

You're right if your point is the comment should be adjusted to omit
the unnecessary, and unused, special behavior on killed buffers.

> > > and "buggy".
> >
> > It avoids segfaults or random memory corruption. How is that not "buggy"?
>
> That's not the issue here.  You said the proposed change didn't change
> the behavior "except where it was buggy"; I'm saying that it changes
> the behavior unrelated to this bug, where previous behavior was not
> buggy by any measure.

How so? Can you describe a scenario in which Emacs would behave at all
differently? valid_lisp_object_p returns a different value, sure; but
none of its callers care about the difference, so Emacs behavior
overall does not change.

> So why does it not consider the buffer reachable in this case?  The
> call to live_buffer_p is just one attempt to identify it as reachable;
> there are (or at least should be) others.

I don't think there are, no. This is the one shot we get at protecting
a stack slot that might contain the sole reference to a killed buffer.

> > valid_lisp_object_p is currently documented to return 2 for a killed
> > buffer and 1 for a live buffer, which is weird since they're both
> > valid. It also returns 1 for some fake objects which aren't actually
> > valid:
> >
> > (gdb) p current_thread->m_current_buffer
> > $3 = (struct buffer *) 0x555556694b10
> > (gdb) p valid_lisp_object_p(0x555556694b15)
> > $4 = 1
> > (gdb) p valid_lisp_object_p(0x555556694b25)
> > $5 = 1
>
> Why do you consider this incorrect?  The Emacs GC is "conservative",
> which means it doesn't collect anything that _might_ be a valid Lisp
> object.  In what ways does the above violate that contract?

GC is conservative; valid_lisp_object_p is documented to be precise: a
return value of 1 or 2 means that the object is valid, not that it's
potentially valid and potentially nonsense.

> > If a buffer has been killed but is reachable only through
> > mark_maybe_object, we fail to mark it.
> >
> > We should mark it. In fact, whether a buffer object is marked should
> > depend only on whether it's reachable, not whether it's "live" in some
> > other sense.
> >
> > That's all my patch does.
>
> Your patch modifies the notion of whether a buffer is "live",

No, it modifies a specific function (mis)named buffer_live_p. The
dozens of places in which we check whether a buffer is "live", as
opposed to "killed", are unaffected. Only GC is affected.

> on the
> assumption that this is the root cause of the failure to mark it.

I'm not sure about the philosophical implications of "root cause", but
this is a very obvious bug.

> But do we have any evidence that this is the root cause?

What kind of evidence do you want?

A buffer should be marked iff it is reachable

A buffer is marked iff it is reachable from the heap or it is
reachable from the stack and buffer_live_p returns true

Therefore, it is invalid for buffer_live_p to return false for a
buffer which is reachable from the stack.

> Moreover, by disregarding the indication of a killed buffer, doesn't
> your patch cause us not to GC killed buffers even though they are
> unreachable, or at least create a danger that we would?

Only in the rare case that they appear to be reachable through a stack
reference but actually aren't, but that's just the price we pay for
conservative GC.

> The way to understand what happened in your test case is to figure out
> how come the buffer was not found to be reachable via any other
> approach the GC makes.

There is no other approach.

> For example, shouldn't we have this buffer
> somewhere on the stack?

Precisely.

> if so, how come stack marking didn't find it?

Because we are talking about the stack marking! The stack marking
calls buffer_live_p to check whether it should actually mark the
buffer or not.

> And if we don't have it on the stack, why not?

We do.

> > How about we put out the fire rather than waiting to see whether it
> > causes any damage?
>
> The disagreement is whether there's fire, not whether we should put it
> out if there is.  You've shown that you can start a fire if you want,
> but not that the fire is already out there, burning.  E.g., I see no
> reason for some Lisp program to do what your test case does, it simply
> makes no sense.

How does it not make sense? We kill a buffer and return it.

> > And, if we can agree to do so, what would you like a patch which is
> > actually meant for inclusion into the emacs-27 branch (my previous
> > patch wasn't, obviously) to look like?
>
> If it isn't clear, I'm saying that your proposed patch is not
> necessarily TRT for master, either.  I'd like to see more analysis of
> what exactly happens in that case, and why, along the above-mentioned
> lines, before I make up my mind.

It's certainly not the right thing for master! Using "live" in two
different senses like that is way too confusing for a code base that
is still being worked on.

Again, I think we're being distracted from a very simple issue: stack
marking relies on recognizing reachable objects. Reachable objects are
called "live" in GC code, so the stack marking code that calls
buffer_live_p clearly expects a return value indicating whether the
pointer it passed in points into a buffer object; it doesn't, and
shouldn't, care whether that buffer has been killed or not.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 39962 <at> debbugs.gnu.org, pieter-l <at> vanoostrum.org, eggert <at> cs.ucla.edu
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Fri, 13 Mar 2020 18:30:40 +0200

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Fri, 13 Mar 2020 13:56:07 +0000
> Cc: pieter-l <at> vanoostrum.org, 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
> 
> On Fri, Mar 13, 2020 at 9:40 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > > > > It doesn't affect visible behavior of any callers, except in the case
> > > > > where the previous behavior was buggy.
> > > >
> > > > I guess we have different notions of "visible"
> > >
> > > Please say something about your notion of "visible". It doesn't affect
> > > any of the existing C callers of valid_lisp_object_p. Are you talking
> > > about printing valid_lisp_object_p(x) in a debugger, and not getting
> > > the expected value? Or something else?
> >
> > I'm talking about the behavior documented in the commentary.
> 
> You're right if your point is the comment should be adjusted to omit
> the unnecessary, and unused, special behavior on killed buffers.

I don't yet think that function's behavior should be changed.  See
below.

> > > > and "buggy".
> > >
> > > It avoids segfaults or random memory corruption. How is that not "buggy"?
> >
> > That's not the issue here.  You said the proposed change didn't change
> > the behavior "except where it was buggy"; I'm saying that it changes
> > the behavior unrelated to this bug, where previous behavior was not
> > buggy by any measure.
> 
> How so? Can you describe a scenario in which Emacs would behave at all
> differently?

The behavior of live_buffer_p and valid_lisp_object_p changed, and
those functions weren't "buggy" before.

> valid_lisp_object_p returns a different value, sure; but
> none of its callers care about the difference, so Emacs behavior
> overall does not change.

I wasn't talking about behavior of Emacs as a whole.

And I don't understand why you are arguing about this.  You asked me
to say something about my notion of "visible", and I did.  Will
arguing about _my_ notion of that get us to some useful place?

> > > (gdb) p current_thread->m_current_buffer
> > > $3 = (struct buffer *) 0x555556694b10
> > > (gdb) p valid_lisp_object_p(0x555556694b15)
> > > $4 = 1
> > > (gdb) p valid_lisp_object_p(0x555556694b25)
> > > $5 = 1
> >
> > Why do you consider this incorrect?  The Emacs GC is "conservative",
> > which means it doesn't collect anything that _might_ be a valid Lisp
> > object.  In what ways does the above violate that contract?
> 
> GC is conservative; valid_lisp_object_p is documented to be precise: a
> return value of 1 or 2 means that the object is valid, not that it's
> potentially valid and potentially nonsense.

But what does "valid" mean in this case?  The part that looks at the
stack uses the stack-marking routines, and thus inherits the
"conservative" nature of stack marking.  The code also makes it quite
clear that it only considers "live" objects as valid, and a killed
buffer is not "live".  So I still don't understand in what way the
above results are incorrect.

> > Your patch modifies the notion of whether a buffer is "live",
> 
> No, it modifies a specific function (mis)named buffer_live_p.

Which, among other things, checks whether a buffer is "live".  So it
is not necessarily mis-named.

> The dozens of places in which we check whether a buffer is "live",
> as opposed to "killed", are unaffected. Only GC is affected.

No, not only GC is affected.  Some of the callers are outside GC,
we've been there up-thread, and agreed about that.

> A buffer should be marked iff it is reachable
> 
> A buffer is marked iff it is reachable from the heap or it is
> reachable from the stack and buffer_live_p returns true
> 
> Therefore, it is invalid for buffer_live_p to return false for a
> buffer which is reachable from the stack.

This mixes two notions: a "live" buffer and a buffer that should be
marked.  They are not the same.

> > if so, how come stack marking didn't find it?
> 
> Because we are talking about the stack marking! The stack marking
> calls buffer_live_p to check whether it should actually mark the
> buffer or not.

Fine, so you are saying that stack marking should disregard whether a
buffer is "live"?  Then let's make such a change only for stack
marking, not in a function called from other places.

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, Pip Cet <pipcet <at> gmail.com>
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Fri, 13 Mar 2020 18:42:16 +0100

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

>> From: Pip Cet <pipcet <at> gmail.com>
>> Date: Thu, 12 Mar 2020 20:00:13 +0000
>> Cc: 39962 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
>> 
>> The first attachment to this message is an Elisp file which does the
>> same thing, by creating thousands of symbols. On GNU/Linux, with
>> fairly default standard stack size settings, I get a segfault after
>> some 85,000 symbols have been created.
>
> The default stack size on GNU/Linux is 2MB, right?  Maybe it's high
> time we raised that, what with the memory size today's machines
> routinely have at their disposal.  FWIW, the MS-Windows build have
> been using a 8MB run-time stack for a very long time.

My ulimit -s was 8192 (8 MiBi if I am correct).
The maximum I can set it to is 65532 (that's 64 MiBi if I am correct).

> Of course, given enough recursive data structures we can always crash
> the current GC the way it is implemented.  But the question is how
> many such recursive symbols are there in Pieter's sessions? are they
> anywhere near the 1000000000 mark you used in your test program?  IOW,
> I think we need to know how close we are in real-life sessions to the
> dangerous mark.

One file had 5063 messages, another one 2374.
But I was resorting these files, so I don't know if these caused more of these entries to be generated. The sorting has to reorder the messages, so I get the total would double, but they would be separate lists.

> Maybe this is also worth reporting to VM developers.  They might
> consider changing their implementation to avoid these problems.
>
> Thanks.

-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, Pip Cet <pipcet <at> gmail.com>
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Fri, 13 Mar 2020 18:43:58 +0100

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

>
> I'm not aware of anyone working on that, no.  But I also am not sure
> this is something we should do.  First, it only works on GNU/Linux,
> while Pieter is on macOS AFAIU.  And second, if you read the GCC
> manual's description of that switch, you will see some serious
> caveats, which could mean using that option might produce an
> unworkable binary.  IOW, it doesn't sound to me as an option that is
> recommended for general-purpose use.

Yes I am on MacOS.
-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, pipcet <at> gmail.com
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Fri, 13 Mar 2020 21:34:59 +0200

> From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
> Cc: Pip Cet <pipcet <at> gmail.com>,  39962 <at> debbugs.gnu.org,  eggert <at> cs.ucla.edu
> Date: Fri, 13 Mar 2020 18:42:16 +0100
> 
> > The default stack size on GNU/Linux is 2MB, right?  Maybe it's high
> > time we raised that, what with the memory size today's machines
> > routinely have at their disposal.  FWIW, the MS-Windows build have
> > been using a 8MB run-time stack for a very long time.
> 
> My ulimit -s was 8192 (8 MiBi if I am correct).

But does that mean Emacs can really use that much stack space?

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, pipcet <at> gmail.com
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Fri, 13 Mar 2020 22:35:23 +0100

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

>> From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
>> Cc: Pip Cet <pipcet <at> gmail.com>,  39962 <at> debbugs.gnu.org,  eggert <at> cs.ucla.edu
>> Date: Fri, 13 Mar 2020 18:42:16 +0100
>> 
>> > The default stack size on GNU/Linux is 2MB, right?  Maybe it's high
>> > time we raised that, what with the memory size today's machines
>> > routinely have at their disposal.  FWIW, the MS-Windows build have
>> > been using a 8MB run-time stack for a very long time.
>> 
>> My ulimit -s was 8192 (8 MiBi if I am correct).
>
> But does that mean Emacs can really use that much stack space?

I don't know. If not, would that be an Emacs problem or a MacOS problem? And how can I find out?
-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Richard Stallman <rms <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, pieter-l <at> vanoostrum.org, pipcet <at> gmail.com,
 eggert <at> cs.ucla.edu
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Fri, 13 Mar 2020 23:38:29 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I'm not aware of anyone working on that, no.  But I also am not sure
  > this is something we should do.  First, it only works on GNU/Linux,
  > while Pieter is on macOS AFAIU.

The GNU system is our primary target; other systems are secondary.
Our motto is, "It runs best on GNU."

Therefore if this feature in question would be good to install on
GNU/Linux, we should not hold back from that merely because non-GNU
systems won't be improved as well.

I have not studied this technical issue.  Eli's message suggests it
may have other problems, and perhaps it is not solid enough to be
desirable even on GNU/Linux.  I don't have any opinion about that
question.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, pipcet <at> gmail.com
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 14 Mar 2020 10:08:53 +0200

> From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
> Cc: pipcet <at> gmail.com,  39962 <at> debbugs.gnu.org,  eggert <at> cs.ucla.edu
> Date: Fri, 13 Mar 2020 22:35:23 +0100
> 
> >> My ulimit -s was 8192 (8 MiBi if I am correct).
> >
> > But does that mean Emacs can really use that much stack space?
> 
> I don't know. If not, would that be an Emacs problem or a MacOS problem? And how can I find out?

I'm not familiar enough with Binutils (or their equivalent) on macOS,
but if you put a breakpoint around line 1167 in emacs.c, you should be
able to examine the amount of stack returned by getrlimit.  Assuming
that code gets compiled on your system, that is.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: rms <at> gnu.org
Cc: 39962 <at> debbugs.gnu.org, pieter-l <at> vanoostrum.org, pipcet <at> gmail.com,
 eggert <at> cs.ucla.edu
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 14 Mar 2020 10:37:32 +0200

> From: Richard Stallman <rms <at> gnu.org>
> Cc: pipcet <at> gmail.com, 39962 <at> debbugs.gnu.org, pieter-l <at> vanoostrum.org,
> 	eggert <at> cs.ucla.edu
> Date: Fri, 13 Mar 2020 23:38:29 -0400
> 
>   > I'm not aware of anyone working on that, no.  But I also am not sure
>   > this is something we should do.  First, it only works on GNU/Linux,
>   > while Pieter is on macOS AFAIU.
> 
> The GNU system is our primary target; other systems are secondary.
> Our motto is, "It runs best on GNU."
> 
> Therefore if this feature in question would be good to install on
> GNU/Linux, we should not hold back from that merely because non-GNU
> systems won't be improved as well.
> 
> I have not studied this technical issue.  Eli's message suggests it
> may have other problems, and perhaps it is not solid enough to be
> desirable even on GNU/Linux.  I don't have any opinion about that
> question.

If it wasn't clear, my point was that I didn't think this option is
too good for GNU/Linux, either.  One other evidence to that is that it
isn't the default on those GNU/Linux targets where it works (which are
only a subset of architectures GNU/Linux supports, btw, albeit an
important subset).

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

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, pieter-l <at> vanoostrum.org, eggert <at> cs.ucla.edu
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 14 Mar 2020 09:02:47 +0000

On Fri, Mar 13, 2020 at 4:30 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > > > Please say something about your notion of "visible". It doesn't affect
> > > > any of the existing C callers of valid_lisp_object_p. Are you talking
> > > > about printing valid_lisp_object_p(x) in a debugger, and not getting
> > > > the expected value? Or something else?
> > >
> > > I'm talking about the behavior documented in the commentary.
> >
> > You're right if your point is the comment should be adjusted to omit
> > the unnecessary, and unused, special behavior on killed buffers.
>
> I don't yet think that function's behavior should be changed.  See
> below.

Okay, I can accept that. I suggest we focus on what you want changed, then?

> > How so? Can you describe a scenario in which Emacs would behave at all
> > differently?
>
> The behavior of live_buffer_p and valid_lisp_object_p changed, and
> those functions weren't "buggy" before.

We're just going to have to agree to disagree about whether changing
an internal-only function counts as a behavor change.

I'm perfectly okay with maintaining those two functions as they were
before, and using reachable_buffer_p or something for the GC function.
Would that work for you?

> > > > (gdb) p current_thread->m_current_buffer
> > > > $3 = (struct buffer *) 0x555556694b10
> > > > (gdb) p valid_lisp_object_p(0x555556694b15)
> > > > $4 = 1
> > > > (gdb) p valid_lisp_object_p(0x555556694b25)
> > > > $5 = 1
> > >
> > > Why do you consider this incorrect?  The Emacs GC is "conservative",
> > > which means it doesn't collect anything that _might_ be a valid Lisp
> > > object.  In what ways does the above violate that contract?
> >
> > GC is conservative; valid_lisp_object_p is documented to be precise: a
> > return value of 1 or 2 means that the object is valid, not that it's
> > potentially valid and potentially nonsense.
>
> But what does "valid" mean in this case?  The part that looks at the
> stack uses the stack-marking routines, and thus inherits the
> "conservative" nature of stack marking.

I don't believe that's correct. valid_lisp_object_p is documented, at
least, to return precisely which object is valid, which one isn't, and
potentially which one we can't say anything about.

> > A buffer should be marked iff it is reachable
> >
> > A buffer is marked iff it is reachable from the heap or it is
> > reachable from the stack and buffer_live_p returns true
> >
> > Therefore, it is invalid for buffer_live_p to return false for a
> > buffer which is reachable from the stack.
>
> This mixes two notions: a "live" buffer and a buffer that should be
> marked.  They are not the same.

No, it doesn't. I never mentioned liveness in the sense of not being
killed, at all.

> Fine, so you are saying that stack marking should disregard whether a
> buffer is "live"?  Then let's make such a change only for stack
> marking, not in a function called from other places.

I agree. I'll prepare a patch.

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

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, pieter-l <at> vanoostrum.org, rms <at> gnu.org,
 eggert <at> cs.ucla.edu
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 14 Mar 2020 09:16:40 +0000

On Sat, Mar 14, 2020 at 8:37 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> If it wasn't clear, my point was that I didn't think this option is
> too good for GNU/Linux, either.

I don't think it's desirable as default behavior, at this point. It
seems not entirely trivial to get it to work, at least in the case
where system libraries aren't built with -fsplit-stack.

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

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, pieter-l <at> vanoostrum.org, rms <at> gnu.org,
 eggert <at> cs.ucla.edu
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 14 Mar 2020 15:34:14 +0000

[Message part 1 (text/plain, inline)]

On Sat, Mar 14, 2020 at 9:16 AM Pip Cet <pipcet <at> gmail.com> wrote:
> I don't think it's desirable as default behavior, at this point. It
> seems not entirely trivial to get it to work, at least in the case
> where system libraries aren't built with -fsplit-stack.

It turns out my problems were due to vfork, which doesn't appear to
work with -fsplit-stack and non-split-stack libraries.

The attached patch works, but it appears the standard behavior of
-fsplit-stack is to allocate the stack one page at a time, so it runs
into Linux system limits after 128K stack pages (with guard pages).
That corresponds to somewhere between 4M and 8M symbols in the linked
list, using my test program.

To make this work, configure with CFLAGS="-fsplit-stack", edit
config.h to define USE_SPLIT_STACK and #define vfork fork.

Note that this version marks the entire mapped stack, not just the
area that is actually used; that should be easy enough to fix, but it
doesn't appear to cause any immediate problems.

So, in summary, it's possible to get it to work, but you have to work
around the vfork limitation, and it doesn't help all that much because
the allocation strategy needs to be adjusted, and even then it would
need some extra work not to mark stack areas that were once used but
now aren't.

[0001-split-stack-support.patch (text/x-patch, attachment)]

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

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, pieter-l <at> vanoostrum.org, eggert <at> cs.ucla.edu
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 14 Mar 2020 15:39:42 +0000

[Message part 1 (text/plain, inline)]

> > Fine, so you are saying that stack marking should disregard whether a
> > buffer is "live"?  Then let's make such a change only for stack
> > marking, not in a function called from other places.
>
> I agree. I'll prepare a patch.

Here's the patch. Please let me know if anything else needs changing.

[0001-Don-t-collect-reachable-killed-buffers-during-GC.patch (text/x-patch, attachment)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pip Cet <pipcet <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, pieter-l <at> vanoostrum.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 14 Mar 2020 09:00:50 -0700

On 3/14/20 8:39 AM, Pip Cet wrote:

> +/* If P is a pointer into a buffer, killed or live, return the buffer.
> +   Otherwise, return nil.  M is a pointer to the mem_block for P.  */
> +
> +static Lisp_Object
> +valid_buffer_holding (struct mem_node *m, void *p)
> +{
> +  /* P must point into the block, and the buffer
> +     must not have been killed.  */

The two comments do not seem to agree. Surely second one should say just 
something like "P must point into block M."

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

From: Pip Cet <pipcet <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, pieter-l <at> vanoostrum.org,
 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 14 Mar 2020 16:15:57 +0000

[Message part 1 (text/plain, inline)]

On Sat, Mar 14, 2020 at 4:00 PM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> > +/* If P is a pointer into a buffer, killed or live, return the buffer.
> > +   Otherwise, return nil.  M is a pointer to the mem_block for P.  */
> > +
> > +static Lisp_Object
> > +valid_buffer_holding (struct mem_node *m, void *p)
> > +{
> > +  /* P must point into the block, and the buffer
> > +     must not have been killed.  */
>
> The two comments do not seem to agree. Surely second one should say just
> something like "P must point into block M."

Thanks! Revised patch attached.

[0001-Don-t-collect-reachable-killed-buffers-during-GC.patch (text/x-patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, pieter-l <at> vanoostrum.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 14 Mar 2020 18:57:41 +0200

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Sat, 14 Mar 2020 16:15:57 +0000
> Cc: Eli Zaretskii <eliz <at> gnu.org>, pieter-l <at> vanoostrum.org, 39962 <at> debbugs.gnu.org
> 
> > The two comments do not seem to agree. Surely second one should say just
> > something like "P must point into block M."
> 
> Thanks! Revised patch attached.

Thanks.  I'd prefer not to duplicate code, though.  Can we teach
live_buffer_holding to disregard whether a buffer is killed or not
based on an additional argument?

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

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, pieter-l <at> vanoostrum.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 14 Mar 2020 18:34:58 +0000

[Message part 1 (text/plain, inline)]

On Sat, Mar 14, 2020 at 4:57 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > > The two comments do not seem to agree. Surely second one should say just
> > > something like "P must point into block M."
> >
> > Thanks! Revised patch attached.
>
> Thanks.  I'd prefer not to duplicate code, though.  Can we teach
> live_buffer_holding to disregard whether a buffer is killed or not
> based on an additional argument?

Sure. Patch attached.

[0001-Don-t-collect-reachable-killed-buffers-during-GC.patch (text/x-patch, attachment)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pip Cet <pipcet <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, pieter-l <at> vanoostrum.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 14 Mar 2020 12:09:45 -0700

On 3/14/20 11:34 AM, Pip Cet wrote:

> +      if (0 <= offset && offset < sizeof *b &&
> +	  (all_buffers || !NILP (b->name_)))

The "&&" should go at the start of the second line, not the end of the first.

This patch is for emacs-27, right?

Thanks again.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 39962 <at> debbugs.gnu.org, pieter-l <at> vanoostrum.org, pipcet <at> gmail.com
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 14 Mar 2020 22:10:51 +0200

> Cc: pieter-l <at> vanoostrum.org, 39962 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sat, 14 Mar 2020 12:09:45 -0700
> 
> This patch is for emacs-27, right?

No, it's for master.

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, pipcet <at> gmail.com
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 14 Mar 2020 22:32:12 +0100

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

>> From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
>> Cc: pipcet <at> gmail.com,  39962 <at> debbugs.gnu.org,  eggert <at> cs.ucla.edu
>> Date: Fri, 13 Mar 2020 22:35:23 +0100
>> 
>> >> My ulimit -s was 8192 (8 MiBi if I am correct).
>> >
>> > But does that mean Emacs can really use that much stack space?
>> 
>> I don't know. If not, would that be an Emacs problem or a MacOS problem? And how can I find out?
>
> I'm not familiar enough with Binutils (or their equivalent) on macOS,
> but if you put a breakpoint around line 1167 in emacs.c, you should be
> able to examine the amount of stack returned by getrlimit.  Assuming
> that code gets compiled on your system, that is.

Thanks.

line 1167: rlim_t lim = rlim.rlim_cur;
gives the new maximum that I specified with ulimit -s (67104768). So I can redo the test with that limit. But first get some night rest.
-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Pip Cet <pipcet <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, pieter-l <at> vanoostrum.org,
 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sun, 15 Mar 2020 12:09:43 +0000

[Message part 1 (text/plain, inline)]

On Sat, Mar 14, 2020 at 7:09 PM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> On 3/14/20 11:34 AM, Pip Cet wrote:
>
> > +      if (0 <= offset && offset < sizeof *b &&
> > +       (all_buffers || !NILP (b->name_)))
>
> The "&&" should go at the start of the second line, not the end of the first.

Oops, sorry. Fixed patch attached.

> This patch is for emacs-27, right?

I'd intended it for emacs-27, yes. In master we should get rid of the
live_buffer_p function entirely, I think.

> Thanks again.

Thank you!

[0001-Don-t-collect-reachable-killed-buffers-during-GC.patch (text/x-patch, attachment)]

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

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>,
 pieter-l <at> vanoostrum.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sun, 15 Mar 2020 12:12:52 +0000

On Sat, Mar 14, 2020 at 8:10 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > This patch is for emacs-27, right?
> No, it's for master.

Do you want to apply a different fix to emacs-27, or just leave it unfixed?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, pieter-l <at> vanoostrum.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sun, 15 Mar 2020 16:50:47 +0200

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Sun, 15 Mar 2020 12:09:43 +0000
> Cc: Eli Zaretskii <eliz <at> gnu.org>, pieter-l <at> vanoostrum.org, 39962 <at> debbugs.gnu.org
> 
> Oops, sorry. Fixed patch attached.

Thanks, I pushed it to the master branch (after reversing the meaning
of the additional argument).

> In master we should get rid of the live_buffer_p function entirely,
> I think.

What is wrong with that function that we need to get rid of it?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, pieter-l <at> vanoostrum.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sun, 15 Mar 2020 16:53:35 +0200

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Sun, 15 Mar 2020 12:12:52 +0000
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>, pieter-l <at> vanoostrum.org, 39962 <at> debbugs.gnu.org
> 
> On Sat, Mar 14, 2020 at 8:10 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > > This patch is for emacs-27, right?
> > No, it's for master.
> 
> Do you want to apply a different fix to emacs-27, or just leave it unfixed?

The latter.  I don't want to mess with GC on the release branch at
this time.  We can always consider backporting it to Emacs 27.2 (or
earlier if the need arises); meanwhile I'd like the change to collect
some usage experience on master.

Thanks.

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, pipcet <at> gmail.com
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sun, 15 Mar 2020 20:49:54 +0100

Pieter van Oostrum <pieter-l <at> vanoostrum.org> writes:

> line 1167: rlim_t lim = rlim.rlim_cur;
> gives the new maximum that I specified with ulimit -s (67104768). So I
> can redo the test with that limit. But first get some night rest.

I have done the test with the large stack size. It took considerably longer to crash Emacs, but I still got the crash. 

I had the two breakpoints
break marker.c:472 if charpos <= 0
break alloc.c:3518 if charpos <= 0
but these weren't triggered.

The crash is in the GC, and it seems there is a corrupted overlay or some such.

BTW, the warning: Source file is more recent than executable, is because I switched back and forth between different branches in my repository, but before running I switched back to the compiled Emacs 27 branch, commit c5f255d68156926923232b1edadf50faac527861.
This means it didn't have the live_buffer_holding patch.

------------------------------------------------------------------------
./lisp.h:2623: Emacs fatal error: assertion failed: MARKERP (a)
--Type <RET> for more, q to quit, c to continue without paging--


Thread 3 hit Breakpoint 1, terminate_due_to_signal (sig=6, 
    backtrace_limit=2147483647) at emacs.c:371
warning: Source file is more recent than executable.
371	  signal (sig, SIG_DFL);
(gdb) 
(gdb) bt
#0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:371
#1  0x00000001002a4b9b in die (msg=0x1004f65cc "MARKERP (a)", 
    file=0x1004f0449 "./lisp.h", line=2623) at alloc.c:7245
#2  0x00000001002b98cf in XMARKER (a=XIL(0)) at ./lisp.h:2623
#3  0x00000001002b56e7 in mark_overlay (ptr=0x12c489030) at alloc.c:6213
#4  0x00000001002b3902 in mark_object (arg=XIL(0x12c489035)) at alloc.c:6554
#5  0x00000001002b5813 in mark_vectorlike (header=0x11e7da6b0) at alloc.c:6157
#6  0x00000001002b391a in mark_object (arg=XIL(0x11e7da6b5)) at alloc.c:6566
#7  0x00000001002b5813 in mark_vectorlike (header=0x11d98cc70) at alloc.c:6157
#8  0x00000001002b391a in mark_object (arg=XIL(0x11d98cc75)) at alloc.c:6566
#9  0x00000001002b3d33 in mark_object (arg=XIL(0x11dbdbd33)) at alloc.c:6628
#10 0x00000001002b5a17 in mark_localized_symbol (ptr=0x104a5a560)
    at alloc.c:6278
#11 0x00000001002b3b3d in mark_object (arg=XIL(0x4021850)) at alloc.c:6594
#12 0x00000001002b5813 in mark_vectorlike (header=0x106d63050) at alloc.c:6157
#13 0x00000001002b391a in mark_object (arg=XIL(0x106d63105)) at alloc.c:6566
#14 0x00000001002b3a5d in mark_object (arg=XIL(0x488fbb0)) at alloc.c:6581
#15 0x00000001002b5813 in mark_vectorlike (header=0x104d4abe0) at alloc.c:6157
#16 0x00000001002b391a in mark_object (arg=XIL(0x104d4ba35)) at alloc.c:6566
#17 0x00000001002b3a5d in mark_object (arg=XIL(0x6f1e7e0)) at alloc.c:6581
#18 0x00000001002b5813 in mark_vectorlike (header=0x106d32640) at alloc.c:6157
#19 0x00000001002b391a in mark_object (arg=XIL(0x106d326e5)) at alloc.c:6566
#20 0x00000001002b3a5d in mark_object (arg=XIL(0x62e4f90)) at alloc.c:6581
#21 0x00000001002b5813 in mark_vectorlike (header=0x106d43400) at alloc.c:6157
#22 0x00000001002b391a in mark_object (arg=XIL(0x106d327a5)) at alloc.c:6566
#23 0x00000001002b3a5d in mark_object (arg=XIL(0x105333cf3)) at alloc.c:6581
#24 0x00000001002b3a6a in mark_object (arg=XIL(0x4af0780)) at alloc.c:6582
#25 0x00000001002b5813 in mark_vectorlike (header=0x106f18620) at alloc.c:6157
#26 0x00000001002b391a in mark_object (arg=XIL(0x106f18685)) at alloc.c:6566
#27 0x00000001002b3a5d in mark_object (arg=XIL(0x4af0a20)) at alloc.c:6581
#28 0x00000001002b5813 in mark_vectorlike (header=0x106f186b0) at alloc.c:6157
#29 0x00000001002b391a in mark_object (arg=XIL(0x104c44eb3)) at alloc.c:6566
#30 0x00000001002b3a5d in mark_object (arg=XIL(0x125d29773)) at alloc.c:6581
#31 0x00000001002b5207 in mark_compiled (ptr=0x125c0ae90) at alloc.c:6199
#32 0x00000001002b3827 in mark_object (arg=XIL(0x125c0ae95)) at alloc.c:6521
#33 0x00000001002b3a5d in mark_object (arg=XIL(0x6343500)) at alloc.c:6581
#34 0x00000001002b5813 in mark_vectorlike (header=0x106d81d10) at alloc.c:6157
#35 0x00000001002b391a in mark_object (arg=XIL(0x106d81e05)) at alloc.c:6566
#36 0x00000001002b3a5d in mark_object (arg=XIL(0x6343440)) at alloc.c:6581
#37 0x00000001002b5813 in mark_vectorlike (header=0x106d81cd0) at alloc.c:6157
#38 0x00000001002b391a in mark_object (arg=XIL(0x106d813c5)) at alloc.c:6566
#39 0x00000001002b3a5d in mark_object (arg=XIL(0x6343410)) at alloc.c:6581
#40 0x00000001002b5813 in mark_vectorlike (header=0x106d81f70) at alloc.c:6157
#41 0x00000001002b391a in mark_object (arg=XIL(0x106d82115)) at alloc.c:6566
#42 0x00000001002b3a5d in mark_object (arg=XIL(0x632b2b0)) at alloc.c:6581
#43 0x00000001002b5813 in mark_vectorlike (header=0x106d77220) at alloc.c:6157
#44 0x00000001002b391a in mark_object (arg=XIL(0x106d77285)) at alloc.c:6566
#45 0x00000001002b3a5d in mark_object (arg=XIL(0x6333650)) at alloc.c:6581
--Type <RET> for more, q to quit, c to continue without paging--q
Quit
(gdb) p $rsp
$1 = (void *) 0x7ffeef9c9270
(gdb) i thr
  Id   Target Id                     Frame 
* 3    Thread 0x1d03 of process 9528 terminate_due_to_signal (sig=6, 
    backtrace_limit=2147483647) at emacs.c:371
  6    Thread 0x2a1b of process 9528 0x00007fff72c1fcf2 in ?? ()
   from /usr/lib/system/libsystem_kernel.dylib
  8    Thread 0x5203 of process 9528 0x00007fff72c1fcf2 in ?? ()
   from /usr/lib/system/libsystem_kernel.dylib
  11   Thread 0x5003 of process 9528 0x00007fff72c161fa in ?? ()
   from /usr/lib/system/libsystem_kernel.dylib
  411  Thread 0x4f23 of process 9528 0x00007fff72c2028a in ?? ()
   from /usr/lib/system/libsystem_kernel.dylib
  412  Thread 0x1b33 of process 9528 0x00007fff72de6bdc in start_wqthread ()
   from /usr/lib/system/libsystem_pthread.dylib
  413  Thread 0x1fab of process 9528 0x00007fff72c2028a in ?? ()
   from /usr/lib/system/libsystem_kernel.dylib
  414  Thread 0x2c27 of process 9528 0x00007fff72c2028a in ?? ()
   from /usr/lib/system/libsystem_kernel.dylib
(gdb) 

-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, pipcet <at> gmail.com
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sun, 15 Mar 2020 21:57:22 +0200

> From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
> Cc: 39962 <at> debbugs.gnu.org,  eggert <at> cs.ucla.edu,  pipcet <at> gmail.com
> Date: Sun, 15 Mar 2020 20:49:54 +0100
> 
> Pieter van Oostrum <pieter-l <at> vanoostrum.org> writes:
> 
> (gdb) p $rsp
> $1 = (void *) 0x7ffeef9c9270

What is the value of stack_bottom?

And how many frames do you have in that backtrace, if you show all of
it?

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, pipcet <at> gmail.com
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Mon, 16 Mar 2020 00:26:31 +0100

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

>> From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
>> Cc: 39962 <at> debbugs.gnu.org,  eggert <at> cs.ucla.edu,  pipcet <at> gmail.com
>> Date: Sun, 15 Mar 2020 20:49:54 +0100
>> 
>> Pieter van Oostrum <pieter-l <at> vanoostrum.org> writes:
>> 
>> (gdb) p $rsp
>> $1 = (void *) 0x7ffeef9c9270
>
> What is the value of stack_bottom?
>
(gdb) p &stack_bottom_variable
$3 = (void **) 0x7ffeefbff628

(gdb) p current_thread->m_stack_bottom
$4 = 0x7ffeefbff628 ""

> And how many frames do you have in that backtrace, if you show all of
> it?

11567
#11567 0x00000001001c281e in main (argc=1, argv=0x7ffeefbff660) at emacs.c:2054

-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, pipcet <at> gmail.com
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Mon, 16 Mar 2020 11:44:40 +0100

Pieter van Oostrum <pieter-l <at> vanoostrum.org> writes:

>>> (gdb) p $rsp
>>> $1 = (void *) 0x7ffeef9c9270
>>
>> What is the value of stack_bottom?
>>
> (gdb) p &stack_bottom_variable
> $3 = (void **) 0x7ffeefbff628
>
> (gdb) p current_thread->m_stack_bottom
> $4 = 0x7ffeefbff628 ""
>
>> And how many frames do you have in that backtrace, if you show all of
>> it?
>
> 11567
> #11567 0x00000001001c281e in main (argc=1, argv=0x7ffeefbff660) at emacs.c:2054

(gdb) f 3
#3  0x00000001002b56e7 in mark_overlay (ptr=0x12c489030) at alloc.c:6213
6213	      set_vectorlike_marked (&XMARKER (ptr->end)->header);
(gdb) p *ptr
$9 = {
  header = {
    size = -4611686018360274941
  },
  start = XIL(0x12c488fc5),
  end = XIL(0),
  plist = XIL(0x11dc4e263),
  next = 0x12c488f30
}

So the end of the overlay = 0, and the size is negative. Corruption.
Maybe a stray assignment, or error in freeing memory.

This build doesn't have the 0001-Don-t-collect-reachable-killed-buffers-during-GC.patch applied. I guess that patch might help.

-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, pipcet <at> gmail.com
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Mon, 16 Mar 2020 17:07:12 +0200

> From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
> Cc: 39962 <at> debbugs.gnu.org,  eggert <at> cs.ucla.edu,  pipcet <at> gmail.com
> Date: Mon, 16 Mar 2020 11:44:40 +0100
> 
> #3  0x00000001002b56e7 in mark_overlay (ptr=0x12c489030) at alloc.c:6213
> 6213	      set_vectorlike_marked (&XMARKER (ptr->end)->header);
> (gdb) p *ptr
> $9 = {
>   header = {
>     size = -4611686018360274941
>   },
>   start = XIL(0x12c488fc5),
>   end = XIL(0),
>   plist = XIL(0x11dc4e263),
>   next = 0x12c488f30
> }
> 
> So the end of the overlay = 0, and the size is negative.

XIL(0) is not a position of zero, it's nil (which has binary
representation as zero).  IOW, the END marker of the overlay is nil,
something that shouldn't happen.  (The size prints negative because
the object is marked, and the mark bit makes it look like a negative
value.)  And thus this abort is different from the one you reported
originally: the failed assertion now says that something that should
have been a marker, isn't.

Is the START marker of that overlay valid (albeit marked)?  If so, is
its buffer live, i.e. is its name a Lisp string or is it nil?  And if
it's a live buffer, what kind of buffer is it?

> Corruption.  Maybe a stray assignment, or error in freeing memory.

It does look like memory corruption, although it's hard to imagine a
memory corruption that zeroes out one full 32-bit field of a struct,
but leaves the previous one and the next one intact.

> This build doesn't have the 0001-Don-t-collect-reachable-killed-buffers-during-GC.patch applied. I guess that patch might help.

Didn't you say that an early version of that patch didn't help you
avoid the crashes?  But sure, go ahead and apply that patch, it cannot
possibly hurt.  Although the markers and the overlays are unlinked
from the buffer as part of kill-buffer, i.e. before that patch comes
into play...

An alternative idea is to write code that checks overlays for nil
markers, and then run this code periodically to find when such an
overlay appears.

Or maybe, given enough of such aborts, you could determine whether the
offending overlay always belongs to a certain buffer, and then we
could focus on monitoring that one buffer.

Thanks.

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

From: Pip Cet <pipcet <at> gmail.com>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, eggert <at> cs.ucla.edu, 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Mon, 16 Mar 2020 15:33:56 +0000

On Mon, Mar 16, 2020 at 10:44 AM Pieter van Oostrum
<pieter-l <at> vanoostrum.org> wrote:
> Pieter van Oostrum <pieter-l <at> vanoostrum.org> writes:
>
> >>> (gdb) p $rsp
> >>> $1 = (void *) 0x7ffeef9c9270
> >>
> >> What is the value of stack_bottom?
> >>
> > (gdb) p &stack_bottom_variable
> > $3 = (void **) 0x7ffeefbff628
> >
> > (gdb) p current_thread->m_stack_bottom
> > $4 = 0x7ffeefbff628 ""
> >
> >> And how many frames do you have in that backtrace, if you show all of
> >> it?
> >
> > 11567
> > #11567 0x00000001001c281e in main (argc=1, argv=0x7ffeefbff660) at emacs.c:2054
>
> (gdb) f 3
> #3  0x00000001002b56e7 in mark_overlay (ptr=0x12c489030) at alloc.c:6213
> 6213          set_vectorlike_marked (&XMARKER (ptr->end)->header);
> (gdb) p *ptr
> $9 = {
>   header = {
>     size = -4611686018360274941
>   },
>   start = XIL(0x12c488fc5),
>   end = XIL(0),
>   plist = XIL(0x11dc4e263),
>   next = 0x12c488f30
> }

Can you show the entire small vector block containing 0x12c488fc0?
Something like

x/1024gx 0x12c488000

should work.

What I think happened is that the vector free list got corrupted
somehow, and two vectors believed they owned the memory location
0x12c489040.

> So the end of the overlay = 0

It's nil, indeed. That does point to corruption.

> , and the size is negative. Corruption.

The size looks fine. It's a pseudovector, and tagged, so the two msbs
are 1, making it look negative.

> This build doesn't have the 0001-Don-t-collect-reachable-killed-buffers-during-GC.patch applied. I guess that patch might help.

It's very unlikely.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, pieter-l <at> vanoostrum.org, Pip Cet <pipcet <at> gmail.com>,
 eggert <at> cs.ucla.edu
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Mon, 16 Mar 2020 12:31:44 -0400

> But what does "valid" mean in this case?  The part that looks at the
> stack uses the stack-marking routines, and thus inherits the
> "conservative" nature of stack marking.  The code also makes it quite
> clear that it only considers "live" objects as valid, and a killed
> buffer is not "live".

[ I understand I'm late to this game, but just want to clarify
  a point here.  ]

There are two uses of the word "live" at play here:
- The use coming from Emacs for whether a buffer has been killed or not.
- The use coming from the realm of memory management where it means that
  the object can't be reclaimed because some pointers still point to it
  (and may still be dereferenced or compared).

The GC's marking is only concerned about liveness in the
memory-management sense.


        Stefan

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

From: Pip Cet <pipcet <at> gmail.com>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, eggert <at> cs.ucla.edu, 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Mon, 16 Mar 2020 17:19:52 +0000

[Message part 1 (text/plain, inline)]

On Mon, Mar 16, 2020 at 3:33 PM Pip Cet <pipcet <at> gmail.com> wrote:
> On Mon, Mar 16, 2020 at 10:44 AM Pieter van Oostrum
> <pieter-l <at> vanoostrum.org> wrote:
> > Pieter van Oostrum <pieter-l <at> vanoostrum.org> writes:
> >
> > (gdb) f 3
> > #3  0x00000001002b56e7 in mark_overlay (ptr=0x12c489030) at alloc.c:6213
> > 6213          set_vectorlike_marked (&XMARKER (ptr->end)->header);
> > (gdb) p *ptr
> > $9 = {
> >   header = {
> >     size = -4611686018360274941
> >   },
> >   start = XIL(0x12c488fc5),
> >   end = XIL(0),
> >   plist = XIL(0x11dc4e263),
> >   next = 0x12c488f30
> > }
>
> Can you show the entire small vector block containing 0x12c488fc0?
> Something like
>
> x/1024gx 0x12c488000
>
> should work.
>
> What I think happened is that the vector free list got corrupted
> somehow, and two vectors believed they owned the memory location
> 0x12c489040.

Another thing we could try is poisoning the memory area used by a
vector when we put it on the free list. Something like the attached
patch might work.

[0001-poison-memory-of-vectors-put-on-the-free-list.patch (text/x-patch, attachment)]

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, eggert <at> cs.ucla.edu, 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Mon, 16 Mar 2020 19:36:12 +0100

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

> On Mon, Mar 16, 2020 at 10:44 AM Pieter van Oostrum
> <pieter-l <at> vanoostrum.org> wrote:
>> Pieter van Oostrum <pieter-l <at> vanoostrum.org> writes:
>>
>> >>> (gdb) p $rsp
>> >>> $1 = (void *) 0x7ffeef9c9270
>> >>
>> >> What is the value of stack_bottom?
>> >>
>> > (gdb) p &stack_bottom_variable
>> > $3 = (void **) 0x7ffeefbff628
>> >
>> > (gdb) p current_thread->m_stack_bottom
>> > $4 = 0x7ffeefbff628 ""
>> >
>> >> And how many frames do you have in that backtrace, if you show all of
>> >> it?
>> >
>> > 11567
>> > #11567 0x00000001001c281e in main (argc=1, argv=0x7ffeefbff660) at emacs.c:2054
>>
>> (gdb) f 3
>> #3  0x00000001002b56e7 in mark_overlay (ptr=0x12c489030) at alloc.c:6213
>> 6213          set_vectorlike_marked (&XMARKER (ptr->end)->header);
>> (gdb) p *ptr
>> $9 = {
>>   header = {
>>     size = -4611686018360274941
>>   },
>>   start = XIL(0x12c488fc5),
>>   end = XIL(0),
>>   plist = XIL(0x11dc4e263),
>>   next = 0x12c488f30
>> }
>
> Can you show the entire small vector block containing 0x12c488fc0?
> Something like
>
> x/1024gx 0x12c488000
>
> should work.

(gdb) x/1024gx 0x12c488000
0x12c488000:	0xc000000003005000	0x000000013470c6c0
0x12c488010:	0x4000000003005000	0x000000012c487fc0
0x12c488020:	0x000000000000e951	0x000000000000e951
0x12c488030:	0xc000000004001003	0x000000012c487fc5
0x12c488040:	0x000000012c488005	0x00000001069537b3
0x12c488050:	0x000000012c487f30	0x0000000000000000
0x12c488060:	0x4000000003005000	0x0000000160e5d8e0
0x12c488070:	0x000000010d75fdc0	0x000000012c488180
0x12c488080:	0x0000000004034c11	0x0000000004034c11
0x12c488090:	0x4000000003005000	0x0000000160e5d8e0
0x12c4880a0:	0x4000000002002000	0x000000012c488060
0x12c4880b0:	0x000000000408ca03	0x000000000408ca03
0x12c4880c0:	0xc000000003005000	0x000000013470c6c0
0x12c4880d0:	0x4000000003005000	0x000000010d982780
0x12c4880e0:	0x000000000000e951	0x000000000000e951
0x12c4880f0:	0xc000000003005000	0x000000013470c6c0
0x12c488100:	0x4000000018000004	0x000000012c4880c0
0x12c488110:	0x000000000000e9ae	0x000000000000e9ae
0x12c488120:	0xc000000004001003	0x000000012c4880c5
0x12c488130:	0x000000012c4880f5	0x0000000106953793
0x12c488140:	0x000000012c488030	0x000000012c487e90
0x12c488150:	0x4000000003005000	0x0000000160e5d8e0
0x12c488160:	0x000000011d589530	0x000000012c488270
0x12c488170:	0x0000000003fac124	0x0000000003fac124
0x12c488180:	0x4000000003005000	0x0000000160e5d8e0
0x12c488190:	0x4000000002002000	0x000000012c488150
0x12c4881a0:	0x0000000003ff08c3	0x0000000003ff08c3
0x12c4881b0:	0xc000000003005000	0x000000013470c6c0
0x12c4881c0:	0x4000000003005000	0x000000010d9827e0
0x12c4881d0:	0x000000000000e9ae	0x000000000000e9ae
0x12c4881e0:	0xc000000003005000	0x000000013470c6c0
0x12c4881f0:	0x4000000003005000	0x000000012c4881b0
0x12c488200:	0x000000000000ea0b	0x000000000000ea0b
0x12c488210:	0xc000000004001003	0x000000012c4881b5
0x12c488220:	0x000000012c4881e5	0x0000000106953773
0x12c488230:	0x000000012c488120	0x0000000000000000
0x12c488240:	0x4000000003005000	0x0000000160e5d8e0
0x12c488250:	0x0000000118928350	0x000000012c488360
0x12c488260:	0x0000000003f1f4f4	0x0000000003f1f4f4
0x12c488270:	0x4000000003005000	0x0000000160e5d8e0
0x12c488280:	0x4000000002002000	0x000000012c488240
0x12c488290:	0x0000000003f69440	0x0000000003f69440
0x12c4882a0:	0xc000000003005000	0x000000013470c6c0
0x12c4882b0:	0x4000000003005000	0x000000010d982840
0x12c4882c0:	0x000000000000ea0b	0x000000000000ea0b
0x12c4882d0:	0xc000000003005000	0x000000013470c6c0
0x12c4882e0:	0x4000000003005000	0x000000012c4882a0
0x12c4882f0:	0x000000000000ea68	0x000000000000ea68
0x12c488300:	0xc000000004001003	0x000000012c4882a5
0x12c488310:	0x000000012c4882d5	0x0000000106953753
0x12c488320:	0x000000012c488210	0x000000012c488280
0x12c488330:	0x4000000003005000	0x0000000160e5d8e0
0x12c488340:	0x00000000000179b8	0x000000012c488450
0x12c488350:	0x0000000003ec0c1d	0x0000000003ec0c1d
0x12c488360:	0x4000000003005000	0x0000000160e5d8e0
0x12c488370:	0x0000000000000000	0x000000012c488330
0x12c488380:	0x0000000003edcc75	0x0000000003edcc75
0x12c488390:	0xc000000003005000	0x000000013470c6c0
0x12c4883a0:	0x4000000003005000	0x000000010d9828a0
0x12c4883b0:	0x000000000000ea68	0x000000000000ea68
0x12c4883c0:	0xc000000003005000	0x000000013470c6c0
0x12c4883d0:	0x4000000003005000	0x000000012c488390
0x12c4883e0:	0x000000000000eac5	0x000000000000eac5
0x12c4883f0:	0xc000000004001003	0x000000012c488395
0x12c488400:	0x000000012c4883c5	0x0000000106953673
0x12c488410:	0x000000012c488300	0x000000012c4883d0
0x12c488420:	0x4000000003005000	0x0000000160e5d8e0
0x12c488430:	0x0000000004ef0510	0x000000012c488540
0x12c488440:	0x0000000003e77cfa	0x0000000003e77cfa
--Type <RET> for more, q to quit, c to continue without paging--
0x12c488450:	0x4000000003005000	0x0000000160e5d8e0
0x12c488460:	0x000000000000000c	0x000000012c488420
0x12c488470:	0x0000000003e9c68d	0x0000000003e9c68d
0x12c488480:	0xc000000003005000	0x000000013470c6c0
0x12c488490:	0x4000000003005000	0x000000010d982900
0x12c4884a0:	0x000000000000eac5	0x000000000000eac5
0x12c4884b0:	0xc000000003005000	0x000000013470c6c0
0x12c4884c0:	0x4000000003005000	0x000000012c488480
0x12c4884d0:	0x000000000000eb22	0x000000000000eb22
0x12c4884e0:	0xc000000004001003	0x000000012c488485
0x12c4884f0:	0x000000012c4884b5	0x0000000106953653
0x12c488500:	0x000000012c4883f0	0x0000000000000000
0x12c488510:	0x4000000003005000	0x0000000160e5d8e0
0x12c488520:	0x00000000000179b8	0x000000012c488630
0x12c488530:	0x0000000003e01464	0x0000000003e01464
0x12c488540:	0x4000000003005000	0x0000000160e5d8e0
0x12c488550:	0x0000000000000000	0x000000012c488510
0x12c488560:	0x0000000003e3c41b	0x0000000003e3c41b
0x12c488570:	0xc000000003005000	0x000000013470c6c0
0x12c488580:	0x4000000003005000	0x000000010d982960
0x12c488590:	0x000000000000eb22	0x000000000000eb22
0x12c4885a0:	0xc000000003005000	0x000000013470c6c0
0x12c4885b0:	0x4000000003005000	0x000000012c488570
0x12c4885c0:	0x000000000000eb7f	0x000000000000eb7f
0x12c4885d0:	0xc000000004001003	0x000000012c488575
0x12c4885e0:	0x000000012c4885a5	0x0000000106953633
0x12c4885f0:	0x000000012c4884e0	0x000000012c4883d0
0x12c488600:	0x4000000003005000	0x0000000160e5d8e0
0x12c488610:	0x000000012687d200	0x000000012c488720
0x12c488620:	0x0000000003d85137	0x0000000003d85137
0x12c488630:	0x4000000003005000	0x0000000160e5d8e0
0x12c488640:	0x4000000002002000	0x000000012c488600
0x12c488650:	0x0000000003dc2afa	0x0000000003dc2afa
0x12c488660:	0xc000000003005000	0x000000013470c6c0
0x12c488670:	0x4000000018000004	0x000000010d9829c0
0x12c488680:	0x000000000000eb7f	0x000000000000eb7f
0x12c488690:	0xc000000003005000	0x000000013470c6c0
0x12c4886a0:	0x4000000003005000	0x000000012c488660
0x12c4886b0:	0x000000000000ebdc	0x000000000000ebdc
0x12c4886c0:	0xc000000004001003	0x000000012c488665
0x12c4886d0:	0x000000012c488695	0x0000000106953613
0x12c4886e0:	0x000000012c4885d0	0x0000000000000000
0x12c4886f0:	0x4000000003005000	0x0000000160e5d8e0
0x12c488700:	0x000000011d4c8be0	0x000000012c488810
0x12c488710:	0x0000000003ceda81	0x0000000003ceda81
0x12c488720:	0x4000000003005000	0x0000000160e5d8e0
0x12c488730:	0x4000000002002000	0x000000012c4886f0
0x12c488740:	0x0000000003d4718f	0x0000000003d4718f
0x12c488750:	0xc000000003005000	0x000000013470c6c0
0x12c488760:	0x4000000003005000	0x0000000134954c30
0x12c488770:	0x000000000000ebdc	0x000000000000ebdc
0x12c488780:	0xc000000003005000	0x000000013470c6c0
0x12c488790:	0x4000000003005000	0x000000012c488750
0x12c4887a0:	0x000000000000ec26	0x000000000000ec26
0x12c4887b0:	0xc000000004001003	0x000000012c488755
0x12c4887c0:	0x000000012c488785	0x0000000106953523
0x12c4887d0:	0x000000012c4886c0	0x0000000000000000
0x12c4887e0:	0x4000000003005000	0x0000000160e5d8e0
0x12c4887f0:	0x000000011d4fbfb0	0x000000012c488900
0x12c488800:	0x0000000003c967df	0x0000000003c967df
0x12c488810:	0x4000000003005000	0x0000000160e5d8e0
0x12c488820:	0x4000000002002000	0x000000012c4887e0
0x12c488830:	0x0000000003ccdc6e	0x0000000003ccdc6e
0x12c488840:	0xc000000003005000	0x000000013470c6c0
0x12c488850:	0x0000000000000040	0x0000000134954c90
0x12c488860:	0x000000000000ec26	0x000000000000ec26
0x12c488870:	0xc000000003005000	0x000000013470c6c0
0x12c488880:	0x0000000000000040	0x000000012c488840
0x12c488890:	0x000000000000ec67	0x000000000000ec67
--Type <RET> for more, q to quit, c to continue without paging--
0x12c4888a0:	0xc000000004001003	0x000000012c488845
0x12c4888b0:	0x000000012c488875	0x0000000106953503
0x12c4888c0:	0x000000012c4887b0	0x0000000000000000
0x12c4888d0:	0x4000000003005000	0x0000000160e5d8e0
0x12c4888e0:	0x00000000000179b8	0x000000012c4889f0
0x12c4888f0:	0x0000000003c27fbb	0x0000000003c27fbb
0x12c488900:	0x4000000003005000	0x0000000160e5d8e0
0x12c488910:	0x0000000000000000	0x000000012c4888d0
0x12c488920:	0x0000000003c5f3cd	0x0000000003c5f3cd
0x12c488930:	0xc000000003005000	0x000000013470c6c0
0x12c488940:	0x0000000000000040	0x0000000134954cf0
0x12c488950:	0x000000000000ec67	0x000000000000ec67
0x12c488960:	0xc000000003005000	0x000000013470c6c0
0x12c488970:	0x000000000000000c	0x000000012c488930
0x12c488980:	0x000000000000ecc4	0x000000000000ecc4
0x12c488990:	0xc000000004001003	0x000000012c488935
0x12c4889a0:	0x000000012c488965	0x00000001069534e3
0x12c4889b0:	0x000000012c4888a0	0x0000000000000000
0x12c4889c0:	0x4000000003005000	0x0000000160e5d8e0
0x12c4889d0:	0x0000000004ef0510	0x000000012c488ae0
0x12c4889e0:	0x0000000003bb43b0	0x0000000003bb43b0
0x12c4889f0:	0x4000000003005000	0x0000000160e5d8e0
0x12c488a00:	0x000000000000000c	0x000000012c4889c0
0x12c488a10:	0x0000000003bee19f	0x0000000003bee19f
0x12c488a20:	0xc000000003005000	0x000000013470c6c0
0x12c488a30:	0x0000000000000000	0x0000000134954d50
0x12c488a40:	0x000000000000ecc4	0x000000000000ecc4
0x12c488a50:	0xc000000003005000	0x000000013470c6c0
0x12c488a60:	0x0000000000000000	0x000000012c488a20
0x12c488a70:	0x000000000000ed21	0x000000000000ed21
0x12c488a80:	0xc000000004001003	0x000000012c488a25
0x12c488a90:	0x000000012c488a55	0x00000001069534c3
0x12c488aa0:	0x000000012c488990	0x0000000000000000
0x12c488ab0:	0x4000000003005000	0x0000000160e5d8e0
0x12c488ac0:	0x00000000000179b8	0x000000012c488bd0
0x12c488ad0:	0x0000000003b5d83c	0x0000000003b5d83c
0x12c488ae0:	0x4000000003005000	0x0000000160e5d8e0
0x12c488af0:	0x0000000000000000	0x000000012c488ab0
0x12c488b00:	0x0000000003b7a5c1	0x0000000003b7a5c1
0x12c488b10:	0xc000000003005000	0x000000013470c6c0
0x12c488b20:	0x0000000000000000	0x0000000134954db0
0x12c488b30:	0x000000000000ed21	0x000000000000ed21
0x12c488b40:	0xc000000003005000	0x000000013470c6c0
0x12c488b50:	0x0000000000000000	0x000000012c488b10
0x12c488b60:	0x000000000000ed7e	0x000000000000ed7e
0x12c488b70:	0xc000000004001003	0x000000012c488b15
0x12c488b80:	0x000000012c488b45	0x000000011dc4e3c3
0x12c488b90:	0x000000012c488a80	0x0000000000000000
0x12c488ba0:	0x4000000003005000	0x0000000160e5d8e0
0x12c488bb0:	0x000000011d4a5990	0x000000012c488cc0
0x12c488bc0:	0x0000000003b5b76b	0x0000000003b5b76b
0x12c488bd0:	0x4000000003005000	0x0000000160e5d8e0
0x12c488be0:	0x4000000002002000	0x000000012c488ba0
0x12c488bf0:	0x0000000003b5c8e5	0x0000000003b5c8e5
0x12c488c00:	0xc000000003005000	0x000000013470c6c0
0x12c488c10:	0x0000000000000030	0x0000000134954e10
0x12c488c20:	0x000000000000ed7e	0x000000000000ed7e
0x12c488c30:	0xc000000003005000	0x000000013470c6c0
0x12c488c40:	0x0000000000000034	0x000000012c488c00
0x12c488c50:	0x000000000000eddb	0x000000000000eddb
0x12c488c60:	0xc000000004001003	0x000000012c488c05
0x12c488c70:	0x000000012c488c35	0x000000011dc4e3a3
0x12c488c80:	0x000000012c488b70	0x0000000000000000
0x12c488c90:	0x4000000003005000	0x0000000160e5d8e0
0x12c488ca0:	0x000000010d641d70	0x000000012c488db0
0x12c488cb0:	0x0000000003b50fe9	0x0000000003b50fe9
0x12c488cc0:	0x4000000003005000	0x0000000160e5d8e0
0x12c488cd0:	0x4000000002002000	0x000000012c488c90
0x12c488ce0:	0x0000000003b56c4c	0x0000000003b56c4c
--Type <RET> for more, q to quit, c to continue without paging--
0x12c488cf0:	0xc000000003005000	0x000000013470c6c0
0x12c488d00:	0x000000000000003c	0x0000000134954e70
0x12c488d10:	0x000000000000eddb	0x000000000000eddb
0x12c488d20:	0xc000000003005000	0x000000013470c6c0
0x12c488d30:	0x0000000000000000	0x000000012c488cf0
0x12c488d40:	0x000000000000ee25	0x000000000000ee25
0x12c488d50:	0xc000000004001003	0x000000012c488cf5
0x12c488d60:	0x000000012c488d25	0x000000011dc4e383
0x12c488d70:	0x000000012c488c60	0x0000000000000000
0x12c488d80:	0x4000000003005000	0x0000000160e5d8e0
0x12c488d90:	0x000000011d4c2270	0x000000012c488ea0
0x12c488da0:	0x0000000003b45abb	0x0000000003b45abb
0x12c488db0:	0x4000000003005000	0x0000000160e5d8e0
0x12c488dc0:	0x4000000002002000	0x000000012c488d80
0x12c488dd0:	0x0000000003b4b544	0x0000000003b4b544
0x12c488de0:	0xc000000003005000	0x000000013470c6c0
0x12c488df0:	0x0000000000000004	0x0000000134954ed0
0x12c488e00:	0x000000000000ee25	0x000000000000ee25
0x12c488e10:	0xc000000003005000	0x000000013470c6c0
0x12c488e20:	0x000000000000003c	0x000000012c488de0
0x12c488e30:	0x000000000000ee66	0x000000000000ee66
0x12c488e40:	0xc000000004001003	0x000000012c488de5
0x12c488e50:	0x000000012c488e15	0x000000011dc4e363
0x12c488e60:	0x000000012c488d50	0x0000000000000000
0x12c488e70:	0x4000000003005000	0x0000000160e5d8e0
0x12c488e80:	0x00000000000179b8	0x000000012c488f90
0x12c488e90:	0x0000000003b3d487	0x0000000003b3d487
0x12c488ea0:	0x4000000003005000	0x0000000160e5d8e0
0x12c488eb0:	0x0000000000000000	0x000000012c488e70
0x12c488ec0:	0x0000000003b416ac	0x0000000003b416ac
0x12c488ed0:	0xc000000003005000	0x000000013470c6c0
0x12c488ee0:	0x000000000000000c	0x0000000134954f30
0x12c488ef0:	0x000000000000ee66	0x000000000000ee66
0x12c488f00:	0xc000000003005000	0x000000013470c6c0
0x12c488f10:	0x0000000000000030	0x000000012c488ed0
0x12c488f20:	0x000000000000eea7	0x000000000000eea7
0x12c488f30:	0xc000000004001003	0x000000012c488ed5
0x12c488f40:	0x000000012c488f05	0x000000011dc4e283
0x12c488f50:	0x000000012c488e40	0x0000000000000000
0x12c488f60:	0x4000000003005000	0x0000000160e5d8e0
0x12c488f70:	0x0000000004ef0510	0x000000012c487090
0x12c488f80:	0x0000000003aee876	0x0000000003aee876
0x12c488f90:	0x4000000003005000	0x0000000160e5d8e0
0x12c488fa0:	0x000000000000000c	0x000000012c488f60
0x12c488fb0:	0x0000000003b25537	0x0000000003b25537
0x12c488fc0:	0xc000000003005000	0x000000013470c6c0
0x12c488fd0:	0x0000000000000000	0x0000000134954f90
0x12c488fe0:	0x000000000000eea7	0x000000000000eea7
0x12c488ff0:	0x000000012c487000	0x000000012c488f80
0x12c489000:	0x4000000003005000	0x000000013470c6c0
0x12c489010:	0x4000000003005000	0x000000012c488fc0
0x12c489020:	0x000000000000eef1	0x000000000000eef1
0x12c489030:	0xc000000004001003	0x000000012c488fc5
0x12c489040:	0x0000000000000000	0x000000011dc4e263
0x12c489050:	0x000000012c488f30	0x0000000000000000
0x12c489060:	0x4000000003005000	0x0000000160e5d8e0
0x12c489070:	0x000000010d6a9c00	0x000000012c489180
0x12c489080:	0x00000000045e4806	0x00000000045e4806
0x12c489090:	0x4000000003005000	0x0000000160e5d8e0
0x12c4890a0:	0x4000000002002000	0x000000012c489060
0x12c4890b0:	0x00000000045e8654	0x00000000045e8654
0x12c4890c0:	0x4000000003005000	0x000000013470c6c0
0x12c4890d0:	0x4000000003005000	0x0000000134954ff0
0x12c4890e0:	0x000000000000eef1	0x000000000000eef1
0x12c4890f0:	0x4000000003005000	0x000000013470c6c0
0x12c489100:	0x4000000003005000	0x000000012c4890c0
0x12c489110:	0x000000000000ef4e	0x000000000000ef4e
0x12c489120:	0x4000000004001003	0x000000012c4890c5
0x12c489130:	0x000000012c4890f5	0x000000011dc4e243
--Type <RET> for more, q to quit, c to continue without paging--
0x12c489140:	0x000000012c489030	0x000000012c4890a0
0x12c489150:	0x4000000003005000	0x0000000160e5d8e0
0x12c489160:	0x000000010d4e5ae0	0x000000012c489270
0x12c489170:	0x00000000045d9aaa	0x00000000045d9aaa
0x12c489180:	0x4000000003005000	0x0000000160e5d8e0
0x12c489190:	0x4000000002002000	0x000000012c489150
0x12c4891a0:	0x00000000045df3ff	0x00000000045df3ff
0x12c4891b0:	0x4000000003005000	0x000000013470c6c0
0x12c4891c0:	0x4000000003005000	0x0000000134955050
0x12c4891d0:	0x000000000000ef4e	0x000000000000ef4e
0x12c4891e0:	0x4000000003005000	0x000000013470c6c0
0x12c4891f0:	0x4000000003005000	0x000000012c4891b0
0x12c489200:	0x000000000000efab	0x000000000000efab
0x12c489210:	0x4000000004001003	0x000000012c4891b5
0x12c489220:	0x000000012c4891e5	0x000000011dc4e223
0x12c489230:	0x000000012c489120	0x0000000000000000
0x12c489240:	0x4000000003005000	0x0000000160e5d8e0
0x12c489250:	0x00000000000179b8	0x000000012c489360
0x12c489260:	0x00000000045d1144	0x00000000045d1144
0x12c489270:	0x4000000003005000	0x0000000160e5d8e0
0x12c489280:	0x0000000000000000	0x000000012c489240
0x12c489290:	0x00000000045d4402	0x00000000045d4402
0x12c4892a0:	0x4000000003005000	0x000000013470c6c0
0x12c4892b0:	0x4000000003005000	0x00000001349550b0
0x12c4892c0:	0x000000000000efab	0x000000000000efab
0x12c4892d0:	0x4000000003005000	0x000000013470c6c0
0x12c4892e0:	0x4000000003005000	0x000000012c4892a0
0x12c4892f0:	0x000000000000efec	0x000000000000efec
0x12c489300:	0x4000000004001003	0x000000012c4892a5
0x12c489310:	0x000000012c4892d5	0x000000011dc4e133
0x12c489320:	0x000000012c489210	0x000000012c488f20
0x12c489330:	0x4000000003005000	0x0000000160e5d8e0
0x12c489340:	0x0000000004ef0510	0x000000012c489450
0x12c489350:	0x00000000045c50cb	0x00000000045c50cb
0x12c489360:	0x4000000003005000	0x0000000160e5d8e0
0x12c489370:	0x000000000000000c	0x000000012c489330
0x12c489380:	0x00000000045cb2a1	0x00000000045cb2a1
0x12c489390:	0x4000000003005000	0x000000013470c6c0
0x12c4893a0:	0x4000000003005000	0x0000000134955110
0x12c4893b0:	0x000000000000efec	0x000000000000efec
0x12c4893c0:	0x4000000003005000	0x000000013470c6c0
0x12c4893d0:	0x4000000003005000	0x000000012c489390
0x12c4893e0:	0x000000000000f036	0x000000000000f036
0x12c4893f0:	0x4000000004001003	0x000000012c489395
0x12c489400:	0x000000012c4893c5	0x000000011dc4e113
0x12c489410:	0x000000012c489300	0x00000001056543d5
0x12c489420:	0x4000000003005000	0x0000000160e5d8e0
0x12c489430:	0x000000011899ce50	0x000000012c489540
0x12c489440:	0x00000000045b6cff	0x00000000045b6cff
0x12c489450:	0x4000000003005000	0x0000000160e5d8e0
0x12c489460:	0x4000000002002000	0x000000012c489420
0x12c489470:	0x00000000045bc126	0x00000000045bc126
0x12c489480:	0x4000000003005000	0x000000013470c6c0
0x12c489490:	0x4000000003005000	0x0000000134955170
0x12c4894a0:	0x000000000000f036	0x000000000000f036
0x12c4894b0:	0x4000000003005000	0x000000013470c6c0
0x12c4894c0:	0x4000000003005000	0x000000012c489480
0x12c4894d0:	0x000000000000f093	0x000000000000f093
0x12c4894e0:	0x4000000004001003	0x000000012c489485
0x12c4894f0:	0x000000012c4894b5	0x000000011dc4e0f3
0x12c489500:	0x000000012c4893f0	0x000000012c4894c0
0x12c489510:	0x4000000003005000	0x0000000160e5d8e0
0x12c489520:	0x0000000115728120	0x000000012c489630
0x12c489530:	0x00000000045adcdf	0x00000000045adcdf
0x12c489540:	0x4000000003005000	0x0000000160e5d8e0
0x12c489550:	0x4000000002002000	0x000000012c489510
0x12c489560:	0x00000000045b14c6	0x00000000045b14c6
0x12c489570:	0x4000000003005000	0x000000013470c6c0
0x12c489580:	0x4000000003005000	0x00000001349551d0
--Type <RET> for more, q to quit, c to continue without paging--
0x12c489590:	0x000000000000f093	0x000000000000f093
0x12c4895a0:	0x4000000003005000	0x000000013470c6c0
0x12c4895b0:	0x4000000003005000	0x000000012c489570
0x12c4895c0:	0x000000000000f0f0	0x000000000000f0f0
0x12c4895d0:	0x4000000004001003	0x000000012c489575
0x12c4895e0:	0x000000012c4895a5	0x000000011dc4e0d3
0x12c4895f0:	0x000000012c4894e0	0x0000000000000000
0x12c489600:	0x4000000003005000	0x0000000160e5d8e0
0x12c489610:	0x0000000126874280	0x000000012c489720
0x12c489620:	0x00000000045a6ece	0x00000000045a6ece
0x12c489630:	0x4000000003005000	0x0000000160e5d8e0
0x12c489640:	0x4000000002002000	0x000000012c489600
0x12c489650:	0x00000000045a85ab	0x00000000045a85ab
0x12c489660:	0x4000000003005000	0x000000013470c6c0
0x12c489670:	0x4000000003005000	0x0000000134955230
0x12c489680:	0x000000000000f0f0	0x000000000000f0f0
0x12c489690:	0x4000000003005000	0x000000013470c6c0
0x12c4896a0:	0x4000000003005000	0x000000012c489660
0x12c4896b0:	0x000000000000f14d	0x000000000000f14d
0x12c4896c0:	0x4000000004001003	0x000000012c489665
0x12c4896d0:	0x000000012c489695	0x000000011dc4dfd3
0x12c4896e0:	0x000000012c4895d0	0x0000000000000000
0x12c4896f0:	0x4000000003005000	0x0000000160e5d8e0
0x12c489700:	0x00000001268a5900	0x000000012c489810
0x12c489710:	0x0000000004544250	0x0000000004544250
0x12c489720:	0x4000000003005000	0x0000000160e5d8e0
0x12c489730:	0x4000000002002000	0x000000012c4896f0
0x12c489740:	0x00000000045a3423	0x00000000045a3423
0x12c489750:	0x4000000003005000	0x000000013470c6c0
0x12c489760:	0x4000000003005000	0x0000000134955290
0x12c489770:	0x000000000000f14d	0x000000000000f14d
0x12c489780:	0x4000000003005000	0x000000013470c6c0
0x12c489790:	0x4000000003005000	0x000000012c489750
0x12c4897a0:	0x000000000000f1aa	0x000000000000f1aa
0x12c4897b0:	0x4000000004001003	0x000000012c489755
0x12c4897c0:	0x000000012c489785	0x000000011dc4dfb3
0x12c4897d0:	0x000000012c4896c0	0x000000012c489760
0x12c4897e0:	0x4000000003005000	0x0000000160e5d8e0
0x12c4897f0:	0x00000000000179b8	0x000000012c489900
0x12c489800:	0x0000000004489eec	0x0000000004489eec
0x12c489810:	0x4000000003005000	0x0000000160e5d8e0
0x12c489820:	0x0000000000000000	0x000000012c4897e0
0x12c489830:	0x00000000044e6d46	0x00000000044e6d46
0x12c489840:	0x4000000003005000	0x000000013470c6c0
0x12c489850:	0x0000000000000000	0x00000001349552f0
0x12c489860:	0x000000000000f1aa	0x000000000000f1aa
0x12c489870:	0x4000000003005000	0x000000013470c6c0
0x12c489880:	0x000000012c486400	0x000000012c489840
0x12c489890:	0x000000000000f207	0x000000000000f207
0x12c4898a0:	0x4000000004001003	0x000000012c489845
0x12c4898b0:	0x000000012c489875	0x000000011dc4df93
0x12c4898c0:	0x000000012c4897b0	0x000000012c489870
0x12c4898d0:	0x4000000003005000	0x0000000160e5d8e0
0x12c4898e0:	0x0000000004ef0510	0x000000012c4899f0
0x12c4898f0:	0x00000000043d41c9	0x00000000043d41c9
0x12c489900:	0x4000000003005000	0x0000000160e5d8e0
0x12c489910:	0x000000000000000c	0x000000012c4898d0
0x12c489920:	0x000000000442e27b	0x000000000442e27b
0x12c489930:	0x4000000003005000	0x000000013470c6c0
0x12c489940:	0x696f766e49203a40	0x0000000134955350
0x12c489950:	0x000000000000f207	0x000000000000f207
0x12c489960:	0x4000000003005000	0x000000013470c6c0
0x12c489970:	0x000000012c489918	0x000000012c489930
0x12c489980:	0x000000000000f264	0x000000000000f264
0x12c489990:	0x4000000004001003	0x000000012c489935
0x12c4899a0:	0x000000012c489965	0x000000011dc4df73
0x12c4899b0:	0x000000012c4898a0	0x0000000000000000
0x12c4899c0:	0x4000000003005000	0x0000000160e5d8e0
0x12c4899d0:	0x0000000004eef068	0x000000012c489ae0
--Type <RET> for more, q to quit, c to continue without paging--
0x12c4899e0:	0x000000000435ceba	0x000000000435ceba
0x12c4899f0:	0x4000000003005000	0x0000000160e5d8e0
0x12c489a00:	0x0000000000000014	0x000000012c4899c0
0x12c489a10:	0x000000000437afdb	0x000000000437afdb
0x12c489a20:	0x4000000003005000	0x000000013470c6c0
0x12c489a30:	0x0000000000000004	0x00000001349553b0
0x12c489a40:	0x000000000000f264	0x000000000000f264
0x12c489a50:	0x4000000003005000	0x000000013470c6c0
0x12c489a60:	0x0000000000000000	0x000000012c489a20
0x12c489a70:	0x000000000000f2c1	0x000000000000f2c1
0x12c489a80:	0x4000000004001003	0x000000012c489a25
0x12c489a90:	0x000000012c489a55	0x000000011dc4de83
0x12c489aa0:	0x000000012c489990	0x000000000000003f
0x12c489ab0:	0x4000000003005000	0x0000000160e5d8e0
0x12c489ac0:	0x0000000126865ef0	0x000000012c489bd0
0x12c489ad0:	0x000000000431f2f3	0x000000000431f2f3
0x12c489ae0:	0x4000000003005000	0x0000000160e5d8e0
0x12c489af0:	0x4000000002002000	0x000000012c489ab0
0x12c489b00:	0x000000000433d4e9	0x000000000433d4e9
0x12c489b10:	0x4000000003005000	0x000000013470c6c0
0x12c489b20:	0x0000000000000000	0x0000000134955410
0x12c489b30:	0x000000000000f2c1	0x000000000000f2c1
0x12c489b40:	0x4000000003005000	0x000000013470c6c0
0x12c489b50:	0x0000000000000000	0x000000012c489b10
0x12c489b60:	0x000000000000f31e	0x000000000000f31e
0x12c489b70:	0x4000000004001003	0x000000012c489b15
0x12c489b80:	0x000000012c489b45	0x000000011dc4de63
0x12c489b90:	0x000000012c489a80	0x0000000000000000
0x12c489ba0:	0x4000000003005000	0x0000000160e5d8e0
0x12c489bb0:	0x00000001268891d0	0x000000012c489cc0
0x12c489bc0:	0x00000000042e1eb3	0x00000000042e1eb3
0x12c489bd0:	0x4000000003005000	0x0000000160e5d8e0
0x12c489be0:	0x4000000002002000	0x000000012c489ba0
0x12c489bf0:	0x0000000004301283	0x0000000004301283
0x12c489c00:	0x4000000003005000	0x000000013470c6c0
0x12c489c10:	0x000000012c7ffde4	0x0000000134955470
0x12c489c20:	0x000000000000f31e	0x000000000000f31e
0x12c489c30:	0x4000000003005000	0x000000013470c6c0
0x12c489c40:	0x0000000000005988	0x000000012c489c00
0x12c489c50:	0x000000000000f35f	0x000000000000f35f
0x12c489c60:	0x4000000004001003	0x000000012c489c05
0x12c489c70:	0x000000012c489c35	0x000000011dc4de43
0x12c489c80:	0x000000012c489b70	0x0000000000000001
0x12c489c90:	0x4000000003005000	0x0000000160e5d8e0
0x12c489ca0:	0x00000001268348a0	0x000000012c489db0
0x12c489cb0:	0x00000000042609cd	0x00000000042609cd
0x12c489cc0:	0x4000000003005000	0x0000000160e5d8e0
0x12c489cd0:	0x4000000002002000	0x000000012c489c90
0x12c489ce0:	0x000000000429e5ac	0x000000000429e5ac
0x12c489cf0:	0x4000000003005000	0x000000013470c6c0
0x12c489d00:	0x000000012c489ca8	0x00000001349554d0
0x12c489d10:	0x000000000000f35f	0x000000000000f35f
0x12c489d20:	0x4000000003005000	0x000000013470c6c0
0x12c489d30:	0x0000000000000000	0x000000012c489cf0
0x12c489d40:	0x000000000000f3a9	0x000000000000f3a9
0x12c489d50:	0x4000000004001003	0x000000012c489cf5
0x12c489d60:	0x000000012c489d25	0x000000011dc4de23
0x12c489d70:	0x000000012c489c60	0x0000000000000002
0x12c489d80:	0x4000000003005000	0x0000000160e5d8e0
0x12c489d90:	0x00000000000179b8	0x000000012c489ea0
0x12c489da0:	0x00000000041e9220	0x00000000041e9220
0x12c489db0:	0x4000000003005000	0x0000000160e5d8e0
0x12c489dc0:	0x0000000000000000	0x000000012c489d80
0x12c489dd0:	0x00000000042256fe	0x00000000042256fe
0x12c489de0:	0x4000000003005000	0x000000013470c6c0
0x12c489df0:	0x000000010cb3af44	0x0000000134955530
0x12c489e00:	0x000000000000f3a9	0x000000000000f3a9
0x12c489e10:	0x4000000003005000	0x000000013470c6c0
0x12c489e20:	0x4f20202020202000	0x000000012c489de0
--Type <RET> for more, q to quit, c to continue without paging--
0x12c489e30:	0x000000000000f3f3	0x000000000000f3f3
0x12c489e40:	0x4000000004001003	0x000000012c489de5
0x12c489e50:	0x000000012c489e15	0x000000011dc4dd43
0x12c489e60:	0x000000012c489d50	0x0000000000000000
0x12c489e70:	0x4000000003005000	0x0000000160e5d8e0
0x12c489e80:	0x0000000004ef0510	0x000000012c489f90
0x12c489e90:	0x00000000041998ca	0x00000000041998ca
0x12c489ea0:	0x4000000003005000	0x0000000160e5d8e0
0x12c489eb0:	0x000000000000000c	0x000000012c489e70
0x12c489ec0:	0x00000000041cbed1	0x00000000041cbed1
0x12c489ed0:	0x4000000003005000	0x000000013470c6c0
0x12c489ee0:	0x0000000000005a18	0x0000000134955590
0x12c489ef0:	0x000000000000f3f3	0x000000000000f3f3
0x12c489f00:	0x4000000003005000	0x000000013470c6c0
0x12c489f10:	0x0000000000000000	0x000000012c489ed0
0x12c489f20:	0x000000000000f434	0x000000000000f434
0x12c489f30:	0x4000000004001003	0x000000012c489ed5
0x12c489f40:	0x000000012c489f05	0x000000011dc4dd23
0x12c489f50:	0x000000012c489e40	0x000000000000004c
0x12c489f60:	0x4000000003005000	0x0000000160e5d8e0
0x12c489f70:	0x00000000000179b8	0x000000012c488090
0x12c489f80:	0x00000000040ea063	0x00000000040ea063
0x12c489f90:	0x4000000003005000	0x0000000160e5d8e0
0x12c489fa0:	0x0000000000000000	0x000000012c489f60
0x12c489fb0:	0x000000000413f1d4	0x000000000413f1d4
0x12c489fc0:	0x4000000003005000	0x000000013470c6c0
0x12c489fd0:	0x000000011e6451c0	0x00000001349555f0
0x12c489fe0:	0x000000000000f434	0x000000000000f434
0x12c489ff0:	0x000000012c488000	0x0000000000000000
(gdb) 

-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, eggert <at> cs.ucla.edu, 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Tue, 17 Mar 2020 04:29:09 +0100

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

> Another thing we could try is poisoning the memory area used by a
> vector when we put it on the free list. Something like the attached
> patch might work.

I made a new compile with the patch 0001-poison-memory-of-vectors-put-on-the-free-list.patch applied and also the latest 0001-Don-t-collect-reachable-killed-buffers-during-GC.patch (from message ID <CAOqdjBfeL-T8grB+sW+jLoW-JX8Y0siFTzG1q0o+Skc+sKvtSQ <at> mail.gmail.com>) applied.

I get a crash about a mal-formed marker, but now in the running code, not in the GC.


./lisp.h:2623: Emacs fatal error: assertion failed: MARKERP (a)
--Type <RET> for more, q to quit, c to continue without paging--

Thread 3 hit Breakpoint 1, terminate_due_to_signal (sig=6, 
    backtrace_limit=2147483647) at emacs.c:371
371	  signal (sig, SIG_DFL);
(gdb) bt
#0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:371
#1  0x00000001002a4b2b in die (msg=0x1004f65cc "MARKERP (a)", 
    file=0x1004f0449 "./lisp.h", line=2623) at alloc.c:7249
#2  0x000000010023c21f in XMARKER (a=XIL(0x12590f575)) at ./lisp.h:2623
#3  0x000000010023cdc5 in marker_position (marker=XIL(0x12590f575))
    at marker.c:691
#4  0x0000000100221335 in OVERLAY_POSITION (p=XIL(0x12590f575))
    at ./buffer.h:1394
#5  0x00000001002268d7 in report_overlay_modification (
    start=make_fixnum(40255), end=make_fixnum(40255), after=false, 
    arg1=make_fixnum(40255), arg2=make_fixnum(40255), arg3=XIL(0))
    at buffer.c:4496
#6  0x0000000100239462 in signal_before_change (start_int=40255, 
    end_int=40255, preserve_ptr=0x0) at insdel.c:2179
#7  0x000000010023878b in prepare_to_modify_buffer_1 (start=40255, end=40255, 
    preserve_ptr=0x0) at insdel.c:2007
#8  0x00000001002339a5 in prepare_to_modify_buffer (start=40255, end=40255, 
    preserve_ptr=0x0) at insdel.c:2018
#9  0x0000000100234067 in insert_from_string_1 (string=XIL(0x1607b3984), 
    pos=0, pos_byte=0, nchars=2, nbytes=2, inherit=false, before_markers=false)
    at insdel.c:1016
#10 0x0000000100233e88 in insert_from_string (string=XIL(0x1607b3984), pos=0, 
    pos_byte=0, length=2, length_byte=2, inherit=false) at insdel.c:967
#11 0x00000001002ec572 in general_insert_function (
    insert_func=0x100232120 <insert>, 
    insert_from_string_func=0x100233df0 <insert_from_string>, inherit=false, 
    nargs=1, args=0x7ffeefbe9af8) at editfns.c:1334
#12 0x00000001002ec28b in Finsert (nargs=1, args=0x7ffeefbe9af8)
    at editfns.c:1370
#13 0x00000001003a7df3 in exec_byte_code (bytestr=XIL(0x10d555e74), 
    vector=XIL(0x10dbc0e65), maxdepth=make_fixnum(6), args_template=XIL(0), 
    nargs=0, args=0x0) at bytecode.c:1075
#14 0x00000001003174d6 in funcall_lambda (fun=XIL(0x10dbc1005), nargs=1, 
    arg_vector=0x7ffeefbeac90) at eval.c:3067
#15 0x0000000100314c9e in Ffuncall (nargs=2, args=0x7ffeefbeac88)
    at eval.c:2796
#16 0x00000001003a527f in exec_byte_code (bytestr=XIL(0x10d555cd4), 
    vector=XIL(0x10dbbf105), maxdepth=make_fixnum(3), args_template=XIL(0), 
    nargs=0, args=0x0) at bytecode.c:633
#17 0x00000001003174d6 in funcall_lambda (fun=XIL(0x10dbbf155), nargs=0, 
    arg_vector=0x7ffeefbebc60) at eval.c:3067
#18 0x0000000100314c9e in Ffuncall (nargs=1, args=0x7ffeefbebc58)
    at eval.c:2796
#19 0x00000001003a527f in exec_byte_code (bytestr=XIL(0x10bcb9c54), 
    vector=XIL(0x105e347e5), maxdepth=make_fixnum(4), args_template=XIL(0), 
    nargs=0, args=0x0) at bytecode.c:633
#20 0x00000001003174d6 in funcall_lambda (fun=XIL(0x105e34885), nargs=1, 
    arg_vector=0x7ffeefbecc60) at eval.c:3067
#21 0x0000000100314c9e in Ffuncall (nargs=2, args=0x7ffeefbecc58)
--Type <RET> for more, q to quit, c to continue without paging--c
   
#22 0x0000000100315d54 in call1 (fn=XIL(0x105e34885), arg1=XIL(0xda2bad0)) at eval.c:2654
#23 0x000000010037ab0d in mapatoms_1 (sym=XIL(0xda2bad0), function=XIL(0x105e34885)) at lread.c:4380
#24 0x000000010037a9ae in map_obarray (obarray=XIL(0x10e062585), fn=0x10037aaf0 <mapatoms_1>, arg=XIL(0x105e34885)) at lread.c:4369
#25 0x000000010037aad1 in Fmapatoms (function=XIL(0x105e34885), obarray=XIL(0x10e062585)) at lread.c:4391
#26 0x000000010031666c in funcall_subr (subr=0x10055b588, numargs=2, args=0x7ffeefbecfb0) at eval.c:2869
#27 0x0000000100314c4e in Ffuncall (nargs=3, args=0x7ffeefbecfa8) at eval.c:2794
#28 0x00000001003a527f in exec_byte_code (bytestr=XIL(0x10bcb9c14), vector=XIL(0x105e348b5), maxdepth=make_fixnum(6), args_template=XIL(0), nargs=0, args=0x0) at bytecode.c:633
#29 0x00000001003174d6 in funcall_lambda (fun=XIL(0x105e349a5), nargs=0, arg_vector=0x7ffeefbedfd0) at eval.c:3067
#30 0x0000000100314c9e in Ffuncall (nargs=1, args=0x7ffeefbedfc8) at eval.c:2796
#31 0x00000001003a527f in exec_byte_code (bytestr=XIL(0x10d3c1e64), vector=XIL(0x104a577f5), maxdepth=make_fixnum(13), args_template=XIL(0), nargs=0, args=0x0) at bytecode.c:633
#32 0x00000001003174d6 in funcall_lambda (fun=XIL(0x10dcd81a5), nargs=9, arg_vector=0x7ffeefbef420) at eval.c:3067
#33 0x0000000100314c9e in Ffuncall (nargs=10, args=0x7ffeefbef418) at eval.c:2796
#34 0x00000001003a527f in exec_byte_code (bytestr=XIL(0x10d3c16a4), vector=XIL(0x10daee0a5), maxdepth=make_fixnum(11), args_template=XIL(0), nargs=0, args=0x0) at bytecode.c:633
#35 0x00000001003174d6 in funcall_lambda (fun=XIL(0x10dcfa1b5), nargs=2, arg_vector=0x7ffeefbf0770) at eval.c:3067
#36 0x0000000100314c9e in Ffuncall (nargs=3, args=0x7ffeefbf0768) at eval.c:2796
#37 0x00000001002fda6a in Ffuncall_interactively (nargs=3, args=0x7ffeefbf0768) at callint.c:254
#38 0x0000000100316526 in funcall_subr (subr=0x100558d98, numargs=3, args=0x7ffeefbf0768) at eval.c:2847
#39 0x0000000100314c4e in Ffuncall (nargs=4, args=0x7ffeefbf0760) at eval.c:2794
#40 0x0000000100314a06 in Fapply (nargs=3, args=0x7ffeefbf1500) at eval.c:2424
#41 0x00000001002fdfd0 in Fcall_interactively (function=XIL(0x54b0790), record_flag=XIL(0xa770), keys=XIL(0x11e7468a5)) at callint.c:342
#42 0x00000001003166a2 in funcall_subr (subr=0x100558d68, numargs=3, args=0x7ffeefbf17d0) at eval.c:2872
#43 0x0000000100314c4e in Ffuncall (nargs=4, args=0x7ffeefbf17c8) at eval.c:2794
#44 0x00000001003a527f in exec_byte_code (bytestr=XIL(0x10623df8c), vector=XIL(0x10623dadd), maxdepth=make_fixnum(13), args_template=make_fixnum(1025), nargs=2, args=0x7ffeefbf2848) at bytecode.c:633
#45 0x0000000100316d35 in funcall_lambda (fun=XIL(0x10623daad), nargs=2, arg_vector=0x7ffeefbf2838) at eval.c:2989
#46 0x0000000100314c9e in Ffuncall (nargs=3, args=0x7ffeefbf2830) at eval.c:2796
#47 0x00000001003a527f in exec_byte_code (bytestr=XIL(0x10627ee64), vector=XIL(0x10627e965), maxdepth=make_fixnum(15), args_template=make_fixnum(769), nargs=3, args=0x7ffeefbf3be8) at bytecode.c:633
#48 0x0000000100316d35 in funcall_lambda (fun=XIL(0x10627d80d), nargs=3, arg_vector=0x7ffeefbf3bd0) at eval.c:2989
#49 0x0000000100314c9e in Ffuncall (nargs=4, args=0x7ffeefbf3bc8) at eval.c:2796
#50 0x00000001002fda6a in Ffuncall_interactively (nargs=4, args=0x7ffeefbf3bc8) at callint.c:254
#51 0x0000000100316526 in funcall_subr (subr=0x100558d98, numargs=4, args=0x7ffeefbf3bc8) at eval.c:2847
#52 0x0000000100314c4e in Ffuncall (nargs=5, args=0x7ffeefbf3bc0) at eval.c:2794
#53 0x0000000100314a06 in Fapply (nargs=3, args=0x7ffeefbf4970) at eval.c:2424
#54 0x00000001002fdfd0 in Fcall_interactively (function=XIL(0x5844aa8), record_flag=XIL(0), keys=XIL(0x160a78fd5)) at callint.c:342
#55 0x00000001003166a2 in funcall_subr (subr=0x100558d68, numargs=3, args=0x7ffeefbf4c40) at eval.c:2872
#56 0x0000000100314c4e in Ffuncall (nargs=4, args=0x7ffeefbf4c38) at eval.c:2794
#57 0x00000001003a527f in exec_byte_code (bytestr=XIL(0x10623df8c), vector=XIL(0x10623dadd), maxdepth=make_fixnum(13), args_template=make_fixnum(1025), nargs=1, args=0x7ffeefbf5ca8) at bytecode.c:633
#58 0x0000000100316d35 in funcall_lambda (fun=XIL(0x10623daad), nargs=1, arg_vector=0x7ffeefbf5ca0) at eval.c:2989
#59 0x0000000100314c9e in Ffuncall (nargs=2, args=0x7ffeefbf5c98) at eval.c:2796
#60 0x0000000100315d54 in call1 (fn=XIL(0x3960), arg1=XIL(0x5844aa8)) at eval.c:2654
#61 0x00000001001c76b0 in command_loop_1 () at keyboard.c:1463
#62 0x00000001001f4b5e in Fexecute_kbd_macro (macro=XIL(0x10e00fe05), count=XIL(0), loopfunc=XIL(0x43b13e0)) at macros.c:324
#63 0x00000001003166a2 in funcall_subr (subr=0x100553c98, numargs=3, args=0x7ffeefbf6600) at eval.c:2872
#64 0x0000000100314c4e in Ffuncall (nargs=4, args=0x7ffeefbf65f8) at eval.c:2794
#65 0x00000001003a527f in exec_byte_code (bytestr=XIL(0x10d506dd4), vector=XIL(0x10e0532c5), maxdepth=make_fixnum(4), args_template=XIL(0), nargs=0, args=0x0) at bytecode.c:633
#66 0x00000001003174d6 in funcall_lambda (fun=XIL(0x10e053305), nargs=4, arg_vector=0x7ffeefbf75a8) at eval.c:3067
#67 0x0000000100314c9e in Ffuncall (nargs=5, args=0x7ffeefbf75a0) at eval.c:2796
#68 0x0000000100314a06 in Fapply (nargs=3, args=0x7ffeefbf7978) at eval.c:2424
#69 0x0000000100316526 in funcall_subr (subr=0x100559368, numargs=3, args=0x7ffeefbf7978) at eval.c:2847
#70 0x0000000100314c4e in Ffuncall (nargs=4, args=0x7ffeefbf7970) at eval.c:2794
#71 0x00000001003a527f in exec_byte_code (bytestr=XIL(0x10612797c), vector=XIL(0x10e04ff55), maxdepth=make_fixnum(5), args_template=make_fixnum(128), nargs=3, args=0x7ffeefbf8930) at bytecode.c:633
#72 0x0000000100316d35 in funcall_lambda (fun=XIL(0x10e04ff85), nargs=3, arg_vector=0x7ffeefbf8930) at eval.c:2989
#73 0x0000000100314c9e in Ffuncall (nargs=4, args=0x7ffeefbf8928) at eval.c:2796
#74 0x00000001003a527f in exec_byte_code (bytestr=XIL(0x10d3650a4), vector=XIL(0x104e341b5), maxdepth=make_fixnum(6), args_template=make_fixnum(514), nargs=2, args=0x7ffeefbf97c0) at bytecode.c:633
#75 0x0000000100316d35 in funcall_lambda (fun=XIL(0x104e341e5), nargs=2, arg_vector=0x7ffeefbf97b0) at eval.c:2989
#76 0x0000000100311005 in apply_lambda (fun=XIL(0x104e341e5), args=XIL(0x10794c773), count=18) at eval.c:2926
#77 0x000000010030680d in eval_sub (form=XIL(0x10794c6d3)) at eval.c:2318
#78 0x000000010030705d in Fprogn (body=XIL(0)) at eval.c:462
#79 0x00000001003173ec in funcall_lambda (fun=XIL(0x10794c643), nargs=0, arg_vector=0x7ffeefbf9dc0) at eval.c:3060
#80 0x0000000100311005 in apply_lambda (fun=XIL(0x10794c643), args=XIL(0), count=15) at eval.c:2926
#81 0x0000000100306b79 in eval_sub (form=XIL(0x160a862b3)) at eval.c:2348
#82 0x000000010030705d in Fprogn (body=XIL(0)) at eval.c:462
#83 0x0000000100304a44 in eval_sub (form=XIL(0x160a862d3)) at eval.c:2226
#84 0x000000010030f55d in Feval (form=XIL(0x160a862d3), lexical=XIL(0x30)) at eval.c:2102
#85 0x000000010031666c in funcall_subr (subr=0x100559338, numargs=2, args=0x7ffeefbfa820) at eval.c:2869
#86 0x0000000100314c4e in Ffuncall (nargs=3, args=0x7ffeefbfa818) at eval.c:2794
#87 0x00000001003a527f in exec_byte_code (bytestr=XIL(0x10630312c), vector=XIL(0x106302905), maxdepth=make_fixnum(16), args_template=make_fixnum(257), nargs=1, args=0x7ffeefbfb800) at bytecode.c:633
#88 0x0000000100316d35 in funcall_lambda (fun=XIL(0x1063028d5), nargs=1, arg_vector=0x7ffeefbfb7f8) at eval.c:2989
#89 0x0000000100314c9e in Ffuncall (nargs=2, args=0x7ffeefbfb7f0) at eval.c:2796
#90 0x00000001003a527f in exec_byte_code (bytestr=XIL(0x10630327c), vector=XIL(0x10630287d), maxdepth=make_fixnum(4), args_template=make_fixnum(257), nargs=1, args=0x7ffeefbfca58) at bytecode.c:633
#91 0x0000000100316d35 in funcall_lambda (fun=XIL(0x106302845), nargs=1, arg_vector=0x7ffeefbfca50) at eval.c:2989
#92 0x0000000100314c9e in Ffuncall (nargs=2, args=0x7ffeefbfca48) at eval.c:2796
#93 0x00000001002fda6a in Ffuncall_interactively (nargs=2, args=0x7ffeefbfca48) at callint.c:254
#94 0x0000000100316526 in funcall_subr (subr=0x100558d98, numargs=2, args=0x7ffeefbfca48) at eval.c:2847
#95 0x0000000100314c4e in Ffuncall (nargs=3, args=0x7ffeefbfca40) at eval.c:2794
#96 0x0000000100301314 in Fcall_interactively (function=XIL(0x58c9b00), record_flag=XIL(0), keys=XIL(0x160a78fd5)) at callint.c:783
#97 0x00000001003166a2 in funcall_subr (subr=0x100558d68, numargs=3, args=0x7ffeefbfd9c0) at eval.c:2872
#98 0x0000000100314c4e in Ffuncall (nargs=4, args=0x7ffeefbfd9b8) at eval.c:2794
#99 0x00000001003a527f in exec_byte_code (bytestr=XIL(0x10623df8c), vector=XIL(0x10623dadd), maxdepth=make_fixnum(13), args_template=make_fixnum(1025), nargs=1, args=0x7ffeefbfea28) at bytecode.c:633
#100 0x0000000100316d35 in funcall_lambda (fun=XIL(0x10623daad), nargs=1, arg_vector=0x7ffeefbfea20) at eval.c:2989
#101 0x0000000100314c9e in Ffuncall (nargs=2, args=0x7ffeefbfea18) at eval.c:2796
#102 0x0000000100315d54 in call1 (fn=XIL(0x3960), arg1=XIL(0x58c9b00)) at eval.c:2654
#103 0x00000001001c76b0 in command_loop_1 () at keyboard.c:1463
#104 0x000000010030d65f in internal_condition_case (bfun=0x1001c6950 <command_loop_1>, handlers=XIL(0x90), hfun=0x1001ea010 <cmd_error>) at eval.c:1355
#105 0x00000001001e9ef1 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1091
#106 0x000000010030c798 in internal_catch (tag=XIL(0xc450), func=0x1001e9ec0 <command_loop_2>, arg=XIL(0)) at eval.c:1116
#107 0x00000001001c59c5 in command_loop () at keyboard.c:1070
#108 0x00000001001c5797 in recursive_edit_1 () at keyboard.c:714
#109 0x00000001001c5c46 in Frecursive_edit () at keyboard.c:786
#110 0x00000001001c27ae in main (argc=1, argv=0x7ffeefbff660) at emacs.c:2054
[New Thread 0x2f53 of process 39258]

Lisp Backtrace:
"vm-set-summary-pointer" (0xefbeac90)
"vm-do-needed-summary-rebuild" (0xefbebc60)
0x5e34880 PVEC_COMPILED
"mapatoms" (0xefbecfb0)
"vm-update-summary-and-mode-line" (0xefbedfd0)
"vm" (0xefbef420)
"vf" (0xefbf0770)
"funcall-interactively" (0xefbf0768)
"call-interactively" (0xefbf17d0)
"command-execute" (0xefbf2838)
"execute-extended-command" (0xefbf3bd0)
"funcall-interactively" (0xefbf3bc8)
"call-interactively" (0xefbf4c40)
"command-execute" (0xefbf5ca0)
0x553c98 PVEC_SUBR
"ad-Advice-execute-kbd-macro" (0xefbf75a8)
"apply" (0xefbf7978)
"execute-kbd-macro" (0xefbf8930)
"kmacro-exec-ring-item" (0xefbf97b0)
"test-emacs-crash" (0xefbf9dc0)
"progn" (0xefbfa448)
"eval" (0xefbfa820)
"elisp--eval-last-sexp" (0xefbfb7f8)
"eval-last-sexp" (0xefbfca50)
"funcall-interactively" (0xefbfca48)
"call-interactively" (0xefbfd9c0)
"command-execute" (0xefbfea20)
(gdb) f 3
#3  0x000000010023cdc5 in marker_position (marker=XIL(0x12590f575))
    at marker.c:691
691	  register struct Lisp_Marker *m = XMARKER (marker);
(gdb) p marker
$1 = XIL(0x12590f575)
(gdb) xtype
Lisp_Vectorlike
PVEC_NORMAL_VECTOR
(gdb) p m
$2 = (struct Lisp_Marker *) 0x7ffeefbe92d0
(gdb) p *m
$3 = {
  header = {
    size = 140732920665232
  },
  buffer = 0x1002268d7 <report_overlay_modification+263>,
  need_adjustment = true,
  insertion_type = false,
  next = 0x0,
  charpos = 4406354344,
  bytepos = 4305685776
}
(gdb) 


-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Pip Cet <pipcet <at> gmail.com>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, eggert <at> cs.ucla.edu, 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Tue, 17 Mar 2020 04:54:31 +0000

On Tue, Mar 17, 2020 at 3:29 AM Pieter van Oostrum
<pieter-l <at> vanoostrum.org> wrote:
> Pip Cet <pipcet <at> gmail.com> writes:
>
> > Another thing we could try is poisoning the memory area used by a
> > vector when we put it on the free list. Something like the attached
> > patch might work.
>
> I made a new compile with the patch 0001-poison-memory-of-vectors-put-on-the-free-list.patch applied and also the latest 0001-Don-t-collect-reachable-killed-buffers-during-GC.patch (from message ID <CAOqdjBfeL-T8grB+sW+jLoW-JX8Y0siFTzG1q0o+Skc+sKvtSQ <at> mail.gmail.com>) applied.

Thanks!

> (gdb) f 3
> #3  0x000000010023cdc5 in marker_position (marker=XIL(0x12590f575))
>     at marker.c:691
> 691       register struct Lisp_Marker *m = XMARKER (marker);
> (gdb) p marker
> $1 = XIL(0x12590f575)
> (gdb) xtype
> Lisp_Vectorlike
> PVEC_NORMAL_VECTOR
> (gdb) p m
> $2 = (struct Lisp_Marker *) 0x7ffeefbe92d0

m has not been set; it would have been set to 0x12590f570; can you
print out the memory at that address? (x/32gx 0x12590f570)

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

From: Pip Cet <pipcet <at> gmail.com>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, eggert <at> cs.ucla.edu, 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Tue, 17 Mar 2020 05:20:13 +0000

On Tue, Mar 17, 2020 at 4:54 AM Pip Cet <pipcet <at> gmail.com> wrote:
> m has not been set; it would have been set to 0x12590f570; can you
> print out the memory at that address? (x/32gx 0x12590f570)

Actually, regardless of whether the pseudovector type is poisoned or
zero, it would be good to dump that entire vector block (x/512gx
0x12590f000)

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, eggert <at> cs.ucla.edu, 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Tue, 17 Mar 2020 09:40:43 +0100

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

> On Tue, Mar 17, 2020 at 3:29 AM Pieter van Oostrum
> <pieter-l <at> vanoostrum.org> wrote:
>
>> (gdb) f 3
>> #3  0x000000010023cdc5 in marker_position (marker=XIL(0x12590f575))
>>     at marker.c:691
>> 691       register struct Lisp_Marker *m = XMARKER (marker);
>> (gdb) p marker
>> $1 = XIL(0x12590f575)
>> (gdb) xtype
>> Lisp_Vectorlike
>> PVEC_NORMAL_VECTOR
>> (gdb) p m
>> $2 = (struct Lisp_Marker *) 0x7ffeefbe92d0
>
> m has not been set; it would have been set to 0x12590f570; can you
> print out the memory at that address? (x/32gx 0x12590f570)

(gdb) x/32gx 0x12590f570
0x12590f570:	0x0000000000000000	0x000000015b8a3b30
0x12590f580:	0xa5a5a5a5a5a5a5a4	0x000000012590f540
0x12590f590:	0x0000000000014bea	0x0000000000014bea
0x12590f5a0:	0x4000000004001003	0x000000012590f545
0x12590f5b0:	0x000000012590f575	0x000000010e1e2ee3
0x12590f5c0:	0x000000012590f4b0	0xa5a5a5a5a5a5a5a5
0x12590f5d0:	0x4000000003005000	0x000000015b6eedc0
0x12590f5e0:	0xa5a5a5a5a5a5a5a4	0x000000012590f6f0
0x12590f5f0:	0x00000000004d6218	0x00000000004d6218
0x12590f600:	0x0000000000000005	0x000000012590f4e5
0x12590f610:	0x0000000160e78c05	0x0000000125f406a5
0x12590f620:	0x0000000125f40755	0x000000012590f3f5
0x12590f630:	0x4000000003005000	0x000000015b8a3b30
0x12590f640:	0xa5a5a5a5a5a5a5a4	0x000000016082a730
0x12590f650:	0x0000000000014bea	0x0000000000014bea
0x12590f660:	0x4000000003005000	0x000000015b8a3b30
(gdb) 

-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, eggert <at> cs.ucla.edu, 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Tue, 17 Mar 2020 09:45:33 +0100

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

> On Tue, Mar 17, 2020 at 4:54 AM Pip Cet <pipcet <at> gmail.com> wrote:
>> m has not been set; it would have been set to 0x12590f570; can you
>> print out the memory at that address? (x/32gx 0x12590f570)
>
> Actually, regardless of whether the pseudovector type is poisoned or
> zero, it would be good to dump that entire vector block (x/512gx
> 0x12590f000)


(gdb) x/512gx 0x12590f000
0x12590f000:	0x0000000000000000	0x0000000000000000
0x12590f010:	0x0000000000000017	0x00000001256b9424
0x12590f020:	0x00000001256b9404	0x0000000000000000
0x12590f030:	0x000000011e462035	0x000000011e462065
0x12590f040:	0x000000001d5dd350	0x000000001d5dd3b0
0x12590f050:	0x0000000004679390	0x0000000160759b74
0x12590f060:	0x000000015b8f39d5	0x0000000000000000
0x12590f070:	0x0000000000000000	0x0000000000000000
0x12590f080:	0x0000000000000000	0x0000000000000000
0x12590f090:	0x0000000000000000	0x0000000000000000
0x12590f0a0:	0x0000000000000000	0x00000001608249a5
0x12590f0b0:	0x0000000000000000	0x0000000000000000
0x12590f0c0:	0x000000001d5dd350	0x0000000000000000
0x12590f0d0:	0x4000000003005000	0x000000015b8f39d0
0x12590f0e0:	0xa5a5a5a5a5a5a5a4	0x000000010df98aa0
0x12590f0f0:	0x000000000201db7b	0x000000000201db7b
0x12590f100:	0x4000000003005000	0x000000015b8f39d0
0x12590f110:	0xa5a5a5a5a5a5a5a4	0x000000012590f0d0
0x12590f120:	0x0000000002023612	0x0000000002023612
0x12590f130:	0x4000000003005000	0x000000015b8f39d0
0x12590f140:	0xa5a5a5a5a5a5a5a4	0x000000012590f100
0x12590f150:	0x0000000002023613	0x0000000002023613
0x12590f160:	0x0000000000000005	0x000000012590f255
0x12590f170:	0x000000012590f195	0x000000011e657125
0x12590f180:	0x000000011e6571d5	0x000000012590f295
0x12590f190:	0x0000000000000017	0x00000001256b93e4
0x12590f1a0:	0x00000001256b93c4	0x0000000000000000
0x12590f1b0:	0x000000011e463f35	0x000000011e463f65
0x12590f1c0:	0x000000001d5dd3e0	0x000000001d5dd440
0x12590f1d0:	0x0000000004679390	0x0000000160759b54
0x12590f1e0:	0x000000015b8f39d5	0x0000000000000000
0x12590f1f0:	0x0000000000000000	0x0000000000000000
0x12590f200:	0x0000000000000000	0x0000000000000000
0x12590f210:	0x0000000000000000	0x0000000000000000
0x12590f220:	0x0000000000000000	0x0000000160824a95
0x12590f230:	0x0000000000000000	0x0000000000000000
0x12590f240:	0x000000001d5dd3e0	0x0000000000000000
0x12590f250:	0x0000000000000006	0x0000000105d6fe45
0x12590f260:	0x0000000105d6fe75	0x0000000000000000
0x12590f270:	0x000000011e6570f5	0x0000000105d6fea5
0x12590f280:	0x0000000105d6fed5	0xa5a5a5a5a5a5a5a5
0x12590f290:	0x0000000000000006	0x0000000000000000
0x12590f2a0:	0x000000001d5dd410	0x0000000000000000
0x12590f2b0:	0x0000000105af1113	0x0000000000000000
0x12590f2c0:	0x0000000000000000	0xa5a5a5a5a5a5a5a5
0x12590f2d0:	0x4000000004001003	0x000000011e3b7f55
0x12590f2e0:	0x000000011e3b7f85	0x000000010e1e45f3
0x12590f2f0:	0x000000011e3b7ec0	0xa5a5a5a5a5a5a5a5
0x12590f300:	0x4000000003005000	0x000000015b6eedc0
0x12590f310:	0xa5a5a5a5a5a5a5a4	0x000000012590f5d0
0x12590f320:	0x00000000004d6218	0x00000000004d6218
0x12590f330:	0x4000000003005000	0x000000015b6eedc0
0x12590f340:	0xa5a5a5a5a5a5a5a4	0x000000012590f300
0x12590f350:	0x00000000004d6244	0x00000000004d6244
0x12590f360:	0x4000000003005000	0x000000015b8a3b30
0x12590f370:	0xa5a5a5a5a5a5a5a4	0x000000016082aa00
0x12590f380:	0x0000000000014b02	0x0000000000014b02
0x12590f390:	0x4000000003005000	0x000000015b8a3b30
0x12590f3a0:	0xa5a5a5a5a5a5a5a4	0x000000012590f360
0x12590f3b0:	0x0000000000014b5f	0x0000000000014b5f
0x12590f3c0:	0x4000000004001003	0x000000012590f365
0x12590f3d0:	0x000000012590f395	0x000000010e1e42e3
0x12590f3e0:	0x000000012590f2d0	0xa5a5a5a5a5a5a5a5
0x12590f3f0:	0x0000000000000006	0x0000000000000000
0x12590f400:	0x000000000d4269c0	0x0000000000000000
0x12590f410:	0x0000000000000000	0x0000000000000000
0x12590f420:	0x0000000000000000	0xa5a5a5a5a5a5a5a5
0x12590f430:	0x0000000000000002	0x0000000000008df0
0x12590f440:	0x0000000005757688	0xa5a5a5a5a5a5a5a5
0x12590f450:	0x4000000003005000	0x000000015b8a3b30
0x12590f460:	0xa5a5a5a5a5a5a5a4	0x000000016082a910
0x12590f470:	0x0000000000014b5f	0x0000000000014b5f
--Type <RET> for more, q to quit, c to continue without paging--c
0x12590f480:	0x4000000003005000	0x000000015b8a3b30
0x12590f490:	0xa5a5a5a5a5a5a5a4	0x000000012590f450
0x12590f4a0:	0x0000000000014ba0	0x0000000000014ba0
0x12590f4b0:	0x4000000004001003	0x000000012590f455
0x12590f4c0:	0x000000012590f485	0x000000010e1e37c3
0x12590f4d0:	0x000000012590f3c0	0xa5a5a5a5a5a5a5a5
0x12590f4e0:	0x0000000000000006	0x000000012590f305
0x12590f4f0:	0x000000012590f335	0x0000000000000000
0x12590f500:	0x0000000125f40675	0x0000000160d3f7a5
0x12590f510:	0x0000000160d3f7d5	0xa5a5a5a5a5a5a5a5
0x12590f520:	0x4000000002002000	0x0000000200000003
0x12590f530:	0x000000011de53fc0	0xa5a5a5a5a5a5a5a5
0x12590f540:	0x4000000003005000	0x000000015b8a3b30
0x12590f550:	0xa5a5a5a5a5a5a5a4	0x000000016082a820
0x12590f560:	0x0000000000014ba0	0x0000000000014ba0
0x12590f570:	0x0000000000000000	0x000000015b8a3b30
0x12590f580:	0xa5a5a5a5a5a5a5a4	0x000000012590f540
0x12590f590:	0x0000000000014bea	0x0000000000014bea
0x12590f5a0:	0x4000000004001003	0x000000012590f545
0x12590f5b0:	0x000000012590f575	0x000000010e1e2ee3
0x12590f5c0:	0x000000012590f4b0	0xa5a5a5a5a5a5a5a5
0x12590f5d0:	0x4000000003005000	0x000000015b6eedc0
0x12590f5e0:	0xa5a5a5a5a5a5a5a4	0x000000012590f6f0
0x12590f5f0:	0x00000000004d6218	0x00000000004d6218
0x12590f600:	0x0000000000000005	0x000000012590f4e5
0x12590f610:	0x0000000160e78c05	0x0000000125f406a5
0x12590f620:	0x0000000125f40755	0x000000012590f3f5
0x12590f630:	0x4000000003005000	0x000000015b8a3b30
0x12590f640:	0xa5a5a5a5a5a5a5a4	0x000000016082a730
0x12590f650:	0x0000000000014bea	0x0000000000014bea
0x12590f660:	0x4000000003005000	0x000000015b8a3b30
0x12590f670:	0xa5a5a5a5a5a5a5a4	0x000000012590f630
0x12590f680:	0x0000000000014c47	0x0000000000014c47
0x12590f690:	0x4000000004001003	0x000000012590f635
0x12590f6a0:	0x000000012590f665	0x000000010e1e9983
0x12590f6b0:	0x000000012590f5a0	0xa5a5a5a5a5a5a5a5
0x12590f6c0:	0x4000000003005000	0x000000015b6eedc0
0x12590f6d0:	0xa5a5a5a5a5a5a5a4	0x0000000125bec110
0x12590f6e0:	0x00000000004d4dc1	0x00000000004d4dc1
0x12590f6f0:	0x4000000003005000	0x000000015b6eedc0
0x12590f700:	0xa5a5a5a5a5a5a5a4	0x000000012590f6c0
0x12590f710:	0x00000000004d6217	0x00000000004d6217
0x12590f720:	0x4000000003005000	0x000000015b8a3b30
0x12590f730:	0xa5a5a5a5a5a5a5a4	0x000000016082a640
0x12590f740:	0x0000000000014c47	0x0000000000014c47
0x12590f750:	0x4000000003005000	0x000000015b8a3b30
0x12590f760:	0xa5a5a5a5a5a5a5a4	0x000000012590f720
0x12590f770:	0x0000000000014ca4	0x0000000000014ca4
0x12590f780:	0x4000000001001000	0x000000011e7e6c62
0x12590f790:	0x4000000003005000	0x000000015b8f39d0
0x12590f7a0:	0xa5a5a5a5a5a5a5a4	0x0000000160ab0400
0x12590f7b0:	0x00000000037026a3	0x00000000037026a3
0x12590f7c0:	0x4000000003005000	0x000000015b8f39d0
0x12590f7d0:	0xa5a5a5a5a5a5a5a4	0x000000012590f790
0x12590f7e0:	0x00000000037026a4	0x00000000037026a4
0x12590f7f0:	0x0000000000000005	0x000000012590f8e5
0x12590f800:	0x000000012590f825	0x0000000125ca5745
0x12590f810:	0x0000000125ca57f5	0x000000012590f925
0x12590f820:	0x0000000000000017	0x0000000160655624
0x12590f830:	0x0000000160655604	0x0000000000000000
0x12590f840:	0x000000010e56e6f5	0x000000010e56e725
0x12590f850:	0x000000001dd58ab0	0x000000000cfa8b20
0x12590f860:	0x0000000004679390	0x000000010d7f8a34
0x12590f870:	0x000000015b8f39d5	0x0000000000000000
0x12590f880:	0x0000000000000000	0x0000000000000000
0x12590f890:	0x0000000000000000	0x0000000000000000
0x12590f8a0:	0x0000000000000000	0x0000000000000000
0x12590f8b0:	0x0000000000000000	0x000000011e436a55
0x12590f8c0:	0x0000000000000000	0x0000000000000000
0x12590f8d0:	0x000000001dd58ab0	0x0000000000000000
0x12590f8e0:	0x0000000000000006	0x000000012590f965
0x12590f8f0:	0x000000012590f995	0x0000000000000000
0x12590f900:	0x0000000160b973b5	0x000000012590f9c5
0x12590f910:	0x000000012590f9f5	0xa5a5a5a5a5a5a5a5
0x12590f920:	0x0000000000000006	0x0000000000000000
0x12590f930:	0x000000000cfa8af0	0x0000000000000000
0x12590f940:	0x0000000000000000	0x0000000000000000
0x12590f950:	0x0000000000000000	0xa5a5a5a5a5a5a5a5
0x12590f960:	0x4000000003005000	0x000000015b8f39d0
0x12590f970:	0xa5a5a5a5a5a5a5a4	0x000000012590f7c0
0x12590f980:	0x00000000037026a4	0x00000000037026a4
0x12590f990:	0x4000000003005000	0x000000015b8f39d0
0x12590f9a0:	0xa5a5a5a5a5a5a5a4	0x000000012590f960
0x12590f9b0:	0x0000000003702728	0x0000000003702728
0x12590f9c0:	0x4000000003005000	0x000000015b8f39d0
0x12590f9d0:	0xa5a5a5a5a5a5a5a4	0x000000012590f990
0x12590f9e0:	0x0000000003708343	0x0000000003708343
0x12590f9f0:	0x4000000003005000	0x000000015b8f39d0
0x12590fa00:	0xa5a5a5a5a5a5a5a4	0x000000012590f9c0
0x12590fa10:	0x0000000003708344	0x0000000003708344
0x12590fa20:	0x0000000000000005	0x000000012590fb15
0x12590fa30:	0x000000012590fa55	0x0000000125ca59c5
0x12590fa40:	0x0000000125ca5a75	0x000000012590fb55
0x12590fa50:	0x0000000000000017	0x00000001606555e4
0x12590fa60:	0x00000001606555c4	0x0000000000000000
0x12590fa70:	0x000000010e56e755	0x000000010e56e785
0x12590fa80:	0x000000000cfa8b50	0x000000000cfa8bb0
0x12590fa90:	0x0000000004679390	0x000000010d7f8a14
0x12590faa0:	0x000000015b8f39d5	0x0000000000000000
0x12590fab0:	0x0000000000000000	0x0000000000000000
0x12590fac0:	0x0000000000000000	0x0000000000000000
0x12590fad0:	0x0000000000000000	0x0000000000000000
0x12590fae0:	0x0000000000000000	0x000000011e436b45
0x12590faf0:	0x0000000000000000	0x0000000000000000
0x12590fb00:	0x000000000cfa8b50	0x0000000000000000
0x12590fb10:	0x0000000000000006	0x000000012590fb95
0x12590fb20:	0x000000012590fbc5	0x0000000000000000
0x12590fb30:	0x0000000125ca5995	0x000000010e078605
0x12590fb40:	0x000000010e078635	0xa5a5a5a5a5a5a5a5
0x12590fb50:	0x0000000000000006	0x0000000000000000
0x12590fb60:	0x000000000cfa8b80	0x0000000000000000
0x12590fb70:	0x0000000000000000	0x0000000000000000
0x12590fb80:	0x0000000000000000	0xa5a5a5a5a5a5a5a5
0x12590fb90:	0x4000000003005000	0x000000015b8f39d0
0x12590fba0:	0xa5a5a5a5a5a5a5a4	0x000000012590f9f0
0x12590fbb0:	0x0000000003708344	0x0000000003708344
0x12590fbc0:	0x4000000003005000	0x000000015b8f39d0
0x12590fbd0:	0xa5a5a5a5a5a5a5a4	0x000000012590fb90
0x12590fbe0:	0x00000000037083c8	0x00000000037083c8
0x12590fbf0:	0x00000001079ffc00	0x0000000000000000
0x12590fc00:	0x0000000000000002	0x0000000000004c9a
0x12590fc10:	0x000000012590fca8	0x0000000000000000
0x12590fc20:	0x000000012590fd18	0x0000000125907fc0
0x12590fc30:	0x000000010e764273	0x0000000000000001
0x12590fc40:	0x000000000000008c	0x0000000000000000
0x12590fc50:	0x0000000000000000	0x00000001609e4bb8
0x12590fc60:	0x0000000125913c80	0x0000000160ae8563
0x12590fc70:	0x0000000000000003	0x0000000000000099
0x12590fc80:	0x000000012590fdc0	0x000000012590fed8
0x12590fc90:	0x000000012590fd50	0x0000000125913c80
0x12590fca0:	0x0000000160ae6f33	0x0000000000000001
0x12590fcb0:	0x0000000000004c99	0x0000000000000000
0x12590fcc0:	0x0000000000000000	0x000000012590fc00
0x12590fcd0:	0x0000000125913cc0	0x000000010e764843
0x12590fce0:	0x0000000000000001	0x0000000000000096
0x12590fcf0:	0x0000000000000000	0x0000000000000000
0x12590fd00:	0x000000012590fd50	0x0000000125913cc0
0x12590fd10:	0x0000000160ae83d3	0x0000000000000007
0x12590fd20:	0x0000000000004c96	0x000000012590fd88
0x12590fd30:	0x000000012590fc00	0x0000000125907b80
0x12590fd40:	0x0000000125913d00	0x000000010e764863
0x12590fd50:	0x0000000000000005	0x0000000000000097
0x12590fd60:	0x000000012590fce0	0x000000012590fc70
0x12590fd70:	0x000000012590fdf8	0x0000000125913d00
0x12590fd80:	0x0000000160ae6fb3	0x0000000000000002
0x12590fd90:	0x0000000000004c94	0x0000000000000000
0x12590fda0:	0x0000000000000000	0x000000012590fd18
0x12590fdb0:	0x0000000125913dc0	0x000000010e764883
0x12590fdc0:	0x0000000000000001	0x0000000000000098
0x12590fdd0:	0x0000000000000000	0x0000000000000000
0x12590fde0:	0x000000012590fc70	0x0000000125913dc0
0x12590fdf0:	0x0000000160ae6f73	0x000000000000000b
0x12590fe00:	0x000000000000009b	0x000000012590fd50
0x12590fe10:	0x000000012590ff80	0x00000001609e4bb8
0x12590fe20:	0x0000000000000000	0x0000000160ae6eb3
0x12590fe30:	0x000000000000000d	0x0000000000000000
0x12590fe40:	0x0000000000000000	0x000000012590fe68
0x12590fe50:	0x0000000125731bc4	0x0000000000000001
0x12590fe60:	0x0000000000000000	0x0000000000000005
0x12590fe70:	0x0000000000000008	0x0000000000000000
0x12590fe80:	0x0000000000000000	0x000000012590fe30
0x12590fe90:	0x0000000000000000	0x0000000160ae7f23
0x12590fea0:	0x000000000000008e	0x0000000000004c68
0x12590feb0:	0x000000012590ff48	0x0000000125907b80
0x12590fec0:	0x00000001609e48e0	0x0000000000000000
0x12590fed0:	0x000000010e764ae3	0x0000000000000001
0x12590fee0:	0x000000000000009a	0x0000000000000000
0x12590fef0:	0x0000000000000000	0x000000012590fc70
0x12590ff00:	0x0000000000000000	0x0000000160ae6ef3
0x12590ff10:	0x0000000000000101	0x00000000000000a1
0x12590ff20:	0x0000000160f38748	0x000000011e7d7000
0x12590ff30:	0x000000016070fca5	0x0000000000000001
0x12590ff40:	0x0000000160ae6e33	0x0000000000000031
0x12590ff50:	0x0000000000004c3e	0x00000001609e4838
0x12590ff60:	0x0000000000000000	0x000000012590fea0
0x12590ff70:	0x0000000000000000	0x000000010e764b03
0x12590ff80:	0x0000000000000001	0x00000000000000a0
0x12590ff90:	0x0000000000000000	0x0000000000000000
0x12590ffa0:	0x000000012590fdf8	0x0000000000000000
0x12590ffb0:	0x0000000160ae6e73	0x0000000000000002
0x12590ffc0:	0x0000000000004c3d	0x00000001609e4800
0x12590ffd0:	0x0000000000000000	0x00000001609e4838
0x12590ffe0:	0x0000000000000000	0x000000010e764b33
0x12590fff0:	0x00000001609e4800	0x0000000000000000
(gdb) 

-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Pip Cet <pipcet <at> gmail.com>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, eggert <at> cs.ucla.edu, 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Tue, 17 Mar 2020 13:54:05 +0000

[Message part 1 (text/plain, inline)]

On Tue, Mar 17, 2020 at 8:45 AM Pieter van Oostrum
<pieter-l <at> vanoostrum.org> wrote:
> Pip Cet <pipcet <at> gmail.com> writes:
> > On Tue, Mar 17, 2020 at 4:54 AM Pip Cet <pipcet <at> gmail.com> wrote:
> >> m has not been set; it would have been set to 0x12590f570; can you
> >> print out the memory at that address? (x/32gx 0x12590f570)
> >
> > Actually, regardless of whether the pseudovector type is poisoned or
> > zero,

It's zero.

> > it would be good to dump that entire vector block (x/512gx
> > 0x12590f000)

> 0x12590f3f0:    0x0000000000000006      0x0000000000000000
> 0x12590f400:    0x000000000d4269c0      0x0000000000000000

I'm suspicious about this "symbol". Is 0xd4269c0 a valid lisp value?

> 0x12590f430:    0x0000000000000002      0x0000000000008df0
> 0x12590f440:    0x0000000005757688      0xa5a5a5a5a5a5a5a5

This vector is weird. The first entry is a symbol, but the second
entry looks invalid to me: all other symbols are aligned to 16-byte
boundaries, and I don't think 0x5757688 is even a valid pointer.

Can you check which symbol corresponds to 0x8df0 in your build? It
should be the one with 757 in its define line in globals.h

# define Qlibpng_version builtin_lisp_symbol (757)

> 0x12590f520:    0x4000000002002000      0x0000000200000003
> 0x12590f530:    0x000000011de53fc0      0xa5a5a5a5a5a5a5a5

A real-life bignum! Can you print x/2gx 0x11de53fc0 so we figure out
what its value is? (And what's creating bignums in your session?)

> 0x12590f540:    0x4000000003005000      0x000000015b8a3b30
> 0x12590f550:    0xa5a5a5a5a5a5a5a4      0x000000016082a820
> 0x12590f560:    0x0000000000014ba0      0x0000000000014ba0
> 0x12590f570:    0x0000000000000000      0x000000015b8a3b30

That's our corrupt word.

> 0x12590fbf0:    0x00000001079ffc00      0x0000000000000000

And that's the end of the vector block.

If you want to, you can try the attached patch and see whether it
produces anything poisoned rather than merely corrupt.

Thanks again!

[0001-more-debugging.patch (text/x-patch, attachment)]

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, eggert <at> cs.ucla.edu, 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Tue, 17 Mar 2020 16:27:38 +0100

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

> On Tue, Mar 17, 2020 at 8:45 AM Pieter van Oostrum
> <pieter-l <at> vanoostrum.org> wrote:
>> Pip Cet <pipcet <at> gmail.com> writes:
>> > On Tue, Mar 17, 2020 at 4:54 AM Pip Cet <pipcet <at> gmail.com> wrote:
>> >> m has not been set; it would have been set to 0x12590f570; can you
>> >> print out the memory at that address? (x/32gx 0x12590f570)
>> >
>> > Actually, regardless of whether the pseudovector type is poisoned or
>> > zero,
>
> It's zero.
>
>> > it would be good to dump that entire vector block (x/512gx
>> > 0x12590f000)
>
>> 0x12590f3f0:    0x0000000000000006      0x0000000000000000
>> 0x12590f400:    0x000000000d4269c0      0x0000000000000000
>
> I'm suspicious about this "symbol". Is 0xd4269c0 a valid lisp value?

I'm sorry. I don't know how to find out. I'm just a newbee with debugging elisp in gdb.

>> 0x12590f430:    0x0000000000000002      0x0000000000008df0
>> 0x12590f440:    0x0000000005757688      0xa5a5a5a5a5a5a5a5
>
> This vector is weird. The first entry is a symbol, but the second
> entry looks invalid to me: all other symbols are aligned to 16-byte
> boundaries, and I don't think 0x5757688 is even a valid pointer.
>
> Can you check which symbol corresponds to 0x8df0 in your build? It
> should be the one with 757 in its define line in globals.h
>
> # define Qlibpng_version builtin_lisp_symbol (757)

Sorry, again, I don't know how to find that symbol. I guess it's one of the functions defined in .gdbinit, but I don't know which one.

And in globals.h, the numbers are different.

# define Qlibpng_version builtin_lisp_symbol (687)
# define Qmode_line builtin_lisp_symbol (757)


>> 0x12590f520:    0x4000000002002000      0x0000000200000003
>> 0x12590f530:    0x000000011de53fc0      0xa5a5a5a5a5a5a5a5
>
> A real-life bignum! Can you print x/2gx 0x11de53fc0 so we figure out
> what its value is? (And what's creating bignums in your session?)

(gdb) x/2gx 0x11de53fc0 
0x11de53fc0:	0xe3fedf0cbab410c0	0x0000000000000055

I don't think there is something explicitely creating bignums. But could it be the result of a calculation that doesn't fit in an normal int?
>
>> 0x12590f540:    0x4000000003005000      0x000000015b8a3b30
>> 0x12590f550:    0xa5a5a5a5a5a5a5a4      0x000000016082a820
>> 0x12590f560:    0x0000000000014ba0      0x0000000000014ba0
>> 0x12590f570:    0x0000000000000000      0x000000015b8a3b30
>
> That's our corrupt word.
>
>> 0x12590fbf0:    0x00000001079ffc00      0x0000000000000000
>
> And that's the end of the vector block.
>
> If you want to, you can try the attached patch and see whether it
> produces anything poisoned rather than merely corrupt.
>
I'll do that after I have extracted enough information from the current setting.

-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, pipcet <at> gmail.com
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Tue, 17 Mar 2020 17:33:22 +0200

> From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  39962 <at> debbugs.gnu.org,  eggert <at> cs.ucla.edu
> Date: Tue, 17 Mar 2020 04:29:09 +0100
> 
> ./lisp.h:2623: Emacs fatal error: assertion failed: MARKERP (a)
> 
> Thread 3 hit Breakpoint 1, terminate_due_to_signal (sig=6, 
>     backtrace_limit=2147483647) at emacs.c:371
> 371	  signal (sig, SIG_DFL);
> (gdb) bt
> #0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:371
> #1  0x00000001002a4b2b in die (msg=0x1004f65cc "MARKERP (a)", 
>     file=0x1004f0449 "./lisp.h", line=2623) at alloc.c:7249
> #2  0x000000010023c21f in XMARKER (a=XIL(0x12590f575)) at ./lisp.h:2623
> #3  0x000000010023cdc5 in marker_position (marker=XIL(0x12590f575))
>     at marker.c:691
> #4  0x0000000100221335 in OVERLAY_POSITION (p=XIL(0x12590f575))
>     at ./buffer.h:1394
> #5  0x00000001002268d7 in report_overlay_modification (
>     start=make_fixnum(40255), end=make_fixnum(40255), after=false, 
>     arg1=make_fixnum(40255), arg2=make_fixnum(40255), arg3=XIL(0))
>     at buffer.c:4496

This is here:

      /* We are being called before a change.
	 Scan the overlays to find the functions to call.  */
      last_overlay_modification_hooks_used = 0;
      for (struct Lisp_Overlay *tail = current_buffer->overlays_before;
	   tail; tail = tail->next)
	{
	  ptrdiff_t startpos, endpos;
	  Lisp_Object ostart, oend;

	  Lisp_Object overlay = make_lisp_ptr (tail, Lisp_Vectorlike);

	  ostart = OVERLAY_START (overlay);
	  oend = OVERLAY_END (overlay);
	  endpos = OVERLAY_POSITION (oend); <<<<<<<<<<<<<<<<
	  if (XFIXNAT (start) > endpos)
	    break;
	  startpos = OVERLAY_POSITION (ostart);

Are this overlay's other fields valid?  E.g., what about ostart -- is
it a valid marker, and if so, what buffer does it point to? is that
buffer identical to current_buffer?

Also, can you go through this linked list of the overlays (it starts
at current_buffer->overlays_before), and see if there are other
overlays there that are similarly invalid?  Likewise with overlays
that start at current_buffer->overlays_after.

And what is current_buffer, anyway?  Any idea what are those overlays
in that buffer?

Btw, note that we again have mapatoms in the backtrace -- it
definitely has something to do with this.

Thanks.

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

From: Pip Cet <pipcet <at> gmail.com>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, eggert <at> cs.ucla.edu, 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Tue, 17 Mar 2020 20:16:14 +0000

On Tue, Mar 17, 2020 at 3:27 PM Pieter van Oostrum
<pieter-l <at> vanoostrum.org> wrote:
> Pip Cet <pipcet <at> gmail.com> writes:
> > On Tue, Mar 17, 2020 at 8:45 AM Pieter van Oostrum
> > <pieter-l <at> vanoostrum.org> wrote:
> >> 0x12590f3f0:    0x0000000000000006      0x0000000000000000
> >> 0x12590f400:    0x000000000d4269c0      0x0000000000000000
> >
> > I'm suspicious about this "symbol". Is 0xd4269c0 a valid lisp value?
>
> I'm sorry. I don't know how to find out. I'm just a newbee with debugging elisp in gdb.

I believe "xprintsym 0xd4269c0" would work on macOS, too. I'm not sure
whether "pp 0xd4269c0" would.

"x/32gx 0xd4269c0" would also be interesting, potentially, if that is
a valid memory address.

> >> 0x12590f430:    0x0000000000000002      0x0000000000008df0
> >> 0x12590f440:    0x0000000005757688      0xa5a5a5a5a5a5a5a5
> >
> > This vector is weird. The first entry is a symbol, but the second
> > entry looks invalid to me: all other symbols are aligned to 16-byte
> > boundaries, and I don't think 0x5757688 is even a valid pointer.

"x/32gx 0x5757688" would also be interesting if it works.

> > Can you check which symbol corresponds to 0x8df0 in your build? It
> > should be the one with 757 in its define line in globals.h
> >
> > # define Qlibpng_version builtin_lisp_symbol (757)
>
> Sorry, again, I don't know how to find that symbol. I guess it's one of the functions defined in .gdbinit, but I don't know which one.
>
> And in globals.h, the numbers are different.
>
> # define Qlibpng_version builtin_lisp_symbol (687)
> # define Qmode_line builtin_lisp_symbol (757)

Thanks, that's precisely what I wanted to know. So it's a vector
[mode-line X], where X is either a very peculiar symbol or invalid.

> >> 0x12590f520:    0x4000000002002000      0x0000000200000003
> >> 0x12590f530:    0x000000011de53fc0      0xa5a5a5a5a5a5a5a5
> >
> > A real-life bignum! Can you print x/2gx 0x11de53fc0 so we figure out
> > what its value is? (And what's creating bignums in your session?)
>
> (gdb) x/2gx 0x11de53fc0
> 0x11de53fc0:    0xe3fedf0cbab410c0      0x0000000000000055
>
> I don't think there is something explicitely creating bignums. But could it be the result of a calculation that doesn't fit in an normal int?

It's a picosecond time stamp, so that's okay.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>, Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org, pipcet <at> gmail.com
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Tue, 17 Mar 2020 13:59:04 -0700

Although I haven't been following this in detail, I'd like to suggest trying a 
GDB watchpoint to find the bug. Watchpoints have been invaluable to me when I 
debug garbage-collector and other memory management issues.

Say you have a repeatable way to make the problem happen. You discover that some 
random part of Emacs (you don't know what) has zapped the 'next' field of some 
data structure D to make it a null pointer. You want to find out who zapped it.

To do that, first compute the address of the field you're interested in:

(gdb) p &D->next

You'll get a number like 0x16082a730.

Then:

(gdb) watch *(void *)0x16082a730
(gdb) run

The last command re-runs Emacs, and should stop each time the memory location at 
0x16082a730 changes. If you're lucky, this will be just a few times and you can 
figure out who's zapping D->next. If you're unlucky you can come up with a 
fancier watchpoint that may do the trick. (I'm using a plain 'watch' rather than 
a 'watch -l' in the example above, merely to keep things simple.)

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, eggert <at> cs.ucla.edu, 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Wed, 18 Mar 2020 00:32:42 +0100

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

> On Tue, Mar 17, 2020 at 3:27 PM Pieter van Oostrum
> <pieter-l <at> vanoostrum.org> wrote:
>> Pip Cet <pipcet <at> gmail.com> writes:
>> > On Tue, Mar 17, 2020 at 8:45 AM Pieter van Oostrum
>> > <pieter-l <at> vanoostrum.org> wrote:
>> >> 0x12590f3f0:    0x0000000000000006      0x0000000000000000
>> >> 0x12590f400:    0x000000000d4269c0      0x0000000000000000
>> >
>> > I'm suspicious about this "symbol". Is 0xd4269c0 a valid lisp value?
>>
>> I'm sorry. I don't know how to find out. I'm just a newbee with debugging elisp in gdb.
>
> I believe "xprintsym 0xd4269c0" would work on macOS, too. I'm not sure
> whether "pp 0xd4269c0" would.

(gdb) xprintsym 0xd4269c0
Invalid number "0xd4269c0.i".
(gdb) pp 0xd4269c0
Invalid cast.

>
> "x/32gx 0xd4269c0" would also be interesting, potentially, if that is
> a valid memory address.

(gdb) x/32gx 0xd4269c0
0xd4269c0:	Cannot access memory at address 0xd4269c0


>> >> 0x12590f430:    0x0000000000000002      0x0000000000008df0
>> >> 0x12590f440:    0x0000000005757688      0xa5a5a5a5a5a5a5a5
>> >
>> > This vector is weird. The first entry is a symbol, but the second
>> > entry looks invalid to me: all other symbols are aligned to 16-byte
>> > boundaries, and I don't think 0x5757688 is even a valid pointer.
>
> "x/32gx 0x5757688" would also be interesting if it works.

(gdb) x/32gx 0x5757688
0x5757688:	Cannot access memory at address 0x5757688

>> > Can you check which symbol corresponds to 0x8df0 in your build? It
>> > should be the one with 757 in its define line in globals.h
>> >
>> > # define Qlibpng_version builtin_lisp_symbol (757)
>>
>> Sorry, again, I don't know how to find that symbol. I guess it's one
>> of the functions defined in .gdbinit, but I don't know which one.
>>
>> And in globals.h, the numbers are different.
>>
>> # define Qlibpng_version builtin_lisp_symbol (687)
>> # define Qmode_line builtin_lisp_symbol (757)
>
> Thanks, that's precisely what I wanted to know. So it's a vector
> [mode-line X], where X is either a very peculiar symbol or invalid.
>
>> >> 0x12590f520:    0x4000000002002000      0x0000000200000003
>> >> 0x12590f530:    0x000000011de53fc0      0xa5a5a5a5a5a5a5a5
>> >
>> > A real-life bignum! Can you print x/2gx 0x11de53fc0 so we figure out
>> > what its value is? (And what's creating bignums in your session?)
>>
>> (gdb) x/2gx 0x11de53fc0
>> 0x11de53fc0:    0xe3fedf0cbab410c0      0x0000000000000055
>>
>> I don't think there is something explicitely creating bignums. But
>> could it be the result of a calculation that doesn't fit in an normal
>> int?
>
> It's a picosecond time stamp, so that's okay.

-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Pip Cet <pipcet <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Pieter van Oostrum <pieter-l <at> vanoostrum.org>,
 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Wed, 18 Mar 2020 06:17:01 +0000

On Tue, Mar 17, 2020 at 8:59 PM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> Although I haven't been following this in detail, I'd like to suggest trying a
> GDB watchpoint to find the bug. Watchpoints have been invaluable to me when I
> debug garbage-collector and other memory management issues.

They are! Unfortunately, they require a predictable address at which
the corruption happens, and we don't appear to have that.

> (gdb) watch *(void *)0x16082a730

I think you mean

watch *(void **)0x16082a730

Right?

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 39962 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>,
 Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Wed, 18 Mar 2020 10:22:28 +0100

>>>>> On Wed, 18 Mar 2020 06:17:01 +0000, Pip Cet <pipcet <at> gmail.com> said:

    Pip> On Tue, Mar 17, 2020 at 8:59 PM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
    >> Although I haven't been following this in detail, I'd like to suggest trying a
    >> GDB watchpoint to find the bug. Watchpoints have been invaluable to me when I
    >> debug garbage-collector and other memory management issues.

    Pip> They are! Unfortunately, they require a predictable address at which
    Pip> the corruption happens, and we don't appear to have that.

You have a known address if you use rr and run in reverse.

Robert

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 39962 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>,
 Pip Cet <pipcet <at> gmail.com>
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Wed, 18 Mar 2020 12:38:43 +0100

Robert Pluim <rpluim <at> gmail.com> writes:

>>>>>> On Wed, 18 Mar 2020 06:17:01 +0000, Pip Cet <pipcet <at> gmail.com> said:
>
>     Pip> On Tue, Mar 17, 2020 at 8:59 PM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
>     >> Although I haven't been following this in detail, I'd like to suggest trying a
>     >> GDB watchpoint to find the bug. Watchpoints have been invaluable to me when I
>     >> debug garbage-collector and other memory management issues.
>
>     Pip> They are! Unfortunately, they require a predictable address at which
>     Pip> the corruption happens, and we don't appear to have that.
>
> You have a known address if you use rr and run in reverse.
>
> Robert
>

I have a procedure to generate a crash, but it isn't very predictable. I think that is because there are timers running and asynchronous processes. I get a different crash each time I run it.

The crash generation involves opening two large mailboxes with VM (it could be that one would also work). I then manipulate them both, re-sorting them in a different order, saving, switching between the two, sorting back to my preferred order, saving and closing. I have saved this procedure in a keyboard macro, giving it a name. I copied the definition to another Emacs session. To recreate the crash, I copy the definition to the new Emacs session in the *scratch* buffer, and I can then invoke it with C-x C-e. For the latest crash, I entered C-x C-e some 40 times, and went to bed. After I awoke, Emacs had not crashed yet. So I entered a few more C-x C-e, and then it crashed immediately. But it was different than the previous one. So, actually, I think it will be very difficult to find proper watch points.
-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>,
 Robert Pluim <rpluim <at> gmail.com>
Cc: 39962 <at> debbugs.gnu.org, Pip Cet <pipcet <at> gmail.com>
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Wed, 18 Mar 2020 04:57:38 -0700

On 3/18/20 4:38 AM, Pieter van Oostrum wrote:
> I think it will be very difficult to find proper watch points.

That's too bad. If you could somehow trigger the bug in a batch session by 
calling the right functions, it'd be easier to debug. That's one of the first 
things I try to do when debugging this sort of thing.

On 3/17/20 11:17 PM, Pip Cet wrote:

>>> (gdb) watch *(void *)0x16082a730
>> 
>> I think you mean
>> 
>> watch *(void **)0x16082a730

Yes, thanks for spotting the typo.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, pieter-l <at> vanoostrum.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Wed, 18 Mar 2020 16:08:00 +0200

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Wed, 18 Mar 2020 06:17:01 +0000
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Pieter van Oostrum <pieter-l <at> vanoostrum.org>, 39962 <at> debbugs.gnu.org
> 
> > Although I haven't been following this in detail, I'd like to suggest trying a
> > GDB watchpoint to find the bug. Watchpoints have been invaluable to me when I
> > debug garbage-collector and other memory management issues.
> 
> They are! Unfortunately, they require a predictable address at which
> the corruption happens, and we don't appear to have that.

It would suffice to have a predictable recipe where some variable has
the right value under some conditions: then we could put a watchpoint
using that variable's value from a conditional breakpoint that only
triggers under those conditions.  Unfortunately, it sounds like even
such a predictable recipe is not available.

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

From: Pip Cet <pipcet <at> gmail.com>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: Robert Pluim <rpluim <at> gmail.com>, Paul Eggert <eggert <at> cs.ucla.edu>,
 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Wed, 18 Mar 2020 14:08:19 +0000

On Wed, Mar 18, 2020 at 11:38 AM Pieter van Oostrum
<pieter-l <at> vanoostrum.org> wrote:
> Robert Pluim <rpluim <at> gmail.com> writes:
> >>>>>> On Wed, 18 Mar 2020 06:17:01 +0000, Pip Cet <pipcet <at> gmail.com> said:
> >
> >     Pip> On Tue, Mar 17, 2020 at 8:59 PM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> >     >> Although I haven't been following this in detail, I'd like to suggest trying a
> >     >> GDB watchpoint to find the bug. Watchpoints have been invaluable to me when I
> >     >> debug garbage-collector and other memory management issues.
> >
> >     Pip> They are! Unfortunately, they require a predictable address at which
> >     Pip> the corruption happens, and we don't appear to have that.
> >
> > You have a known address if you use rr and run in reverse.

Indeed, which makes debugging on GNU/Linux a lot easier.
Unfortunately, I strongly suspect this problem is specific to macOS,
and I'm not aware of a reverse debugger for that OS.

> I have a procedure to generate a crash, but it isn't very predictable. I think that is because there are timers running and asynchronous processes. I get a different crash each time I run it.

I think it's because of user interaction and the events it generates...

> The crash generation involves opening two large mailboxes with VM (it could be that one would also work). I then manipulate them both, re-sorting them in a different order, saving, switching between the two, sorting back to my preferred order, saving and closing. I have saved this procedure in a keyboard macro, giving it a name. I copied the definition to another Emacs session. To recreate the crash, I copy the definition to the new Emacs session in the *scratch* buffer, and I can then invoke it with C-x C-e. For the latest crash, I entered C-x C-e some 40 times, and went to bed. After I awoke, Emacs had not crashed yet. So I entered a few more C-x C-e, and then it crashed immediately. But it was different than the previous one. So, actually, I think it will be very difficult to find proper watch points.

Is it possible this is somehow related to mouse/keyboard interaction?
That's my prime suspect, anyway; I still think that macOS runs code
asynchronously upon receiving external events in ways that aren't
kosher, particularly if they happen during GC.

If I'm right, it should be possible to trigger the bug by creating a
reasonably large session, running (garbage-collect) in an infinite
loop, and interacting with the mouse and keyboard while that is
happening. Or running your keyboard macro in a similar loop, of
course.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, pipcet <at> gmail.com
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Wed, 18 Mar 2020 17:05:01 +0200

> From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  39962 <at> debbugs.gnu.org,  eggert <at> cs.ucla.edu
> Date: Wed, 18 Mar 2020 00:32:42 +0100
> 
> >> >> 0x12590f3f0:    0x0000000000000006      0x0000000000000000
> >> >> 0x12590f400:    0x000000000d4269c0      0x0000000000000000
> >> >
> >> > I'm suspicious about this "symbol". Is 0xd4269c0 a valid lisp value?
> >>
> >> I'm sorry. I don't know how to find out. I'm just a newbee with debugging elisp in gdb.
> >
> > I believe "xprintsym 0xd4269c0" would work on macOS, too. I'm not sure
> > whether "pp 0xd4269c0" would.
> 
> (gdb) xprintsym 0xd4269c0
> Invalid number "0xd4269c0.i".
> (gdb) pp 0xd4269c0
> Invalid cast.

Try

  (gdb) p XIL(0xd4269c0)
  (gdb) xsymbol

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, pipcet <at> gmail.com
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Thu, 19 Mar 2020 14:23:46 +0100

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

>> From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  39962 <at> debbugs.gnu.org,  eggert <at> cs.ucla.edu
>> Date: Wed, 18 Mar 2020 00:32:42 +0100
>> 
>> >> >> 0x12590f3f0:    0x0000000000000006      0x0000000000000000
>> >> >> 0x12590f400:    0x000000000d4269c0      0x0000000000000000
>> >> >
>> >> > I'm suspicious about this "symbol". Is 0xd4269c0 a valid lisp value?
>> >>
>> >> I'm sorry. I don't know how to find out. I'm just a newbee with debugging elisp in gdb.
>> >
>> > I believe "xprintsym 0xd4269c0" would work on macOS, too. I'm not sure
>> > whether "pp 0xd4269c0" would.
>> 
>> (gdb) xprintsym 0xd4269c0
>> Invalid number "0xd4269c0.i".
>> (gdb) pp 0xd4269c0
>> Invalid cast.
>
> Try
>
>   (gdb) p XIL(0xd4269c0)
>   (gdb) xsymbol

After some trial and error finding the proper definition of XIL:

(gdb) p ((Lisp_Object) {(Lisp_Word) (0xd4269c0)})
$5 = XIL(0xd4269c0)
(gdb) xsymbol
$6 = (struct Lisp_Symbol *) 0x10de5f6d0
"<v>"


-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Pip Cet <pipcet <at> gmail.com>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, eggert <at> cs.ucla.edu, 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Thu, 19 Mar 2020 13:57:54 +0000

[Message part 1 (text/plain, inline)]

On Thu, Mar 19, 2020 at 1:23 PM Pieter van Oostrum
<pieter-l <at> vanoostrum.org> wrote:
> (gdb) p ((Lisp_Object) {(Lisp_Word) (0xd4269c0)})
> $5 = XIL(0xd4269c0)
> (gdb) xsymbol
> $6 = (struct Lisp_Symbol *) 0x10de5f6d0
> "<v>"

Okay, so that symbol is valid.

I think it's not a coincidence this crash happens during
keyboard/mouse input. I'm attaching a patch which increases the window
for the race condition that I think is happening. It slows down Emacs
significantly, but it should still be almost usable.

If you have the time, could you install the patch, start Emacs the
same way you did to produce your original crash, and do similar things
you did that time? If we're lucky, we'll be getting an assert failure
rather than mere corruption.

[0001-more-debugging.patch (text/x-patch, attachment)]

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: Robert Pluim <rpluim <at> gmail.com>, Paul Eggert <eggert <at> cs.ucla.edu>,
 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Thu, 19 Mar 2020 20:17:55 +0100

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

> On Wed, Mar 18, 2020 at 11:38 AM Pieter van Oostrum
>> I have a procedure to generate a crash, but it isn't very predictable.
>> I think that is because there are timers running and asynchronous
>> processes. I get a different crash each time I run it.
>
> I think it's because of user interaction and the events it generates...

[
...
]
> Is it possible this is somehow related to mouse/keyboard interaction?
> That's my prime suspect, anyway; I still think that macOS runs code
> asynchronously upon receiving external events in ways that aren't
> kosher, particularly if they happen during GC.

I think that is quite probable.

I had my keyboard macro translated to an Elisp function and then called this a 100 times with dotimes. However, there was no crash, even though I had the smaller stack size.

In total I had the macro run some 300+ times without any crash. I just had it run automatically (put it in a .el file, and used emacs -Q -l testfile.el), so no keyboard/mouse interaction.

> If I'm right, it should be possible to trigger the bug by creating a
> reasonably large session, running (garbage-collect) in an infinite
> loop, and interacting with the mouse and keyboard while that is
> happening. Or running your keyboard macro in a similar loop, of
> course.

But if I do it in a loop it will not react to the keyboard/mouse. Do you think the asynchronous processing of these events will be sufficient, even though no action is taken on these events?
-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Pip Cet <pipcet <at> gmail.com>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: Robert Pluim <rpluim <at> gmail.com>, Paul Eggert <eggert <at> cs.ucla.edu>,
 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Thu, 19 Mar 2020 19:31:44 +0000

On Thu, Mar 19, 2020 at 7:17 PM Pieter van Oostrum
<pieter-l <at> vanoostrum.org> wrote:
> I had my keyboard macro translated to an Elisp function and then called this a 100 times with dotimes. However, there was no crash, even though I had the smaller stack size.
>
> In total I had the macro run some 300+ times without any crash. I just had it run automatically (put it in a .el file, and used emacs -Q -l testfile.el), so no keyboard/mouse interaction.

Did you use emacs -Q to produce the original crash, or just emacs? I
ask because it's possible something in your mode line specification
caused or exacerbated the problem.

> > If I'm right, it should be possible to trigger the bug by creating a
> > reasonably large session, running (garbage-collect) in an infinite
> > loop, and interacting with the mouse and keyboard while that is
> > happening. Or running your keyboard macro in a similar loop, of
> > course.
>
> But if I do it in a loop it will not react to the keyboard/mouse. Do you think the asynchronous processing of these events will be sufficient, even though no action is taken on these events?

I think so, but I'm not sure. I've been looking at this code for a
while, and I think the likeliest culprit is the mouse-over
highlighting code, possibly for the mode line. On GNU/Linux, the
behavior is quite odd: for the first second or so after starting a
loop, the mode line elements react to mouseover events, but not
afterwards. On the other hand, a millisecond delay ought to be enough
to catch it during the first second.

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: Robert Pluim <rpluim <at> gmail.com>, Paul Eggert <eggert <at> cs.ucla.edu>,
 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Thu, 19 Mar 2020 22:30:03 +0100

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

> On Thu, Mar 19, 2020 at 7:17 PM Pieter van Oostrum
> <pieter-l <at> vanoostrum.org> wrote:
>> I had my keyboard macro translated to an Elisp function and then
>> called this a 100 times with dotimes. However, there was no crash,
>> even though I had the smaller stack size.
>>
>> In total I had the macro run some 300+ times without any crash. I just
>> had it run automatically (put it in a .el file, and used emacs -Q -l
>> testfile.el), so no keyboard/mouse interaction.
>
> Did you use emacs -Q to produce the original crash, or just emacs? I
> ask because it's possible something in your mode line specification
> caused or exacerbated the problem.

The original crash was without -Q, i.e. my normal production Emacs. I have quite an elaborate init.el file, so it could be almost anything.

With the test described above, I used -Q -l testfile.el
I also redid that test with most of my init.el copied into the test,el, and that still did not cause a crash.

>> > If I'm right, it should be possible to trigger the bug by creating a
>> > reasonably large session, running (garbage-collect) in an infinite
>> > loop, and interacting with the mouse and keyboard while that is
>> > happening. Or running your keyboard macro in a similar loop, of
>> > course.
>>
>> But if I do it in a loop it will not react to the keyboard/mouse. Do
>> you think the asynchronous processing of these events will be
>> sufficient, even though no action is taken on these events?
>
> I think so, but I'm not sure. I've been looking at this code for a
> while, and I think the likeliest culprit is the mouse-over
> highlighting code, possibly for the mode line. On GNU/Linux, the
> behavior is quite odd: for the first second or so after starting a
> loop, the mode line elements react to mouseover events, but not
> afterwards. On the other hand, a millisecond delay ought to be enough
> to catch it during the first second.
>
OK, with the next test I will try to trigger that. Right now I am compiling with the new 0001-more-debugging.patch.
-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, eggert <at> cs.ucla.edu, 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 21 Mar 2020 22:22:32 +0100

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

> On Thu, Mar 19, 2020 at 1:23 PM Pieter van Oostrum
> <pieter-l <at> vanoostrum.org> wrote:
>> (gdb) p ((Lisp_Object) {(Lisp_Word) (0xd4269c0)})
>> $5 = XIL(0xd4269c0)
>> (gdb) xsymbol
>> $6 = (struct Lisp_Symbol *) 0x10de5f6d0
>> "<v>"
>
> Okay, so that symbol is valid.
>
> I think it's not a coincidence this crash happens during
> keyboard/mouse input. I'm attaching a patch which increases the window
> for the race condition that I think is happening. It slows down Emacs
> significantly, but it should still be almost usable.
>
> If you have the time, could you install the patch, start Emacs the
> same way you did to produce your original crash, and do similar things
> you did that time? If we're lucky, we'll be getting an assert failure
> rather than mere corruption.
>
With that patch (the latest 0001-more-debugging.patch) Emacs gets extremely slow (about 10 times slower that normal). Also, while it is processing, it becomes completely unresponsive: the cursor becomes an spinning beach ball, it won't even resize the windows, or react to C-g.

I got the old Marker corruption back.


insdel.c:295: Emacs fatal error: assertion failed: m->bytepos >= m->charpos && m->bytepos - m->charpos <= Z_BYTE - Z

Thread 3 hit Breakpoint 1, terminate_due_to_signal (sig=6, 
--Type <RET> for more, q to quit, c to continue without paging--
    backtrace_limit=2147483647) at emacs.c:371
371	  signal (sig, SIG_DFL);
(gdb) bt
#0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:371
#1  0x00000001002a4a1b in die (
    msg=0x10050ff60 "m->bytepos >= m->charpos && m->bytepos - m->charpos <= Z_BYTE - Z", file=0x10050fde3 "insdel.c", line=295) at alloc.c:7264
#2  0x0000000100233a24 in adjust_markers_for_insert (from=529592, 
    from_byte=529598, to=529594, to_byte=529600, before_markers=false)
    at insdel.c:294
#3  0x0000000100234400 in insert_from_string_1 (string=XIL(0x11542c474), 
    pos=0, pos_byte=0, nchars=2, nbytes=2, inherit=false, before_markers=false)
    at insdel.c:1060
#4  0x0000000100233d48 in insert_from_string (string=XIL(0x11542c474), pos=0, 
    pos_byte=0, length=2, length_byte=2, inherit=false) at insdel.c:967
#5  0x00000001002ec552 in general_insert_function (
    insert_func=0x100231fe0 <insert>, 
    insert_from_string_func=0x100233cb0 <insert_from_string>, inherit=false, 
    nargs=1, args=0x7ffeefbed388) at editfns.c:1334
#6  0x00000001002ec26b in Finsert (nargs=1, args=0x7ffeefbed388)
    at editfns.c:1370
#7  0x00000001003a7dd3 in exec_byte_code (bytestr=XIL(0x10d1be5f4), 
    vector=XIL(0x10dba5245), maxdepth=make_fixnum(6), args_template=XIL(0), 
    nargs=0, args=0x0) at bytecode.c:1075
#8  0x00000001003174b6 in funcall_lambda (fun=XIL(0x10dcbd9c5), nargs=1, 
    arg_vector=0x7ffeefbee520) at eval.c:3067
#9  0x0000000100314c7e in Ffuncall (nargs=2, args=0x7ffeefbee518)
    at eval.c:2796
#10 0x00000001003a525f in exec_byte_code (bytestr=XIL(0x10d415114), 
    vector=XIL(0x10dc9b965), maxdepth=make_fixnum(3), args_template=XIL(0), 
    nargs=0, args=0x0) at bytecode.c:633
#11 0x00000001003174b6 in funcall_lambda (fun=XIL(0x10dc9b9b5), nargs=0, 
    arg_vector=0x7ffeefbef4f0) at eval.c:3067
#12 0x0000000100314c7e in Ffuncall (nargs=1, args=0x7ffeefbef4e8)
    at eval.c:2796
#13 0x00000001003a525f in exec_byte_code (bytestr=XIL(0x10b8d2fc4), 
    vector=XIL(0x104c8b925), maxdepth=make_fixnum(4), args_template=XIL(0), 
    nargs=0, args=0x0) at bytecode.c:633
#14 0x00000001003174b6 in funcall_lambda (fun=XIL(0x104c8b9c5), nargs=1, 
    arg_vector=0x7ffeefbf04f0) at eval.c:3067
#15 0x0000000100314c7e in Ffuncall (nargs=2, args=0x7ffeefbf04e8)
    at eval.c:2796
#16 0x0000000100315d34 in call1 (fn=XIL(0x104c8b9c5), arg1=XIL(0x1e229380))
    at eval.c:2654
#17 0x000000010037aaed in mapatoms_1 (sym=XIL(0x1e229380), 
    function=XIL(0x104c8b9c5)) at lread.c:4380
#18 0x000000010037a98e in map_obarray (obarray=XIL(0x10e267435), 
    fn=0x10037aad0 <mapatoms_1>, arg=XIL(0x104c8b9c5)) at lread.c:4369
#19 0x000000010037aab1 in Fmapatoms (function=XIL(0x104c8b9c5), 
    obarray=XIL(0x10e267435)) at lread.c:4391
--Type <RET> for more, q to quit, c to continue without paging--
#20 0x000000010031664c in funcall_subr (subr=0x10055b588, numargs=2, 
    args=0x7ffeefbf0840) at eval.c:2869
#21 0x0000000100314c2e in Ffuncall (nargs=3, args=0x7ffeefbf0838)
    at eval.c:2794
#22 0x00000001003a525f in exec_byte_code (bytestr=XIL(0x10b8d2f84), 
    vector=XIL(0x104c8b9f5), maxdepth=make_fixnum(6), args_template=XIL(0), 
    nargs=0, args=0x0) at bytecode.c:633
#23 0x00000001003174b6 in funcall_lambda (fun=XIL(0x104c8bae5), nargs=0, 
    arg_vector=0x7ffeefbf1860) at eval.c:3067
#24 0x0000000100314c7e in Ffuncall (nargs=1, args=0x7ffeefbf1858)
    at eval.c:2796
#25 0x00000001003a525f in exec_byte_code (bytestr=XIL(0x10b8c51d4), 
    vector=XIL(0x104ca2dd5), maxdepth=make_fixnum(6), args_template=XIL(0), 
    nargs=0, args=0x0) at bytecode.c:633
#26 0x00000001003174b6 in funcall_lambda (fun=XIL(0x104ca3075), nargs=1, 
    arg_vector=0x7ffeefbf29e0) at eval.c:3067
#27 0x0000000100314c7e in Ffuncall (nargs=2, args=0x7ffeefbf29d8)
    at eval.c:2796
#28 0x00000001003a525f in exec_byte_code (bytestr=XIL(0x10b8dbb14), 
    vector=XIL(0x1057428e5), maxdepth=make_fixnum(3), args_template=XIL(0), 
    nargs=0, args=0x0) at bytecode.c:633
#29 0x00000001003174b6 in funcall_lambda (fun=XIL(0x105742965), nargs=1, 
    arg_vector=0x7ffeefbf3d40) at eval.c:3067
#30 0x0000000100314c7e in Ffuncall (nargs=2, args=0x7ffeefbf3d38)
    at eval.c:2796
#31 0x0000000100311165 in Fapply (nargs=3, args=0x7ffeefbf3d38) at eval.c:2377
#32 0x0000000100316506 in funcall_subr (subr=0x100559368, numargs=3, 
    args=0x7ffeefbf3d38) at eval.c:2847
#33 0x0000000100314c2e in Ffuncall (nargs=4, args=0x7ffeefbf3d30)
    at eval.c:2794
#34 0x00000001003a525f in exec_byte_code (bytestr=XIL(0x10612797c), 
    vector=XIL(0x105742635), maxdepth=make_fixnum(5), 
    args_template=make_fixnum(128), nargs=0, args=0x7ffeefbf4ce0)
    at bytecode.c:633
#35 0x0000000100316d15 in funcall_lambda (fun=XIL(0x105742665), nargs=0, 
    arg_vector=0x7ffeefbf4ce0) at eval.c:2989
#36 0x0000000100314c7e in Ffuncall (nargs=1, args=0x7ffeefbf4cd8)
    at eval.c:2796
#37 0x00000001003a525f in exec_byte_code (bytestr=XIL(0x10b8d46d4), 
    vector=XIL(0x10570e495), maxdepth=make_fixnum(7), args_template=XIL(0), 
    nargs=0, args=0x0) at bytecode.c:633
#38 0x00000001003174b6 in funcall_lambda (fun=XIL(0x10570e665), nargs=0, 
    arg_vector=0x7ffeefbf5dd0) at eval.c:3067
#39 0x0000000100314c7e in Ffuncall (nargs=1, args=0x7ffeefbf5dc8)
    at eval.c:2796
#40 0x00000001003a525f in exec_byte_code (bytestr=XIL(0x10d106884), 
    vector=XIL(0x104c9d3d5), maxdepth=make_fixnum(7), args_template=XIL(0), 
--Type <RET> for more, q to quit, c to continue without paging--
    nargs=0, args=0x0) at bytecode.c:633
#41 0x00000001003174b6 in funcall_lambda (fun=XIL(0x104c9d665), nargs=0, 
    arg_vector=0x7ffeefbf6fc0) at eval.c:3067
#42 0x0000000100314c7e in Ffuncall (nargs=1, args=0x7ffeefbf6fb8)
    at eval.c:2796
#43 0x00000001003a525f in exec_byte_code (bytestr=XIL(0x10450fb84), 
    vector=XIL(0x104c9fc35), maxdepth=make_fixnum(2), args_template=XIL(0), 
    nargs=0, args=0x0) at bytecode.c:633
#44 0x00000001003174b6 in funcall_lambda (fun=XIL(0x104c9fc95), nargs=1, 
    arg_vector=0x7ffeefbf8310) at eval.c:3067
#45 0x0000000100314c7e in Ffuncall (nargs=2, args=0x7ffeefbf8308)
    at eval.c:2796
#46 0x0000000100311165 in Fapply (nargs=3, args=0x7ffeefbf8308) at eval.c:2377
#47 0x0000000100316506 in funcall_subr (subr=0x100559368, numargs=3, 
    args=0x7ffeefbf8308) at eval.c:2847
#48 0x0000000100314c2e in Ffuncall (nargs=4, args=0x7ffeefbf8300)
    at eval.c:2794
#49 0x00000001003a525f in exec_byte_code (bytestr=XIL(0x10612797c), 
    vector=XIL(0x104c9f995), maxdepth=make_fixnum(5), 
    args_template=make_fixnum(128), nargs=0, args=0x7ffeefbf92b0)
    at bytecode.c:633
#50 0x0000000100316d15 in funcall_lambda (fun=XIL(0x104c9f9c5), nargs=0, 
    arg_vector=0x7ffeefbf92b0) at eval.c:2989
#51 0x0000000100314c7e in Ffuncall (nargs=1, args=0x7ffeefbf92a8)
    at eval.c:2796
#52 0x00000001003a525f in exec_byte_code (bytestr=XIL(0x10d1018c4), 
    vector=XIL(0x1056f6405), maxdepth=make_fixnum(9), args_template=XIL(0), 
    nargs=0, args=0x0) at bytecode.c:633
#53 0x00000001003174b6 in funcall_lambda (fun=XIL(0x104ca02a5), nargs=1, 
    arg_vector=0x7ffeefbfa4c0) at eval.c:3067
#54 0x0000000100314c7e in Ffuncall (nargs=2, args=0x7ffeefbfa4b8)
    at eval.c:2796
#55 0x00000001003a525f in exec_byte_code (bytestr=XIL(0x10d107ee4), 
    vector=XIL(0x104cb0ac5), maxdepth=make_fixnum(2), args_template=XIL(0), 
    nargs=0, args=0x0) at bytecode.c:633
#56 0x00000001003174b6 in funcall_lambda (fun=XIL(0x104cb0b25), nargs=2, 
    arg_vector=0x7ffeefbfb810) at eval.c:3067
#57 0x0000000100314c7e in Ffuncall (nargs=3, args=0x7ffeefbfb808)
    at eval.c:2796
#58 0x00000001003111f8 in Fapply (nargs=3, args=0x7ffeefbfb808) at eval.c:2381
#59 0x0000000100316506 in funcall_subr (subr=0x100559368, numargs=3, 
    args=0x7ffeefbfb808) at eval.c:2847
#60 0x0000000100314c2e in Ffuncall (nargs=4, args=0x7ffeefbfb800)
    at eval.c:2794
#61 0x00000001003a525f in exec_byte_code (bytestr=XIL(0x10612797c), 
    vector=XIL(0x104cb08b5), maxdepth=make_fixnum(5), 
    args_template=make_fixnum(128), nargs=1, args=0x7ffeefbfca50)
--Type <RET> for more, q to quit, c to continue without paging--
    at bytecode.c:633
#62 0x0000000100316d15 in funcall_lambda (fun=XIL(0x104cb08e5), nargs=1, 
    arg_vector=0x7ffeefbfca50) at eval.c:2989
#63 0x0000000100314c7e in Ffuncall (nargs=2, args=0x7ffeefbfca48)
    at eval.c:2796
#64 0x00000001002fda4a in Ffuncall_interactively (nargs=2, args=0x7ffeefbfca48)
    at callint.c:254
#65 0x0000000100316506 in funcall_subr (subr=0x100558d98, numargs=2, 
    args=0x7ffeefbfca48) at eval.c:2847
#66 0x0000000100314c2e in Ffuncall (nargs=3, args=0x7ffeefbfca40)
    at eval.c:2794
#67 0x00000001003012f4 in Fcall_interactively (function=XIL(0x4c867c0), 
    record_flag=XIL(0), keys=XIL(0x15a8034f5)) at callint.c:783
#68 0x0000000100316682 in funcall_subr (subr=0x100558d68, numargs=3, 
    args=0x7ffeefbfd9c0) at eval.c:2872
#69 0x0000000100314c2e in Ffuncall (nargs=4, args=0x7ffeefbfd9b8)
    at eval.c:2794
#70 0x00000001003a525f in exec_byte_code (bytestr=XIL(0x10623df8c), 
    vector=XIL(0x10623dadd), maxdepth=make_fixnum(13), 
    args_template=make_fixnum(1025), nargs=1, args=0x7ffeefbfea28)
    at bytecode.c:633
#71 0x0000000100316d15 in funcall_lambda (fun=XIL(0x10623daad), nargs=1, 
    arg_vector=0x7ffeefbfea20) at eval.c:2989
#72 0x0000000100314c7e in Ffuncall (nargs=2, args=0x7ffeefbfea18)
    at eval.c:2796
#73 0x0000000100315d34 in call1 (fn=XIL(0x3960), arg1=XIL(0x4c867c0))
    at eval.c:2654
#74 0x00000001001c74f0 in command_loop_1 () at keyboard.c:1463
#75 0x000000010030d63f in internal_condition_case (
    bfun=0x1001c6790 <command_loop_1>, handlers=XIL(0x90), 
    hfun=0x1001e9e50 <cmd_error>) at eval.c:1355
#76 0x00000001001e9d31 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1091
#77 0x000000010030c778 in internal_catch (tag=XIL(0xc450), 
    func=0x1001e9d00 <command_loop_2>, arg=XIL(0)) at eval.c:1116
#78 0x00000001001c5805 in command_loop () at keyboard.c:1070
#79 0x00000001001c55d7 in recursive_edit_1 () at keyboard.c:714
#80 0x00000001001c5a86 in Frecursive_edit () at keyboard.c:786
#81 0x00000001001c25ee in main (argc=1, argv=0x7ffeefbff660) at emacs.c:2054
[New Thread 0x240f of process 5346]

Lisp Backtrace:
"vm-set-summary-pointer" (0xefbee520)
"vm-do-needed-summary-rebuild" (0xefbef4f0)
0x4c8b9c0 PVEC_COMPILED
"mapatoms" (0xefbf0840)
"vm-update-summary-and-mode-line" (0xefbf1860)
0x4ca3070 PVEC_COMPILED
--Type <RET> for more, q to quit, c to continue without paging--
"ad-Advice-vm-decode-mime-message" (0xefbf3d40)
"apply" (0xefbf3d38)
"vm-decode-mime-message" (0xefbf4ce0)
"vm-show-current-message" (0xefbf5dd0)
0x4c9d660 PVEC_COMPILED
"ad-Advice-vm-present-current-message" (0xefbf8310)
"apply" (0xefbf8308)
"vm-present-current-message" (0xefbf92b0)
0x4ca02a0 PVEC_COMPILED
"ad-Advice-vm-scroll-forward" (0xefbfb810)
"apply" (0xefbfb808)
"vm-scroll-forward" (0xefbfca50)
"funcall-interactively" (0xefbfca48)
"call-interactively" (0xefbfd9c0)
"command-execute" (0xefbfea20)
(gdb) 


-- 
Pieter van Oostrum
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, pipcet <at> gmail.com
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sun, 22 Mar 2020 16:21:00 +0200

> From: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  39962 <at> debbugs.gnu.org,  eggert <at> cs.ucla.edu
> Date: Sat, 21 Mar 2020 22:22:32 +0100
> 
> I got the old Marker corruption back.
> 
> 
> insdel.c:295: Emacs fatal error: assertion failed: m->bytepos >= m->charpos && m->bytepos - m->charpos <= Z_BYTE - Z
> 
> Thread 3 hit Breakpoint 1, terminate_due_to_signal (sig=6, 
> --Type <RET> for more, q to quit, c to continue without paging--
>     backtrace_limit=2147483647) at emacs.c:371
> 371	  signal (sig, SIG_DFL);
> (gdb) bt
> #0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:371
> #1  0x00000001002a4a1b in die (
>     msg=0x10050ff60 "m->bytepos >= m->charpos && m->bytepos - m->charpos <= Z_BYTE - Z", file=0x10050fde3 "insdel.c", line=295) at alloc.c:7264
> #2  0x0000000100233a24 in adjust_markers_for_insert (from=529592, 
>     from_byte=529598, to=529594, to_byte=529600, before_markers=false)
>     at insdel.c:294

Can you show the offending data that failed the assertion?

Also, would it be possible for you to look into the related data, as I
suggested several messages ago, and show what you find?  It might give
us some ideas for further debugging.

Thanks.

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

From: Pip Cet <pipcet <at> gmail.com>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, eggert <at> cs.ucla.edu, 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sun, 22 Mar 2020 15:48:42 +0000

[Message part 1 (text/plain, inline)]

On Sat, Mar 21, 2020 at 9:22 PM Pieter van Oostrum
<pieter-l <at> vanoostrum.org> wrote:
> Pip Cet <pipcet <at> gmail.com> writes:
> > On Thu, Mar 19, 2020 at 1:23 PM Pieter van Oostrum
> > <pieter-l <at> vanoostrum.org> wrote:
> > If you have the time, could you install the patch, start Emacs the
> > same way you did to produce your original crash, and do similar things
> > you did that time? If we're lucky, we'll be getting an assert failure
> > rather than mere corruption.
> >
> With that patch (the latest 0001-more-debugging.patch) Emacs gets extremely slow (about 10 times slower that normal). Also, while it is processing, it becomes completely unresponsive: the cursor becomes an spinning beach ball, it won't even resize the windows, or react to C-g.

That's okay, that's the extra delays to increase the race condition.
I've reduced them by an order of magnitude in this patch.

I've also added more checks for what's one potential erroneous code
path: corruption of the red-black tree we use in conservative stack
marking.

[0001-even-more-debugging.patch (text/x-patch, attachment)]

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

From: Pip Cet <pipcet <at> gmail.com>
To: Pieter van Oostrum <pieter-l <at> vanoostrum.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, eggert <at> cs.ucla.edu, 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Mon, 23 Mar 2020 19:34:50 +0000

[Message part 1 (text/plain, inline)]

On Sun, Mar 22, 2020 at 3:48 PM Pip Cet <pipcet <at> gmail.com> wrote:
> I've also added more checks for what's one potential erroneous code
> path: corruption of the red-black tree we use in conservative stack
> marking.

In fact I'd added too many checks, which didn't show up in my testing
because I had built things with the wrong configure options. Better
patch attached.

[0001-even-more-debugging.patch (text/x-patch, attachment)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Pieter van Oostrum <pieter <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sat, 30 Apr 2022 14:38:18 +0200

Pieter van Oostrum <pieter <at> vanoostrum.org> writes:

> I got a segmentation fault in Emacs. I read my email with VM
> (Viewmail), and I had a few fairly large mailboxes open when Emacs
> crashed. I had a few other cases where it crashed under similar
> circumstances, but other cases where it ran without problems.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Skimming this thread, it looked like the bug might have been due to
too-deep recursion in GC.  This was fixed recently in Emacs 29 -- the GC
no longer recurses (as much).

Do you still see this crash in recent Emacs versions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Pieter van Oostrum <pieter <at> vanoostrum.org>
Cc: 39962 <at> debbugs.gnu.org
Subject: Re: bug#39962: 27.0.90; Crash in Emacs 27.0.90
Date: Sun, 29 May 2022 15:19:11 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Skimming this thread, it looked like the bug might have been due to
> too-deep recursion in GC.  This was fixed recently in Emacs 29 -- the GC
> no longer recurses (as much).
>
> Do you still see this crash in recent Emacs versions?

More information was requested, but no response was given within a
month, so I'm closing this bug report.  If the problem still exists,
please respond to this email and we'll reopen the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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