GNU bug report logs - #21666
25.0.50; Random segfaults

Previous Next

Full log

Message #20 received at 21666 <at> debbugs.gnu.org (full text, mbox):

From: Jorgen Schäfer <jorgen.schaefer <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, 21666 <at> debbugs.gnu.org
Subject: Re: 25.0.50; Random segfaults
Date: Fri, 16 Oct 2015 08:03:46 +0000

[Message part 1 (text/plain, inline)]

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

[Message part 2 (text/html, inline)]

[emacs-bug-4.txt (text/plain, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.