Basically I didn't manage to reproduce it with valgrind.

On Sat, Dec 26, 2015 at 1:33 PM, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Dmitry Antipov <dmantipov@yandex.ru> writes:
>
> > On 02/13/2014 03:33 PM, E Sabof wrote:
> >
> >> Program received signal SIGABRT, Aborted.
> >> 0x00007fd4ac8f0f77 in __GI_raise (sig=sig@entry=6)
> >>      at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> >> 56   ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> >> (gdb) backtrace
> >> #0  0x00007fd4ac8f0f77 in __GI_raise (sig=sig@entry=6)
> >>      at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> >> #1  0x00007fd4ac8f45e8 in __GI_abort () at abort.c:90
> >> #2  0x00007fd4ac938aca in __malloc_assert (
> >>      assertion=assertion@entry=0x7fd4aca426e0 "(unsigned long)(size)
> >= (unsigned long)(nb)", file=file@entry=0x7fd4aca3e18d "malloc.c",
> >>      line=line@entry=3637,
> >>      function=function@entry=0x7fd4aca3e48b <__func__.11428>
> "_int_malloc")
> >>      at malloc.c:288
> >> #3  0x00007fd4ac93c324 in _int_malloc (av=0x7fd4acc7b740 <main_arena>,
> >>      bytes=<optimized out>) at malloc.c:3637
> >> #4  0x00007fd4ac93d4d0 in __GI___libc_malloc (bytes=1008) at
> malloc.c:2859
> >
> > Obviously this is a heap corruption. Please try to 1) provide a recipe to
> > reproduce and 2) run temacs under 'valgrind --tool=memcheck' (slow!) to
> catch
> > memory errors (also use --log-file=log.txt since an output may be huge).
>
> More information was requested, but no response was given within a few
> months, so I'm closing this bug report.  If the problem still exists,
> please reopen this bug report.
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>