bug#24764: 25.1.50; Another crash in automatic gc

[Michael Heerdegen <michael_heerdegen@web.de>]

Eli Zaretskii <eliz@gnu.org> writes:

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

How can I find out?

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

My code does the following: open tons of elisp files, read all top level
expressions, and walk the expressions to create a huge list of all the
buffer's atoms, one per buffer, look at it, and discard it, and continue
with the next file etc.

> See etc/DEBUG for how to debug problems during GC. [...]

Ok, will do.

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

Because you give the most useful comments about how to debug such stuff,
and I have no clue most of the time.

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

That's one commit above emacs-25's current HEAD: the WIP commit for
making sort-line accepting a predicate arg.  I can revert it just to be
sure.  But I'm not even convinced that the stuff I suspect is really the
culprit.


Thanks so far,

Michael.