GNU bug report logs - #21666
25.0.50; Random segfaults

Previous Next

Package: emacs;

Reported by: Jorgen Schaefer <Jorgen.Schaefer <at> gmail.com>

Date: Sun, 11 Oct 2015 17:09:02 UTC

Severity: normal

Tags: fixed

Found in version 25.0.50

Done: Noam Postavsky <npostavs <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Jorgen Schäfer <jorgen.schaefer <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, 21666 <at> debbugs.gnu.org
Subject: bug#21666: 25.0.50; Random segfaults
Date: Thu, 15 Oct 2015 11:05:07 +0000
[Message part 1 (text/plain, inline)]
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-3.txt (text/plain, attachment)]

This bug report was last modified 7 years and 30 days ago.

Previous Next


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