talloc & threads in rlm_eap

[Arran Cudbard-Bell]

On 23 Jun 2014, at 17:51, Phil Mayers <p.mayers at 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 at freeradius.org>
FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20140623/3f3af305/attachment-0001.pgp>