Finally getting some time to look at moving us off 2.x again, and first run: https://gist.github.com/philmayers/90d7a605c3020ff07820 Trying to dig into what's triggering it now. It's a huge config with a lot of stuff in, and the minimal changes to move from 2.x to 3.x
On Mar 15, 2016, at 10:03 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
Finally getting some time to look at moving us off 2.x again, and first run:
https://gist.github.com/philmayers/90d7a605c3020ff07820
Trying to dig into what's triggering it now. It's a huge config with a lot of stuff in, and the minimal changes to move from 2.x to 3.x
There was another report of this on the list a while back. I can't see why it would crash there. It checks if auth_item is not NULL, and auth_item should never have a garbage value. Maybe try v3.0.x head? I pushed a fix to always initialize auth_item to NULL. Alan DeKok.
On 15/03/16 14:03, Phil Mayers wrote:
Finally getting some time to look at moving us off 2.x again, and first run:
https://gist.github.com/philmayers/90d7a605c3020ff07820
Trying to dig into what's triggering it now. It's a huge config with a lot of stuff in, and the minimal changes to move from 2.x to 3.x
Looks like req_list is getting trampled with something - rlm_sql query strings from the look of the memory. But I don't understand how - paircompare is passed request, request->packet->vps but by line 537 req_list is now a different pointer: (gdb) print request $70 = (REQUEST *) 0xa68720 (gdb) print request->packet->vps $71 = (VALUE_PAIR *) 0xa55110 (gdb) print req_list $72 = (VALUE_PAIR *) 0xa673c0 (gdb) x/5s req_list 0xa673c0: "select distinct groupname from (select * from netgroup where username=lower('" 0xa6740e: "" 0xa6740f: "" 0xa67410: "\260" 0xa67412: "" Can't see how req_list can get mutated in that function. Will try 3.0 HEAD.
On Mar 15, 2016, at 10:22 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
Looks like req_list is getting trampled with something - rlm_sql query strings from the look of the memory. But I don't understand how - paircompare is passed request, request->packet->vps but by line 537 req_list is now a different pointer:
The only thing I can think of is that it's being passed as a VALUE_PAIR*, and the underlying VALUE_PAIR is being free'd somewhere. But it's weird that it's being freed in the middle of the function. Try watching the address of req_list. In developer builds, the _pair_free function in src/lib/pair.c writes to the VP before it's freed. You may also update that function to memset() all of it's entries to zero, too. Alan DeKok.
On 15/03/16 14:46, Phil Mayers wrote:
On 15/03/16 14:22, Phil Mayers wrote:
Will try 3.0 HEAD.
Bah. github being extremely extremely slow (50kB/s). Ran out of time today. Will have to revisit another time.
Finally. Good grief... Valgrind reckons: (10) sql_groupcmp finished: User is NOT a member of group BANNED ==2930== Invalid read of size 8 ==2930== at 0x4C2B6D8: paircompare (pair.c:625) ==2930== by 0x4C1CF76: cond_cmp_values (evaluate.c:315) ==2930== by 0x4C1D7C4: cond_normalise_and_cmp (evaluate.c:585) ==2930== by 0x4C1DC33: radius_evaluate_map (evaluate.c:654) ==2930== by 0x4C1DE40: radius_evaluate_cond (evaluate.c:750) ==2930== by 0x425D6B: modcall_recurse (modcall.c:479) ==2930== by 0x427039: modcall_child (modcall.c:408) ==2930== by 0x425DF4: modcall_recurse (modcall.c:785) ==2930== by 0x427039: modcall_child (modcall.c:408) ==2930== by 0x425DF4: modcall_recurse (modcall.c:785) ==2930== by 0x426FD2: modcall (modcall.c:1130) ==2930== by 0x420534: indexed_modcall (modules.c:1028) ==2930== Address 0xa130458 is 88 bytes inside a block of size 160 free'd ==2930== at 0x4A06430: free (vg_replace_malloc.c:446) ==2930== by 0x3D36C02388: _talloc_free_internal (talloc.c:876) ==2930== by 0x4E5637B: fr_pair_list_free (pair.c:134) ==2930== by 0x4C1C7FF: radius_pairmove (evaluate.c:1055) ==2930== by 0x850500D: sql_set_user (rlm_sql.c:502) ==2930== by 0x8506876: sql_groupcmp (rlm_sql.c:600) ==2930== by 0x4C2B62B: paircompare (pair.c:576) ==2930== by 0x4C1CF76: cond_cmp_values (evaluate.c:315) ==2930== by 0x4C1D7C4: cond_normalise_and_cmp (evaluate.c:585) ==2930== by 0x4C1DC33: radius_evaluate_map (evaluate.c:654) ==2930== by 0x4C1DE40: radius_evaluate_cond (evaluate.c:750) ==2930== by 0x425D6B: modcall_recurse (modcall.c:479) Looks like rlm_sql is doing something wrong, which is then messing up the packet for later code.
What about with 3.1.x - which is the foundation of the next 'stable' version . 3.0.x is years old now ;) alan
participants (3)
-
Alan Buxey -
Alan DeKok -
Phil Mayers