And another one, this time in the same location as emacs-bug-2. mapcar's leni=2682, so not that much larger.

If I read the backtrace correctly, this should be the following piece of code, if that's helpful at all:

https://github.com/jorgenschaefer/circe/blob/master/lui.el#L916-L970

Regards,
Jorgen

On Thu, Oct 15, 2015 at 1:05 PM Jorgen Schäfer <jorgen.schaefer@gmail.com> wrote:
Hello!
The attached backtrace is running the same Emacs version (e6013e8c) but with your patch applied.

Program received signal SIGSEGV, Segmentation fault.
mark_object (arg=140737488314368) at alloc.c:6187
6187 if (ptr->gcmarkbit)

Anything else I can try to narrow it down more? :-)

Regards,
Jorgen


On Tue, Oct 13, 2015 at 6:09 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
Those two backtraces both have a call to mapcar1 with a long list (leni=2544 in
one, leni=2502 in the other).  When Fmapcar uses SAFE_ALLOCA_LISP, it'll ask for
(say) 2502*8 bytes, or 20016 bytes, and this is more than the 16 KiB MAX_ALLOCA
limit, which means SAFE_ALLOCA_LISP will invoke xmalloc and make_save_memory
rather than invoking AVAIL_ALLOCA.  One possibility is that the xmalloced memory
isn't being properly analyzed by the garbage collector.  To test that theory,
can you please try something like the attached patch?  This wouldn't fix the
bug, but it would mean mapcar should work for larger lists and you won't get a
backtrace until the list gets about twice as large.