On 26/10/12 15:34, Phil Mayers wrote:
I was about to say "that worked like a charm" then radiusd segfaulted :o(
I'll try to get a core dump.
Ugh. Horrible pointer corruption; little useful in the backtrace I'm afraid, but the various pointers were invalid by stack frame #5 #0 0x000000357f630215 in raise () from /lib64/libc.so.6 #1 0x000000357f631cc0 in abort () from /lib64/libc.so.6 #2 0x000000357f66a7fb in __libc_message () from /lib64/libc.so.6 #3 0x000000357f671ce2 in _int_free () from /lib64/libc.so.6 #4 0x000000357f67590c in free () from /lib64/libc.so.6 #5 0x00002aaaad3444ac in cache_entry_free (data=0xc00aa0) at rlm_cache.c:77 #6 0x00000031bb212eac in rbtree_delete (tree=0xbd5530, Z=0xbfd050) at rbtree.c:412 #7 0x00000031bb21302b in rbtree_deletebydata (tree=0xbd5530, data=<value optimized out>) at rbtree.c:461 #8 0x00002aaaad344465 in cache_find (inst=0xbd4eb0, request=0x2aaab8001150, key=0x41e013c0 "172.16.250.14.Stop.508aa231/dc:2b:61:b0:cd:7c/653919") at rlm_cache.c:164 #9 0x00002aaaad344652 in cache_it (instance=0xbd4eb0, request=0x2aaab8001150) at rlm_cache.c:567 #10 0x000000000041c951 in call_modsingle (component=3, c=<value optimized out>, request=0x2aaab8001150) at modcall.c:304 Looking at the code, I'm not entirely sure it's thread-safe; I don't see any locking around anything. What's to stop cache_entry_free running at the same time as the node is being accessed in another thread? Or the rbtree being corrupted? I've had to roll the change back, so I can't give more details at the moment.