Trouble with 7bae7c8e and radsec clients causing mutex crash

[Sam Hartman]

Hi.  I have a bug that is manifesting on 32-bit intel but not on x86_64.
Configurations are similar and I have fairly high confidence that the
changes don't matter; making the configurations identical is difficult.
Notes about the configuration:

* dynamic is true in proxy.conf

* sites-available/tls is the same as the stock configuration except that
  I've added a default radsec client:

client default {
        ipaddr = 0.0.0.0
                netmask = 0
                        proto = tls
                                secret = radsec
                                }
                                


When I try and connect using radsec I get:
Listening on auth+acct proto tcp address * port 2083 (TLS) as server
default
Listening on auth address 127.0.0.1 port 18120 as server inner-tunnel
Listening on auth address * port 1812 as server default
Listening on acct address * port 1813 as server default
Listening on auth address :: port 1812 as server default
Listening on acct address :: port 1813 as server default
Opening new proxy socket 'proxy address * port 0'
Listening on proxy address * port 56457
Ready to process requests
 ... new connection request on TCP socket
 freeradius: tpp.c:63: __pthread_tpp_change_priority: Assertion
 `new_prio == -1 || (new_prio >= __sched_fifo_min_prio && new_prio <=
 __sched_fifo_max_prio)' failed.
 Aborted
 
(gdb) bt
#0  0xb7fe1424 in __kernel_vsyscall ()
#1  0xb7b54941 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0xb7b57d72 in *__GI_abort () at abort.c:92
#3  0xb7b4db58 in *__GI___assert_fail (assertion=0xb7d0e64c "new_prio == -1 || (new_prio >= __sched_fifo_min_prio && new_prio <= __sched_fifo_max_prio)",
    file=0xb7d0e628 "tpp.c", line=63, function=0xb7d0e62e "__pthread_tpp_change_priority") at assert.c:81
    #4  0xb7d0c724 in __pthread_tpp_change_priority (previous_prio=-1, new_prio=5881) at tpp.c:61
    #5  0xb7d04c9d in __pthread_mutex_lock_full (mutex=0xb7c8a63c) at pthread_mutex_lock.c:415
    #6  0xb7f9f8fb in rbtree_find (tree=0xb7c8a628, data=0xbffff454) at src/lib/rbtree.c:513
    #7  0xb7f9f983 in rbtree_finddata (tree=0xb7c8a628, data=data at entry=0xbffff454) at src/lib/rbtree.c:539
    #8  0x0805636c in client_find (clients=clients at entry=0x82f53e8, ipaddr=ipaddr at entry=0xbffff884, proto=6) at src/main/client.c:399
    #9  0x0805efd4 in client_listener_find (listener=listener at entry=0x82f0ee0, ipaddr=ipaddr at entry=0xbffff884, src_port=48007) at src/main/listen.c:134
    #10 0x0805fe51 in dual_tcp_accept (listener=0x82f0ee0) at src/main/listen.c:574
    #11 0x08072775 in event_socket_handler (xel=0x80b2798, fd=16, ctx=0x82f0ee0) at src/main/process.c:4076
    #12 0xb7fa82a9 in fr_event_loop (el=0x80b2798) at src/lib/event.c:495
    #13 0x08077fd3 in radius_event_process () at src/main/process.c:4977
    #14 0x08053d9f in main (argc=4, argv=0xbffffcf4) at src/main/radiusd.c:582
    
(gdb) f 6
#6  0xb7f9f8fb in rbtree_find (tree=0xb7c8a628, data=0xbffff454) at src/lib/rbtree.c:513
513     src/lib/rbtree.c: No such file or directory.
(gdb) p tree
$1 = (rbtree_t *) 0xb7c8a628
(gdb) p *tree
$2 = {root = 0xb7c8a620, num_elements = -1211587040, compare = 0xb7c8a628 <main_arena+616>, free = 0xb7c8a628 <main_arena+616>, replace = 48, lock = 166, mutex = {
    __data = {__lock = -1211587024, __count = 3083380280, __owner = -1211587016, __kind = -1211587008, __nusers = 3083380288, {__spins = -1211587000, __list = {
              __next = 0xb7c8a648}}}, __size = "0\246ȷ8\246ȷ8\246ȷ@\246ȷ@\246ȷH\246ȷ", __align = -1211587024}}
	      

Needless to say, some random offset inside main_arena looks entirely out of place as a compare function.
And the lock valueand num_elements don't look so good either.
399     src/main/client.c: No such file or directory.
(gdb) p clients
$3 = (const RADCLIENT_LIST *) 0x82f53e8
(gdb) p *clients
$4 = {trees = {0x82f8800, 0x0 <repeats 31 times>, 0x82f56a8, 0x0 <repeats 96 times>}, min_prefix = 0}

(gdb) p *$6
$7 = {root = 0x82f8860, num_elements = 1, compare = 0x8056050 <client_ipaddr_cmp>, free = 0, replace = false, lock = false, mutex = {__data = {__lock = 0, __count = 0,
      __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\000' <repeats 23 times>, __align = 0}}
      

I'd appreciate any help trying to track this down.