On 17 Jun 2014, at 15:33, Phil Mayers <p.mayers@IMPERIAL.AC.UK> wrote:
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?
Yes, it would seem to.
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.
You need to run with -m to free allocated memory on exit, else you may get false positives. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2