On 23 Jun 2014, at 17:51, Phil Mayers <p.mayers@IMPERIAL.AC.UK> wrote:
On 23/06/14 17:48, Phil Mayers wrote:
On 23/06/14 17:13, Arran Cudbard-Bell wrote:
call backtrace_print(&vp_bt
$3 = (const VALUE_PAIR *) 0x7f07f003e780 (gdb) call backtrace_print(&vp_bt, 0x7f07f003e780) No backtrace available for 0x7f07f003e780
Doesn't fr_do_bt need to be mutex'd off the cbuff?
Or just alloced from the NULL ctx because it gets reparented anyway, yes.
Also, don't see what happens with marker->obj - thrown away? So don't see how backtrace_print() can ever find it?
It wouldn't *sigh*. OK lets try that again with working code and without me fat fingering almost everything. static fr_cbuff_t *vp_bt; VALUE_PAIR *pairalloc(TALLOC_CTX *ctx, DICT_ATTR const *da) { ... fr_backtrace_attach(&vp_bt, vp); return vp; } You should see lots of "Backtrace attached to VALUE_PAIR 0x<pointer addr>" messages going to stderr. (lldb) call backtrace_print(vp_bt, (VALUE_PAIR *) 0x<pointer addr>) Stacktrace for: 0x<pointer addr> 0 libfreeradius-radius.dylib 0x00000001000c5e53 fr_backtrace_do + 323 1 libfreeradius-radius.dylib 0x00000001000c5f92 fr_backtrace_attach + 258 2 libfreeradius-radius.dylib 0x00000001000eb55c pairalloc + 236 3 libfreeradius-radius.dylib 0x00000001000e125e data2vp + 3214 4 libfreeradius-radius.dylib 0x00000001000e2af2 rad_attr2vp + 370 5 libfreeradius-radius.dylib 0x00000001000e3280 rad_decode + 176 6 radiusd 0x000000010000d0c0 client_socket_decode + 112 7 radiusd 0x0000000100034dae request_pre_handler + 254 8 radiusd 0x000000010003024f request_running + 175 9 radiusd 0x0000000100030168 request_queue_or_run + 392 10 radiusd 0x000000010002f2ba request_receive + 2106 11 radiusd 0x000000010000daa5 auth_socket_recv + 1173 12 radiusd 0x0000000100032df5 event_socket_handler + 325 13 libfreeradius-radius.dylib 0x00000001000f4927 fr_event_loop + 1271 14 radiusd 0x0000000100032621 radius_event_process + 49 15 radiusd 0x0000000100023b91 main + 3601 16 libdyld.dylib 0x00007fff836fa5fd start + 1 17 ??? 0x0000000000000002 0x0 + 2 Stacktrace for: 0x<pointer addr> 0 libfreeradius-radius.dylib 0x00000001000c5e53 fr_backtrace_do + 323 1 libtalloc.dylib 0x000000010012d3d0 _talloc_free_internal + 862 2 libtalloc.dylib 0x000000010012d33d _talloc_free_internal + 715 3 libfreeradius-radius.dylib 0x00000001000eb6f7 pairfree + 119 4 radiusd 0x0000000100036e07 request_finish + 951 5 radiusd 0x000000010003033c request_running + 412 6 radiusd 0x0000000100030168 request_queue_or_run + 392 7 radiusd 0x000000010002f2ba request_receive + 2106 8 radiusd 0x000000010000daa5 auth_socket_recv + 1173 9 radiusd 0x0000000100032df5 event_socket_handler + 325 10 libfreeradius-radius.dylib 0x00000001000f4927 fr_event_loop + 1271 11 radiusd 0x0000000100032621 radius_event_process + 49 12 radiusd 0x0000000100023b91 main + 3601 13 libdyld.dylib 0x00007fff836fa5fd start + 1 14 ??? 0x0000000000000002 0x0 + 2 (lldb) One for alloc, one for free. We can then see if there's a common point of allocation for the double freed VPs. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2