bug#24764: 25.1.50; Another crash in automatic gc

[Eli Zaretskii <eliz@gnu.org>]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: Eli Zaretskii <eliz@gnu.org>
> Date: Sat, 22 Oct 2016 11:38:02 +0200
> 
> I think this could be provoked by some lisp stuff I currently develop
> that does a lot of consing, dunno (but of cause I don't funcall `crash'
> anywhere, at least not willingly :-) ).  Crashs happen every ten minutes or
> so, and at totally random points.
> 
> Here is the gdb output.  Session still open.
> [...]
> 
> (gdb) bt full
> #0  0x000000000058aae0 in unchain_marker (marker=0x88e9968) at marker.c:605
>         tail = 0x2020200020202020 <<<<<<<<<<<<<<<<<<<<<<<<
>         prev = 0x2020200020202030 <<<<<<<<<<<<<<<<<<<<<<<<

Your marker pointers are actually full of blank (and other ASCII)
characters.  So some code somewhere either writes past the end of some
stack-based array or otherwise overwrites the stack.

Or maybe your system, too, uses ralloc.c, and this is one more
manifestation of some buffer or string relocated while some code hangs
to the C pointers of the original contents.

The question is which code does that, and how, because usually this
happens long before GC.

See etc/DEBUG for how to debug problems during GC.  The first question
to answer is what is the Lisp data structure being GC'ed here.  Use
the last_marked array for that.

Then you will usually need to come up with a reproducible recipe for
the crash, because finding out which code causes this involves
repeated execution of the recipe with different probes inserted.

If you cannot easily come up with a reproducible recipe, try lowering
the value of gc-cons-threshold, so that GC happens more frequently;
that could allow you to realize what exactly in your Lisp causes the
bad memory writes.

That's about all I can say about this (not sure why I'm on the CC
list, anyway).

Oh, one other thing:

> In GNU Emacs 25.1.50.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.1)
>  of 2016-10-22 built on drachen
> Repository revision: bfd1abf5c8edf571e9ba272ec2587b964ba86102

There's no such revision SHA1 in the Emacs repository, so I'm not sure
what code base you are using there.