Subject: Re: 25.0.50; Random segfaults

From: Jorgen Schäfer <[email-masked]>
Date: Fri, 16 Oct 2015 08:03:46 +0000

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 <[email-masked]>
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 <[email-masked]> 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.
>>
>>