Stack allocation of Lisp objects

Stack allocation of Lisp objects

[Stefan Monnier]

I started seeing occasional crashes (always during temacs's dump so
far), and while they come&go, they are completely reproducible when
they're here.  So I dug into it, and it looks like a problem with stack
allocation:

The crash I analyzed was within mark_object while looking at a `cons'
whose cdr is nil and whose car is a string whose address is 0xffffcbe0
which IIUC is on the stack.

Apparently there's an AUTO_STRING somewhere which we stick into a heap
allocated cons cell.  So of course, when the GC gets around to scan this
cons object, the stack-allocated string is long gone and overwritten by
unrelated data => crash.


        Stefan "going back to USE_STACK_LISP_OBJECTS=false"

Re: Stack allocation of Lisp objects

[Paul Eggert]

Stefan Monnier wrote:

> Apparently there's an AUTO_STRING somewhere which we stick into a heap
> allocated cons cell.

A plausible scenario is that you got bitten by a GCC bug, where GCC ignores 
___attribute__ ((aligned (8))) on your platform.  At least, that's how I 
reproduced the problem on x86.  I filed a GCC bug report 
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63495>.

If I'm right, the GCC bug cascaded into an Emacs portability bug: Emacs should 
use stack-based strings only if stack-base cons also works, as otherwise 
STACK_CONS could create a heap-based cons cell that points to a stack-based 
string, the symptom you observed.  I fixed that bug in Emacs trunk bzr 118080.

Because of this fix, Emacs no longer uses stack-based allocation on x86 + recent 
GCC, which is a bit of a downer.  It should still work with older GCC though, 
and I expect the GCC folks will fix the bug in newer GCC at some point.