Ok, now that backtrace and debugging are working again, back to top of thread for the issue. Just had another crash on HEAD of 3.0.x; digging into the core file, it does look like malloc state has become corrupted - segfault is inside glibc with: #5 _int_malloc (av=0x7f4ccc000020, bytes=<value optimized out>) at malloc.c:4476 4476 bck->fd = unsorted_chunks(av); (gdb) print bck $1 = (struct malloc_chunk *) 0x0 Higher stack has: #7 0x00000036ad40663f in __talloc (ctx=<value optimized out>, el_size=<value optimized out>, count=<value optimized out>, name=<value optimized out>) at ../talloc.c:560 560 tc = (struct talloc_chunk *)malloc(TC_HDR_SIZE+size); (gdb) print size $2 = 191 i.e. a perfectly ordinary malloc from talloc. Does everyone else agree this suggests heap corruption? Full backtrace here: https://gist.github.com/philmayers/18a04e642803153a4d5a Will try and re-trigger under valgrind, though memcheck seems to report a *lot* for 3.0.x head - many alloc-without-free for regexp compilations at compile parse time and similar.