GNU bug report logs - #26932
25.1; Crash triggered a few times a day with network process

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 26932 in the body.
You can then email your comments to 26932 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: Vivek Dasmohapatra <vivek <at> etla.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.1; Crash triggered a few times a day with network process
Date: Sun, 14 May 2017 21:54:56 +0100 (BST)

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

I have a rudimentary mud client in elisp I cobbled together and use
(since emacs23 or so): It's been stable since then. However since
upgrading to emacs25 I've seen 4 crashes of emacs itself - 3 yesterday
and 1 today.

At first I thought perhaps it was keyboard/input related as it seemed
to happen while I was typing, but today while running the client
to see if I could track down the problem emacs segfaulted while
I wasn't typing or using the mouse. I managed to get a backtrace
out of gdb, which I have attached. I can semi-reliably reproduce
the crash.

I haven't been able to run xbacktrace as it hasn't yet crashed while
gdb was attached.

Looking at the backtrace and examining the source, it looks like
it blows up in the maybe_gc inside funcall _just before_ the first
hook in window-scroll-functions is called.

In GNU Emacs 25.1.1 (x86_64-pc-linux-gnu, GTK+ Version 3.14.5)
 of 2017-04-27, modified by Debian built on noise
Windowing system distributor 'The X.Org Foundation', version 11.0.11604000
System Description:     Debian GNU/Linux 8.8 (jessie)

Configured using:
 'configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes

--enable-locallisppath=/etc/emacs25:/etc/emacs:/usr/local/share/emacs/25.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/25.1/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes

--enable-locallisppath=/etc/emacs25:/etc/emacs:/usr/local/share/emacs/25.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/25.1/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --with-x=yes --with-x-toolkit=gtk3
 --with-toolkit-scroll-bars 'CFLAGS=-g -O2 -fstack-protector-strong
 -Wformat -Werror=format-security -Wall' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-z,relro'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11

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

Major mode: Dired by name

Minor modes in effect:
  which-function-mode: t
  diff-auto-refine-mode: t
  magit-auto-revert-mode: t
  global-git-commit-mode: t
  async-bytecomp-package-mode: t
  shell-dirtrack-mode: t
  auto-image-file-mode: t
  iswitchb-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-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
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t

Recent messages:
<elided - this is not the copy that crashed>

Load-path shadows:
/usr/share/emacs/25.1/site-lisp/debian-startup hides /usr/share/emacs/site-lisp/debian-startup
/usr/share/emacs25/site-lisp/cmake-data/cmake-mode hides /usr/share/emacs/site-lisp/cmake-mode
/home/vivek/.emacs.d/lib/htmlfontify hides /usr/share/emacs/25.1/lisp/htmlfontify
/usr/share/emacs25/site-lisp/dictionaries-common/flyspell hides /usr/share/emacs/25.1/lisp/textmodes/flyspell
/usr/share/emacs/site-lisp/rst hides /usr/share/emacs/25.1/lisp/textmodes/rst
/usr/share/emacs25/site-lisp/dictionaries-common/ispell hides /usr/share/emacs/25.1/lisp/textmodes/ispell
/home/vivek/.emacs.d/lib/browse-url hides /usr/share/emacs/25.1/lisp/net/browse-url

Features:
(shadow sort mail-extr emacsbug sendmail make-mode pulse eieio-opt
speedbar sb-image ezimage dframe find-func etags xref project dired-aux
autoconf autoconf-mode git-rebase misearch multi-isearch esh-var esh-io
esh-cmd esh-opt esh-ext esh-proc esh-arg esh-groups eshell esh-module
esh-mode esh-util which-func imenu cc-mode cc-fonts cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs dabbrev vc-git
sh-script smie executable magit-obsolete magit-blame magit-stash
magit-bisect magit-remote magit-commit magit-sequence magit-notes
magit-worktree magit-branch magit-files magit-refs magit-status magit
magit-repos magit-apply magit-wip magit-log magit-diff smerge-mode
diff-mode magit-core magit-autorevert autorevert filenotify
magit-process magit-margin magit-mode magit-git crm magit-section
magit-popup git-commit magit-utils log-edit message rfc822 mml mml-sec
epg mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mailabbrev gmm-utils mailheader pcvs-util add-log with-editor
async-bytecomp async tramp-sh tramp tramp-compat tramp-loaddefs trampver
ucs-normalize shell pcomplete comint format-spec server dash dired gnus
gnus-ems nnheader mail-utils wid-edit image-file cus-start cus-load
ls-lisp iswitchb edmacro kmacro thingatpt browse-url cl jka-compr wiki
warnings advice url-auth url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf url-util url-parse
auth-source cl-seq eieio eieio-core cl-macs gnus-util mm-util help-fns
mail-prsvr password-cache url-vars mailcap ediff-merg ediff-wind
ediff-diff ediff-mult ediff-help ediff-init ediff-util ediff diff wiki-+
ansi-color lui tracking flyspell ispell ring incomplete finder-inf
tex-site info package epg-config seq byte-opt gv bytecomp byte-compile
cl-extra help-mode easymenu cconv cl-loaddefs pcase cl-lib debian-el
debian-el-loaddefs emacs-goodies-el emacs-goodies-custom
emacs-goodies-loaddefs easy-mmode dpkg-dev-el dpkg-dev-el-loaddefs
devhelp time-date mule-util tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel x-win term/common-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame
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 charscript
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer
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 dbusbind inotify
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 476270 67640)
 (symbols 48 37722 0)
 (miscs 40 599 1669)
 (strings 32 74597 9971)
 (string-bytes 1 19723175)
 (vectors 16 60643)
 (vector-slots 8 1688085 153273)
 (floats 8 386 972)
 (intervals 56 28462 2534)
 (buffers 976 114)
 (heap 1024 80470 3527))

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vivek Dasmohapatra <vivek <at> etla.org>
Cc: 26932 <at> debbugs.gnu.org
Subject: Re: bug#26932: 25.1;
 Crash triggered a few times a day with network process
Date: Mon, 15 May 2017 06:04:14 +0300

> Date: Sun, 14 May 2017 21:54:56 +0100 (BST)
> From: Vivek Dasmohapatra <vivek <at> etla.org>
> 
> I have a rudimentary mud client in elisp I cobbled together and use
> (since emacs23 or so): It's been stable since then. However since
> upgrading to emacs25 I've seen 4 crashes of emacs itself - 3 yesterday
> and 1 today.
> 
> At first I thought perhaps it was keyboard/input related as it seemed
> to happen while I was typing, but today while running the client
> to see if I could track down the problem emacs segfaulted while
> I wasn't typing or using the mouse. I managed to get a backtrace
> out of gdb, which I have attached. I can semi-reliably reproduce
> the crash.
> 
> I haven't been able to run xbacktrace as it hasn't yet crashed while
> gdb was attached.
> 
> Looking at the backtrace and examining the source, it looks like
> it blows up in the maybe_gc inside funcall _just before_ the first
> hook in window-scroll-functions is called.

It segfaults in GC.

Is it possible for you to try the latest Emacs 25.2?

Thanks.

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

From: Vivek Dasmohapatra <vivek <at> etla.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 26932 <at> debbugs.gnu.org
Subject: Re: bug#26932: 25.1; Crash triggered a few times a day with network
 process
Date: Mon, 15 May 2017 12:18:12 +0100 (BST)

> Is it possible for you to try the latest Emacs 25.2?

Sure, I can do that at some point this week.

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

From: Vivek Dasmohapatra <vivek <at> etla.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 26932 <at> debbugs.gnu.org
Subject: Re: bug#26932: 25.1; Crash triggered a few times a day with network
 process
Date: Sun, 11 Jun 2017 22:39:49 +0100 (BST)

On Mon, 15 May 2017, Vivek Dasmohapatra wrote:

>> Is it possible for you to try the latest Emacs 25.2?
>
> Sure, I can do that at some point this week.

That took a little longer for me to get around to, but I just triggered
the crash again with emacs 25.2.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vivek Dasmohapatra <vivek <at> etla.org>
Cc: 26932 <at> debbugs.gnu.org
Subject: Re: bug#26932: 25.1; Crash triggered a few times a day with network
 process
Date: Mon, 12 Jun 2017 17:10:47 +0300

> Date: Sun, 11 Jun 2017 22:39:49 +0100 (BST)
> From: Vivek Dasmohapatra <vivek <at> etla.org>
> cc: 26932 <at> debbugs.gnu.org
> 
> On Mon, 15 May 2017, Vivek Dasmohapatra wrote:
> 
> >> Is it possible for you to try the latest Emacs 25.2?
> >
> > Sure, I can do that at some point this week.
> 
> That took a little longer for me to get around to, but I just triggered
> the crash again with emacs 25.2.

Do you have a backtrace to show for this crash?  It would help.

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

From: Vivek Dasmohapatra <vivek <at> etla.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 26932 <at> debbugs.gnu.org
Subject: Re: bug#26932: 25.1; Crash triggered a few times a day with network
 process
Date: Mon, 12 Jun 2017 16:21:38 +0100 (BST)

> Do you have a backtrace to show for this crash?  It would help.

I have it running now with core dumps turned on: As soon as it happens
again I should have a backtrace for you.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vivek Dasmohapatra <vivek <at> etla.org>
Cc: 26932 <at> debbugs.gnu.org
Subject: Re: bug#26932: 25.1; Crash triggered a few times a day with network
 process
Date: Mon, 12 Jun 2017 18:51:12 +0300

> Date: Mon, 12 Jun 2017 16:21:38 +0100 (BST)
> From: Vivek Dasmohapatra <vivek <at> etla.org>
> cc: 26932 <at> debbugs.gnu.org
> 
> > Do you have a backtrace to show for this crash?  It would help.
> 
> I have it running now with core dumps turned on: As soon as it happens
> again I should have a backtrace for you.

Thanks.  Core dump is better than nothing, but it is even better to
run Emacs under GDB to begin with, because there are some things a
debugger cannot do when all it has is a core dump.

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

From: Vivek Dasmohapatra <vivek <at> etla.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 26932 <at> debbugs.gnu.org
Subject: Re: bug#26932: 25.1; Crash triggered a few times a day with network
 process
Date: Mon, 12 Jun 2017 16:56:32 +0100 (BST)

Running under gdb now.
Anything in particular you want done when it triggers again?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vivek Dasmohapatra <vivek <at> etla.org>
Cc: 26932 <at> debbugs.gnu.org
Subject: Re: bug#26932: 25.1; Crash triggered a few times a day with network
 process
Date: Mon, 12 Jun 2017 19:30:29 +0300

> Date: Mon, 12 Jun 2017 16:56:32 +0100 (BST)
> From: Vivek Dasmohapatra <vivek <at> etla.org>
> cc: 26932 <at> debbugs.gnu.org
> 
> Running under gdb now.
> Anything in particular you want done when it triggers again?

Just backtrace is fine.  But please try not to end the GDB session
immediately, because I might want to ask you to do something before
exiting GDB.

Thanks.

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

From: Vivek Dasmohapatra <vivek <at> etla.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 26932 <at> debbugs.gnu.org
Subject: Re: bug#26932: 25.1; Crash triggered a few times a day with network
 process
Date: Tue, 13 Jun 2017 16:41:37 +0100 (BST)

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

Triggered the segfault: Looks different to the emacs 25.1 fault
but still GC related, I think.

gdb session remains up and running.

[emacs25-backtrace.log (text/plain, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vivek Dasmohapatra <vivek <at> etla.org>
Cc: 26932 <at> debbugs.gnu.org
Subject: Re: bug#26932: 25.1; Crash triggered a few times a day with network
 process
Date: Tue, 13 Jun 2017 19:41:27 +0300

> Date: Tue, 13 Jun 2017 16:41:37 +0100 (BST)
> From: Vivek Dasmohapatra <vivek <at> etla.org>
> cc: 26932 <at> debbugs.gnu.org
> 
> Triggered the segfault: Looks different to the emacs 25.1 fault
> but still GC related, I think.
> 
> gdb session remains up and running.

What kind of :eval form(s) do you have in your mode-line-format
definitions?

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

From: Vivek Dasmohapatra <vivek <at> etla.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 26932 <at> debbugs.gnu.org
Subject: Re: bug#26932: 25.1; Crash triggered a few times a day with network
 process
Date: Tue, 13 Jun 2017 18:04:43 +0100 (BST)

> What kind of :eval form(s) do you have in your mode-line-format
> definitions?

At the top level of m-l-f

 ;; 2nd element:
 (:eval
   (if
       (display-graphic-p)
       #(" " 0 1
         (help-echo "mouse-1: Select (drag to resize)\nmouse-2: Make current
                     window occupy the whole frame\nmouse-3: Remove current
                     window from display"))
     #("-" 0 1
       (help-echo "mouse-1: Select (drag to resize)\nmouse-2: Make current
                   window occupy the whole frame\nmouse-3: Remove current
                   window from display"))))

Immediately followd by:

 ;; mode-line-mule-info
 ;; which ends with:
  (:eval
    (mode-line-eol-desc))

 ;; mode-line-client
 ("" (:propertize
       ("" (:eval
            (if (frame-parameter nil 'client) "@" "")))

 ;; mode-line-modified - N/a
 ;; mode-line-remote - N/a

 ;; mode-line-frame-identification
 (:eval (mode-line-frame-control))

 ;; mode-line-buffer-identification - N/a

 ;; Final element:
(:eval
  (unless
      (display-graphic-p)
    #("-%-" 0 3
      (help-echo "mouse-1: Select (drag to resize)\nmouse-2: Make current
                  window occupy the whole frame\nmouse-3: Remove current
                  window from display"))))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vivek Dasmohapatra <vivek <at> etla.org>
Cc: 26932 <at> debbugs.gnu.org
Subject: Re: bug#26932: 25.1; Crash triggered a few times a day with network
 process
Date: Tue, 13 Jun 2017 22:46:11 +0300

> Date: Tue, 13 Jun 2017 18:04:43 +0100 (BST)
> From: Vivek Dasmohapatra <vivek <at> etla.org>
> cc: 26932 <at> debbugs.gnu.org
> 
> > What kind of :eval form(s) do you have in your mode-line-format
> > definitions?
> 
> At the top level of m-l-f

Thanks, that seems okay.

Hmm... all those "optimized out" variables really make it hard
figuring out which Lisp data structure causes the trouble.  Do you
know how to examine marked objects stored in the last_marked[] array?
There are some instructions about that in etc/DEBUG.

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

From: Vivek Dasmohapatra <vivek <at> etla.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 26932 <at> debbugs.gnu.org
Subject: Re: bug#26932: 25.1; Crash triggered a few times a day with network
 process
Date: Tue, 13 Jun 2017 22:23:33 +0100 (BST)

> Hmm... all those "optimized out" variables really make it hard
> figuring out which Lisp data structure causes the trouble.  Do you

Yeah, I've come to loathe that "optimized out" message on other
projects too.

> know how to examine marked objects stored in the last_marked[] array?
> There are some instructions about that in etc/DEBUG.

I'll have a look.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vivek Dasmohapatra <vivek <at> etla.org>
Cc: 26932 <at> debbugs.gnu.org
Subject: Re: bug#26932: 25.1; Crash triggered a few times a day with network
 process
Date: Wed, 14 Jun 2017 05:32:51 +0300

> Date: Tue, 13 Jun 2017 22:23:33 +0100 (BST)
> From: Vivek Dasmohapatra <vivek <at> etla.org>
> cc: 26932 <at> debbugs.gnu.org
> 
> > Hmm... all those "optimized out" variables really make it hard
> > figuring out which Lisp data structure causes the trouble.  Do you
> 
> Yeah, I've come to loathe that "optimized out" message on other
> projects too.

One thing to try is to rebuild Emacs without optimizations (-O0
compiler option).

> > know how to examine marked objects stored in the last_marked[] array?
> > There are some instructions about that in etc/DEBUG.
> 
> I'll have a look.

Thank you.  Let me know if you need help in that.

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

From: Vivek Dasmohapatra <vivek <at> etla.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 26932 <at> debbugs.gnu.org
Subject: Re: bug#26932: 25.1; Crash triggered a few times a day with network
 process
Date: Thu, 15 Jun 2017 14:48:40 +0100 (BST)

On Wed, 14 Jun 2017, Eli Zaretskii wrote:

> One thing to try is to rebuild Emacs without optimizations (-O0
> compiler option).

I'll kick off a build, but from experience that seems to help a lot
less these days - AIUI anything left in a register over a function
call still counts as optimised away, and you have to crack out
the disassembly instructions in gdb to see it. I'm guessing amd64
having a lot more registers makes this more obvious than in the
old i386 register-starved days.

> Thank you.  Let me know if you need help in that.

Looks reasonable enough. Is there anything in particular you're
interested in, other than which object triggered the SEGV?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vivek Dasmohapatra <vivek <at> etla.org>
Cc: 26932 <at> debbugs.gnu.org
Subject: Re: bug#26932: 25.1; Crash triggered a few times a day with network
 process
Date: Thu, 15 Jun 2017 17:47:29 +0300

> Date: Thu, 15 Jun 2017 14:48:40 +0100 (BST)
> From: Vivek Dasmohapatra <vivek <at> etla.org>
> cc: 26932 <at> debbugs.gnu.org
> 
> On Wed, 14 Jun 2017, Eli Zaretskii wrote:
> 
> > One thing to try is to rebuild Emacs without optimizations (-O0
> > compiler option).
> 
> I'll kick off a build, but from experience that seems to help a lot
> less these days

IME, it actually helps a lot, even on 64-bit machines.

> Is there anything in particular you're interested in, other than
> which object triggered the SEGV?

The faulty object would be a very important clue.  Once we find that
out, we should look at how that object is created and modified.

Thanks.

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

From: Vivek Dasmohapatra <vivek <at> etla.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 26932 <at> debbugs.gnu.org
Subject: Re: bug#26932: 25.1; Crash triggered a few times a day with network
 process
Date: Mon, 19 Jun 2017 01:57:54 +0100 (BST)

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

> The faulty object would be a very important clue.  Once we find that
> out, we should look at how that object is created and modified.

Not sure I'm doing this right, but here's what I have so far:

SEGV @
#0 mark_object; alloc.c:6450
last_mark_index=12, therefore last_mark[11] must be what we are looking at.

(gdb) p XTYPE(last_marked[11])
$41 = Lisp_Symbol
(gdb) p XSYMBOL(last_marked[11])
$44 = (struct Lisp_Symbol *) 0x3c382c0
(gdb) p *XSYMBOL(last_marked[11])
Cannot access memory at address 0x3c382c0

which matches alloc.c:6540 which is inside a `case Lisp_Symbol:' section

line that fails is:

if (ptr->gcmarkbit)

so we have a duff symbol?
============================================================================
#1 mark_object; alloc.c:6543

inside a case Lisp_Cons:

mark_object (ptr->car);

assuming this is the previous marked object:

(gdb) p XTYPE(last_marked[10])
$45 = Lisp_Cons
(gdb) p XCONS(last_marked[10])
$46 = (struct Lisp_Cons *) 0x2eaf810
(gdb) p *XCONS(last_marked[10])
$47 = {car = 50828624, u = {cdr = 48953347, chain = 0x2eaf803}}

(gdb) p XTYPE(50828624)
$49 = Lisp_Symbol
(gdb) p *XSYMBOL(50828624)
Cannot access memory at address 0x3c382c0 // curses, foiled again

============================================================================
#2 mark_maybe_object; alloc.c:4743

Not interesting: checks for alive-ness and calls mark_object
============================================================================
#3  mark_memory (end=0x7fffffffe218, start=<optimized out>); alloc.c:4895

for (pp = start; (void *) pp < end; pp += GC_POINTER_ALIGNMENT)
    {
      mark_maybe_pointer (*(void **) pp);
      mark_maybe_object (*(Lisp_Object *) pp); // ← this is the entry point
    }

(gdb) p XTYPE(*(Lisp_Object *)pp)
$63 = Lisp_Cons
(gdb) p *XCONS(*(Lisp_Object *)pp)
$65 = {car = 48892595, u = {cdr = 49727219, chain = 0x2f6c6f3}}

This doesn't seem to match what we encounter two frames down in mark_object:
Maybe I've misinterpreted something? Anyway:

following the earlier call to mark_maybe_pointer:

(gdb) call mem_find(*((void **) pp))
$86 = (struct mem_node *) 0x2cce8a0
(gdb) p *(struct mem_node *) 0x2cce8a0
$87 = {left = 0x2cce8e0, right = 0x2e816e0, parent = 0x2d5cb00,
  start = 0x2f6c400, end = 0x2f6c7f0, color = MEM_BLACK, type = MEM_TYPE_CONS}

and later on:

	case MEM_TYPE_CONS:
      if (live_cons_p (m, p) && !CONS_MARKED_P ((struct Lisp_Cons *) p))
          XSETCONS (obj, p);
      break;

so we've copied the cons cell into obj (I think).

And then finally:

    if (!NILP (obj))
        mark_object (obj);

so maybe last_marked[9] is involved?

idx 9 seems to be a list with every car being:

(gdb) p last_marked[9]
$120 = 48953379
(gdb) p XTYPE(last_marked[9])
$121 = Lisp_Cons
(gdb) p *XCONS(last_marked[9])
$122 = {car = 8760836, u = {cdr = 48953363, chain = 0x2eaf813}}
(gdb) p XTYPE(8760836)
$123 = Lisp_String
(gdb) p *XSTRING(8760836)
$124 = {size = 4, size_byte = -1, intervals = 0x0,
  data = 0xb374bb <pure+2999995> "DEAD"}

So... a reaped list? Not helpful anyway. Nothing identifiable here.

============================================================================
#4 mark_stack

Nothing of note here
============================================================================

Going up the backtrace all I find is that we're in the modeline display
code and we're _about_ to eval the mode-line-frame-identification
value:

(:eval (mode-line-frame-control))

But GC happens before we actually call it.

Not sure where to go from here: Any advice?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vivek Dasmohapatra <vivek <at> etla.org>
Cc: 26932 <at> debbugs.gnu.org
Subject: Re: bug#26932: 25.1; Crash triggered a few times a day with network
 process
Date: Mon, 19 Jun 2017 17:59:10 +0300

> Date: Mon, 19 Jun 2017 01:57:54 +0100 (BST)
> From: Vivek Dasmohapatra <vivek <at> etla.org>
> cc: 26932 <at> debbugs.gnu.org
> 
> so maybe last_marked[9] is involved?
> 
> idx 9 seems to be a list with every car being:
> 
> (gdb) p last_marked[9]
> $120 = 48953379
> (gdb) p XTYPE(last_marked[9])
> $121 = Lisp_Cons
> (gdb) p *XCONS(last_marked[9])
> $122 = {car = 8760836, u = {cdr = 48953363, chain = 0x2eaf813}}
> (gdb) p XTYPE(8760836)
> $123 = Lisp_String
> (gdb) p *XSTRING(8760836)
> $124 = {size = 4, size_byte = -1, intervals = 0x0,
>    data = 0xb374bb <pure+2999995> "DEAD"}
> 
> So... a reaped list? Not helpful anyway. Nothing identifiable here.

I think you should go back along last_marked[] and look for some valid
identifiable object.

> Going up the backtrace all I find is that we're in the modeline display
> code and we're _about_ to eval the mode-line-frame-identification
> value:
> 
> (:eval (mode-line-frame-control))
> 
> But GC happens before we actually call it.

Indeed.  The exact evaluation is not really relevant because the
problem is with an object Emacs is trying to mark, which is most
probably unrelated to what's involved in the :eval form.

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

From: Vivek Dasmohapatra <vivek <at> etla.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 26932 <at> debbugs.gnu.org
Subject: Re: bug#26932: 25.1; Crash triggered a few times a day with network
 process
Date: Mon, 19 Jun 2017 19:03:40 +0100 (BST)

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

idx 7 is a cons, the car is integer 273081 (probably a buffer size
or char position), the cdr is a cons whose car is another instance of
DEAD

(gdb) p last_marked[7]
$285 = 48953395
(gdb) p XTYPE(last_marked[7])
$286 = Lisp_Cons
(gdb) p *XTYPE(last_marked[7])
Attempt to take contents of a non-pointer value.
(gdb) p *XCONS(last_marked[7])
$287 = {car = 1092326, u = {cdr = 48953379, chain = 0x2eaf823}}
(gdb) p XTYPE(1092326)
$288 = Lisp_Int1
(gdb) p XTYPE(48953379)
$289 = Lisp_Cons
(gdb) p XINT(1092326)
$290 = 273081
(gdb) p *XCONS(48953379)
$291 = {car = 8760836, u = {cdr = 48953363, chain = 0x2eaf813}}
(gdb) p XTYPE(8760836)
$292 = Lisp_String
(gdb) p *XSTRING(8760836)
$293 = {size = 4, size_byte = -1, intervals = 0x0,
  data = 0xb374bb <pure+2999995> "DEAD"}

idx 6 seems to be a marker (I guess?) inside a cons:

(gdb) p *XCONS(last_marked[6])
$226 = {car = 21742881, u = {cdr = -30, chain = 0xffffffffffffffe2}}
(gdb) p XTYPE(21742881)
$227 = Lisp_Misc
(gdb) p XTYPE(-30)
$228 = Lisp_Int0
(gdb) p XINT(-30)
$229 = -8
(gdb) p XTYPE(21742881)
$230 = Lisp_Misc
(gdb) p *XMISC(21742881)
$231 = {u_any = {type = Lisp_Misc_Marker, gcmarkbit = true, spacer = 1128},
  u_free = {type = Lisp_Misc_Marker, gcmarkbit = true, spacer = 1128,
    chain = 0x1e1d370}, u_marker = {type = Lisp_Misc_Marker, gcmarkbit = true,
    spacer = 1128, need_adjustment = false, insertion_type = false,
    buffer = 0x1e1d370, next = 0x14bc548, charpos = 275053, bytepos = 275063},
  u_overlay = {type = Lisp_Misc_Marker, gcmarkbit = true, spacer = 1128,
    next = 0x1e1d370, start = 21742920, end = 275053, plist = 275063},
  u_save_value = {type = Lisp_Misc_Marker, gcmarkbit = true, spacer = 0,
    save_type = SAVE_TYPE_FUNCPTR_PTR_OBJ, data = {{pointer = 0x1e1d370,
        funcpointer = 0x1e1d370, integer = 31576944, object = 31576944}, {
        pointer = 0x14bc548, funcpointer = 0x14bc548, integer = 21742920,
        object = 21742920}, {pointer = 0x4326d, funcpointer = 0x4326d,
        integer = 275053, object = 275053}, {pointer = 0x43277,
        funcpointer = 0x43277, integer = 275063, object = 275063}}},
  u_finalizer = {base = {type = Lisp_Misc_Marker, gcmarkbit = true,
      spacer = 1128}, prev = 0x1e1d370, next = 0x14bc548, function = 275053}}

From here on things don't look interesting (to me) but included for 
completemess: just character positions, cons cells, small chunks of text 
and the symbol nil.

Would recompiling the the GC sanity checking turned on be useful here?

How hard would it be to make emacs log the pointer or pseudopointer and
context when creating an object to stderr so we could figure out which 
object got corrupted? I guess we'd be swamped by output, especially as
it can take a long time to trigger the bug.
=======================================================================================

idx 5 looks like a cons cell whose first element is the cons containing the idx 6 entry:

(gdb) p XTYPE(last_marked[5])
$242 = Lisp_Cons
(gdb) p *XCONS(last_marked[5])
$243 = {car = 44165379, u = {cdr = 48953395, chain = 0x2eaf833}}
(gdb) p XTYPE(44165379)
$244 = Lisp_Cons
(gdb) p XTYPE(48953395)
$245 = Lisp_Cons
(gdb) p *XCONS(44165379)
$246 = {car = 21742881, u = {cdr = -30, chain = 0xffffffffffffffe2}}
(gdb) p XTYPE(21742881)
$247 = Lisp_Misc
(gdb) p *XMISC(21742881)
$248 = {u_any = {type = Lisp_Misc_Marker, gcmarkbit = true, spacer = 1128},
  u_free = {type = Lisp_Misc_Marker, gcmarkbit = true, spacer = 1128,
    chain = 0x1e1d370}, u_marker = {type = Lisp_Misc_Marker, gcmarkbit = true,
    spacer = 1128, need_adjustment = false, insertion_type = false,
    buffer = 0x1e1d370, next = 0x14bc548, charpos = 275053, bytepos = 275063},
  u_overlay = {type = Lisp_Misc_Marker, gcmarkbit = true, spacer = 1128,
    next = 0x1e1d370, start = 21742920, end = 275053, plist = 275063},
  u_save_value = {type = Lisp_Misc_Marker, gcmarkbit = true, spacer = 0,
    save_type = SAVE_TYPE_FUNCPTR_PTR_OBJ, data = {{pointer = 0x1e1d370,
        funcpointer = 0x1e1d370, integer = 31576944, object = 31576944}, {
        pointer = 0x14bc548, funcpointer = 0x14bc548, integer = 21742920,
        object = 21742920}, {pointer = 0x4326d, funcpointer = 0x4326d,
        integer = 275053, object = 275053}, {pointer = 0x43277,
        funcpointer = 0x43277, integer = 275063, object = 275063}}},
  u_finalizer = {base = {type = Lisp_Misc_Marker, gcmarkbit = true,
      spacer = 1128}, prev = 0x1e1d370, next = 0x14bc548, function = 275053}}

The cdr is a cons whose car is another "DEAD" string.

(gdb) p XTYPE(last_marked[5])
$249 = Lisp_Cons
(gdb) p *XCONS(last_marked[5])
$250 = {car = 44165379, u = {cdr = 48953395, chain = 0x2eaf833}}
(gdb) p XTYPE(48953395)
$251 = Lisp_Cons
(gdb) p *XCONS(48953395)
$252 = {car = 1092326, u = {cdr = 48953379, chain = 0x2eaf823}}
(gdb) p XTYPE(1092326)
$253 = Lisp_Int1
(gdb) p XINT(1092326)
$254 = 273081
(gdb) p XTYPE(48953379)
$255 = Lisp_Cons
(gdb) p *XCONS(48953379)
$256 = {car = 8760836, u = {cdr = 48953363, chain = 0x2eaf813}}

(gdb) p XINT(last_marked[4])
$260 = -273073 ← char position? seems close to the number above.

(gdb) p *XSTRING(last_marked[3])
$264 = {size = -9223372036854775800, size_byte = 8, intervals = 0x0,
  data = 0x2ab9f28 "l corpse"}

That's an outgoing string sent by the mud client over the newtwork.

last_marked[2] contains a cons of( last_marked[3] . last_marked[4] )

last_marked[1] containing structure for the last_marked[2]

last_marked[0]

(gdb) p XTYPE(last_marked[0])
$310 = Lisp_Symbol
(gdb) p *XSYMBOL(last_marked[0])
$311 = {gcmarkbit = true, redirect = SYMBOL_PLAINVAL, constant = 1,
  interned = 2, declared_special = true, pinned = false, name = 8760940,
  val = {value = 0, alias = 0x0, blv = 0x0, fwd = 0x0}, function = 0,
  plist = 33306355, next = 0x0}
(gdb) p XTYPE(8760940)
$312 = Lisp_String
(gdb) p *XSTRING(8760940)
$313 = {size = 3, size_byte = -1, intervals = 0x0, data = 0x5f3eec "nil"}

last_marked[499] - container of previous

last_marked[498]
(gdb) p last_marked[498]
$326 = 1092298
(gdb) p XTYPE(1092298)
$327 = Lisp_Int0
(gdb) p XINT(1092298)
$328 = 273074

last_marked[497] - XINT 273073

last_marked[496] (273073 . 273074)

last_marked[495] ((273073 . 273074) ...)

last_marked[494] 'nil

(gdb) p XTYPE(last_marked[494])
$350 = Lisp_Symbol
(gdb) p *XSYMBOL(last_marked[494])
$351 = {gcmarkbit = true, redirect = SYMBOL_PLAINVAL, constant = 1,
  interned = 2, declared_special = true, pinned = false, name = 8760940,
  val = {value = 0, alias = 0x0, blv = 0x0, fwd = 0x0}, function = 0,
  plist = 33306355, next = 0x0}
(gdb) p XTYPE(8760940)
$352 = Lisp_String
(gdb) p *XSTRING(8760940)
$353 = {size = 3, size_byte = -1, intervals = 0x0, data = 0x5f3eec "nil"}

last_marked[493] container
last_marked[492] 273074
last_marked[491] ibid
last_marked[490] -1
last_marked[489] container
last_marked[488] -273073
last_marked[487] "e"
last_marked[486] ("e" . -273073)
last_marked[485] container

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

From: Vivek Dasmohapatra <vivek <at> etla.org>
To: 26932 <at> debbugs.gnu.org
Subject: Subject: Re: bug#26932: 25.1;
Date: Mon, 10 Jul 2017 14:01:08 +0100 (BST)

The data structure looks like the buffer undo list.

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

From: Vivek Dasmohapatra <vivek <at> etla.org>
To: 26932 <at> debbugs.gnu.org
Subject: Found the triggering behaviour
Date: Wed, 10 Jan 2018 13:58:43 +0000 (GMT)

The old code in lui.el used to (effectively) do this:

  (setq buffer-undo-list (mapcar a-lambda-here buffer-undo-list))

This seemed to cause some strings in the undo list structure to get
freed to early, then freed again later.

The altered code uses the approach of setf'ing the relevant elements of
the undo-list, which doesn't trick the GC code into a premature free.

Since there's a workaround it's not particularly urgent, but it seems
to me that there's a hole in the GC logic somewhere.

--- /home/vivek/elisp/lui.el	2017-07-23 19:42:11.047162827 +0100
+++ /home/vivek/elisp/lui.el	2017-07-28 14:03:00.306977730 +0100
@@ -358,10 +358,8 @@
          (setq val (progn ,@body)))
        (when (consp buffer-undo-list)
          ;; Not t :-)
-         (setq buffer-undo-list (lui-adjust-undo-list buffer-undo-list
-                                                      ,old-marker-sym
-                                                      (- lui-input-marker
-                                                         ,old-marker-sym))))
+         (lui-adjust-undo-list  ,old-marker-sym (- lui-input-marker
+                                                   ,old-marker-sym)))
        val)))


@@ -776,66 +774,47 @@
                                   faces)))))))
   )

-(defun lui-adjust-undo-list (list old-begin shift)
-  "Adjust undo positions in LIST by SHIFT.
-LIST is in the format of `buffer-undo-list'.
-Only positions after OLD-BEGIN are affected."
-  ;; This is necessary because the undo-list keeps exact buffer
-  ;; positions.
-  ;; Thanks to ERC for the idea of the code.
-  ;; ERC's code doesn't take care of an OLD-BEGIN value, which is
-  ;; necessary if you allow modification of the buffer.
-  (let* ((adjust-position (lambda (pos)
-                            (if (and (numberp pos)
-                                     ;; After the boundary: Adjust
-                                     (>= (abs pos)
-                                         old-begin))
-                                (* (if (< pos 0)
-                                       -1
-                                     1)
-                                   (+ (abs pos)
-                                      shift))
-                              pos)))
-         (adjust (lambda (entry)
-                   (cond
-                    ;; POSITION
-                    ((numberp entry)
-                     (funcall adjust-position entry))
-                    ((not (consp entry))
-                     entry)
-                    ;; (BEG . END)
-                    ((numberp (car entry))
-                     (cons (funcall adjust-position (car entry))
-                           (funcall adjust-position (cdr entry))))
-                    ;; (TEXT . POSITION)
-                    ((stringp (car entry))
-                     (cons (car entry)
-                           (funcall adjust-position (cdr entry))))
-                    ;; (nil PROPERTY VALUE BEG . END)
-                    ((not (car entry))
-                     `(nil ,(nth 1 entry)
-                           ,(nth 2 entry)
-                           ,(funcall adjust-position (nth 3 entry))
-                           .
-                           ,(funcall adjust-position (nthcdr 4 entry))))
-                    ;; (apply DELTA BEG END FUN-NAME . ARGS)
-                    ((and (eq 'apply (car entry))
-                          (numberp (cadr entry)))
-                     `(apply ,(nth 1 entry)
-                             ,(funcall adjust-position (nth 2 entry))
-                             ,(funcall adjust-position (nth 3 entry))
-                             ,(nth 4 entry)
-                             .
-                             ,(nthcdr 5 entry)))
-                    ;; XEmacs: (<extent> start end)
-                    ((and (fboundp 'extentp)
-                          (extentp (car entry)))
-                     (list (nth 0 entry)
-                           (funcall adjust-position (nth 1 entry))
-                           (funcall adjust-position (nth 2 entry))))
-                    (t
-                     entry)))))
-    (mapcar adjust list)))
+;; ----------------------------------------------------------------------------
+
+(defun lui--adjust-p (pos old)
+  (and (numberp pos) (>= (abs pos) old)))
+
+(defun lui--new-pos (pos shift)
+  (* (if (< pos 0) -1 1) (+ (abs pos) shift)))
+
+(defun lui-adjust-undo-list (old-begin shift)
+  ;; Translate buffer positions in buffer-undo-list by SHIFT.
+  (unless (or (zerop shift) (atom buffer-undo-list))
+    (let ((list buffer-undo-list) elt)
+      (while list
+        (setq elt (car list))
+        (cond ((integerp elt)           ; POSITION
+               (if (lui--adjust-p elt old-begin)
+                   (setf (car list) (lui--new-pos elt shift))))
+              ((or (atom elt)           ; nil, EXTENT
+                   (markerp (car elt))) ; (MARKER . DISTANCE)
+               nil)
+              ((integerp (car elt))     ; (BEGIN . END)
+               (if (lui--adjust-p (car elt) old-begin)
+                   (setf (car elt) (lui--new-pos (car elt) shift)))
+               (if (lui--adjust-p (cdr elt) old-begin)
+                   (setf (cdr elt) (lui--new-pos (cdr elt) shift))))
+              ((stringp (car elt))      ; (TEXT . POSITION)
+               (if (lui--adjust-p (cdr elt) old-begin)
+                   (setf (cdr elt) (lui--new-pos (cdr elt) shift))))
+              ((null (car elt))         ; (nil PROPERTY VALUE BEG . END)
+               (let ((cons (nthcdr 3 elt)))
+                 (if (lui--adjust-p (car cons) old-begin)
+                     (setf (car cons) (lui--new-pos (car cons) shift)))
+                 (if (lui--adjust-p (cdr cons) old-begin)
+                     (setf (cdr cons) (lui--new-pos (cdr cons) shift)))))
+              ((and (featurep 'xemacs)
+                    (extentp (car elt))) ; (EXTENT START END)
+               (if (lui--adjust-p (nth 1 elt) old-begin)
+                     (setf (nth 1 elt) (lui--new-pos (nth 1 elt) shift)))
+                 (if (lui--adjust-p (nth 2 elt) old-begin)
+                     (setf (nth 2 elt) (lui--new-pos (nth 2 elt) shift)))))
+        (setq list (cdr list))))))

 (defvar lui-prompt-map
   (let ((map (make-sparse-keymap)))

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Vivek Dasmohapatra <vivek <at> etla.org>
Cc: 26932 <at> debbugs.gnu.org
Subject: Re: bug#26932: Found the triggering behaviour
Date: Wed, 23 Oct 2019 12:02:21 +0200

Vivek Dasmohapatra <vivek <at> etla.org> writes:

> The old code in lui.el used to (effectively) do this:
>
>   (setq buffer-undo-list (mapcar a-lambda-here buffer-undo-list))
>
> This seemed to cause some strings in the undo list structure to get
> freed to early, then freed again later.
>
> The altered code uses the approach of setf'ing the relevant elements of
> the undo-list, which doesn't trick the GC code into a premature free.
>
> Since there's a workaround it's not particularly urgent, but it seems
> to me that there's a hole in the GC logic somewhere.

If I understand correctly, the external lui package set buffer-undo-list
to something invalid, and this led Emacs to segfault when gc-ing?

Was there any further work done here, or a reproducible test case
written?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Vivek Dasmohapatra <vivek <at> etla.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 26932 <at> debbugs.gnu.org
Subject: Re: bug#26932: Found the triggering behaviour
Date: Mon, 20 Jan 2020 15:11:41 +0000 (GMT)

> If I understand correctly, the external lui package set buffer-undo-list
> to something invalid, and this led Emacs to segfault when gc-ing?

Not invalid as such - entries were removed from the list while it was "in 
flight" through a mapc/mapcar and a double free (or similar) occurred.

> Was there any further work done here, or a reproducible test case
> written?

No test case was written, the code for lui was changed to operate on
a copy of the undo list, then assign that back to the original head 
variable instead.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Vivek Dasmohapatra <vivek <at> etla.org>
Cc: 26932 <at> debbugs.gnu.org
Subject: Re: bug#26932: Found the triggering behaviour
Date: Wed, 22 Jan 2020 14:30:23 +0100

Vivek Dasmohapatra <vivek <at> etla.org> writes:

>> If I understand correctly, the external lui package set buffer-undo-list
>> to something invalid, and this led Emacs to segfault when gc-ing?
>
> Not invalid as such - entries were removed from the list while it was
> "in flight" through a mapc/mapcar and a double free (or similar)
> occurred.
>
>> Was there any further work done here, or a reproducible test case
>> written?
>
> No test case was written, the code for lui was changed to operate on
> a copy of the undo list, then assign that back to the original head
> variable instead.

You can make the Emacs gc segfault pretty trivially by making lists that
are recursive in just the wrong way, but it'd be interesting to see just
what it was that lui.el was doing.  But if there's no test case, then it
seem unlikely that we'll make further progress on this bug report.

So I'm closing this bug report.  If further progress can be made, please
either open a new bug report or respond to this and it'll be reopened.

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