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@entry=0xbffff454) at src/lib/rbtree.c:539 #8 0x0805636c in client_find (clients=clients@entry=0x82f53e8, ipaddr=ipaddr@entry=0xbffff884, proto=6) at src/main/client.c:399 #9 0x0805efd4 in client_listener_find (listener=listener@entry=0x82f0ee0, ipaddr=ipaddr@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.