bug#26932: 25.1; Crash triggered a few times a day with network process

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#26932: 25.1; Crash triggered a few times a day with network process

Vivek Dasmohapatra-2
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 (86K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#26932: 25.1; Crash triggered a few times a day with network process

Eli Zaretskii
> Date: Sun, 14 May 2017 21:54:56 +0100 (BST)
> From: Vivek Dasmohapatra <[hidden email]>
>
> 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.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#26932: 25.1; Crash triggered a few times a day with network process

Vivek Dasmohapatra-2
> Is it possible for you to try the latest Emacs 25.2?

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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#26932: 25.1; Crash triggered a few times a day with network process

Vivek Dasmohapatra-2
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.








Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#26932: 25.1; Crash triggered a few times a day with network process

Eli Zaretskii
> Date: Sun, 11 Jun 2017 22:39:49 +0100 (BST)
> From: Vivek Dasmohapatra <[hidden email]>
> cc: [hidden email]
>
> 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.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#26932: 25.1; Crash triggered a few times a day with network process

Vivek Dasmohapatra-2
> 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.




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#26932: 25.1; Crash triggered a few times a day with network process

Eli Zaretskii
> Date: Mon, 12 Jun 2017 16:21:38 +0100 (BST)
> From: Vivek Dasmohapatra <[hidden email]>
> cc: [hidden email]
>
> > 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.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#26932: 25.1; Crash triggered a few times a day with network process

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




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#26932: 25.1; Crash triggered a few times a day with network process

Eli Zaretskii
> Date: Mon, 12 Jun 2017 16:56:32 +0100 (BST)
> From: Vivek Dasmohapatra <[hidden email]>
> cc: [hidden email]
>
> 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.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#26932: 25.1; Crash triggered a few times a day with network process

Vivek Dasmohapatra-2
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 (42K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#26932: 25.1; Crash triggered a few times a day with network process

Eli Zaretskii
> Date: Tue, 13 Jun 2017 16:41:37 +0100 (BST)
> From: Vivek Dasmohapatra <[hidden email]>
> cc: [hidden email]
>
> 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?



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#26932: 25.1; Crash triggered a few times a day with network process

Vivek Dasmohapatra-2
> 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"))))




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#26932: 25.1; Crash triggered a few times a day with network process

Eli Zaretskii
> Date: Tue, 13 Jun 2017 18:04:43 +0100 (BST)
> From: Vivek Dasmohapatra <[hidden email]>
> cc: [hidden email]
>
> > 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.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#26932: 25.1; Crash triggered a few times a day with network process

Vivek Dasmohapatra-2
> 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.




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#26932: 25.1; Crash triggered a few times a day with network process

Eli Zaretskii
> Date: Tue, 13 Jun 2017 22:23:33 +0100 (BST)
> From: Vivek Dasmohapatra <[hidden email]>
> cc: [hidden email]
>
> > 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.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#26932: 25.1; Crash triggered a few times a day with network process

Vivek Dasmohapatra-2
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?



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#26932: 25.1; Crash triggered a few times a day with network process

Eli Zaretskii
> Date: Thu, 15 Jun 2017 14:48:40 +0100 (BST)
> From: Vivek Dasmohapatra <[hidden email]>
> cc: [hidden email]
>
> 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.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#26932: 25.1; Crash triggered a few times a day with network process

Vivek Dasmohapatra-2
> 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?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#26932: 25.1; Crash triggered a few times a day with network process

Eli Zaretskii
> Date: Mon, 19 Jun 2017 01:57:54 +0100 (BST)
> From: Vivek Dasmohapatra <[hidden email]>
> cc: [hidden email]
>
> 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.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug#26932: 25.1; Crash triggered a few times a day with network process

Vivek Dasmohapatra-2
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
Loading...